plugins/lisa-expo-cursor/skills/owasp-zap/SKILL.md
# OWASP ZAP Baseline Scanning OWASP ZAP (Zed Attack Proxy) performs DAST (Dynamic Application Security Testing) by scanning a running application for common security vulnerabilities from the OWASP Top 10. ## When to Use - After making changes to HTTP headers, authentication, or security middleware - Before deploying to staging or production - When reviewing security scan results from CI - When triaging ZAP findings from pull request checks ## Running Locally ```bash # Requires Docker to be
npx skillsauth add codyswanngt/lisa plugins/lisa-expo-cursor/skills/owasp-zapInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
OWASP ZAP (Zed Attack Proxy) performs DAST (Dynamic Application Security Testing) by scanning a running application for common security vulnerabilities from the OWASP Top 10.
# Requires Docker to be installed and running
bash scripts/zap-baseline.sh
The scan builds the Expo web export, serves it locally, and runs ZAP against it. Reports are saved to zap-report.html, zap-report.json, and zap-report.md.
ZAP findings are categorized by risk level:
| Risk | Action | |------|--------| | High | Fix immediately — indicates exploitable vulnerability | | Medium | Fix before deployment — security best practice violation | | Low | Fix when convenient — minor security improvement | | Informational | Review — may be false positive or acceptable risk |
script-src 'self' 'unsafe-inline' for hydration.frame-ancestors in CSP at CDN level.HttpOnly, Secure, and SameSite attributes.Server response header.ZAP scan rules are configured in .zap/baseline.conf. Each line controls how ZAP treats a specific rule:
IGNORE: Skip the rule entirelyWARN: Report finding but don't fail the buildFAIL: Fail the build if this finding is detectedZAP runs automatically in CI via the zap-baseline.yml workflow. Results are uploaded as artifacts and the build fails on medium+ severity findings.
documentation
Onboard a user to the project via its LLM Wiki. Interviews the user about themselves in relation to the project, captures that to project-scoped memory only, then gives a guided tour of what the project is and sample questions they can ask. Use when someone is new to the project or asks to be onboarded. Read-mostly — it does not open PRs or write PII into the wiki.
documentation
Migrate an existing, hand-rolled wiki implementation onto the lisa-wiki kernel — phased and compatibility-first, with a strict no-loss guarantee. Use when adopting lisa-wiki in a repo that already has its own wiki/, ingest skills, docs, or roles. Renaming things into the canonical shape is fine; losing functionality or data is not. Ends by running /doctor.
development
Health-check the LLM Wiki. Reports orphan pages, contradictions, stale claims, broken internal links, missing index/log coverage, structure-manifest violations, and secret/tenant leaks. Use periodically or before hardening a wiki. Read-only — it reports findings, it does not fix them.
testing
Ingest source material into the LLM Wiki. With an argument (URL, file path, or prompt) it ingests that one source; with no argument it runs a full ingest across every enabled non-external-write source. Routes to the right connector, then runs the ordered pipeline (source note → synthesis → index → log → verify → state → commit/PR). Use whenever new knowledge should enter the wiki.