OC Security Audit -- OWASP-grounded pre-launch security audit for web apps

Dedicated to Ohad Cohen, a brave Israeli soldier who gave his life protecting Kibbutz Be'eri on October 7, 2023.

Install

Step 1 — add the marketplace (run this first, then wait for it to finish):

/plugin marketplace add miclivne/oc-security-audit

Step 2 — install the plugin:

/plugin install oc-security-audit

Then run in any project:

/oc-security-audit

or just ask: "run a security audit on this project"

What it checks

14 categories mapped to OWASP standards. Each answers a plain-language security question:

How it works

The audit runs in 6 steps with progress indicators:

Step 1: DISCOVER              Step 2: SELECT TESTS         Step 3: SCAN
[shell script]                [shell script]               [shell script]

discover.sh                   Read profile, count:         scan.sh
  - Detect framework            - 66 test types to run       - Profile-driven dispatch
  - Detect hosting              - 11 LLM judgment calls      - grep code patterns
  - Detect ORM                  - 33 skipped (not            - curl live domain
  - Find 12+ API routes           applicable to stack)       - npm audit
  - Find production domain      - 12 deferred to             - Check security headers
  - Detect features               /security-review           - Output TOTALS + Audit Details

Step 4: ANALYZE               Step 5: REPORT               Step 6: CLOSE
[LLM]                         [LLM]                        [LLM]

LLM reads route files         Positive-first report:       Remind about /security-review
  for 8 judgment calls:         1. What's secure            Offer to save report
  - IDOR ownership              2. Executive Summary
  - Privilege escalation         3. What needs attention
  - Feature misuse                 (issues by category,
  - Data exposure                   severity-tagged)
  - Prompt injection             4. Audit Details table
  - Workflow bypass

Lightweight — shell scripts handle mechanical checks, LLM only activates for judgment calls and report writing. Steps 1-3 use zero LLM tokens. Token usage varies by model and project size.

Profile-driven execution (v2.2 architecture)

The profile (profiles/nextjs-prisma.md) is the single source of truth. It declares every OWASP WSTG test case with a decision: RUN (script), RUN (llm), SKIP, or DEFER. scan.sh reads the profile at startup and dispatches to named functions. If a RUN check has no matching function, scan.sh emits a FAIL row -- no silent skipping.

This follows industry-standard patterns used by OWASP ZAP, Nessus, and Checkov -- the profile drives execution, not hardcoded check lists.

Report structure

The report leads with the positive and uses clear severity tags:

1. What's secure -- categories where your app is fundamentally solid (generous: includes LLM judgment passes and categories with minor WARNs)
2. Executive Summary -- posture emoji + exact pass/warn/fail counts + distinct findings count
3. What needs attention -- issues grouped by category, ordered by priority:
   • Each issue has a severity tag: :red_circle: FIX / :yellow_circle: INVESTIGATE / :green_circle: MONITOR/ACCEPT
   • Each FIX issue includes 7 sections: WSTG Reference, Threat, What's wrong, What could happen, What could go wrong when fixing, How others solve this, Recommended action
4. Audit Details -- script-computed category summary table with OWASP test IDs (numbers guaranteed accurate)

What it doesn't check

These checks are deferred to Anthropic's /security-review skill, which does deep code-level analysis:

Supported stacks

Each stack has its own profile (profiles/{stack}.md) with WSTG-mapped checks, grep patterns, and judgment call definitions tailored to that stack's patterns and conventions.

Unsupported stacks

Note (April 2026): We currently only support the nextjs-prisma profile. Adding a new profile is straightforward — copy the existing profile, adjust the RUN/SKIP/DEFER decisions for your stack, and add matching grep patterns. PRs welcome, or open an issue to request a profile for your stack.

If your stack is not yet supported, partial stack-independent checks still run (security headers, TLS, exposed files, DNS, npm audit, secret patterns) with a message noting which stack-specific checks were skipped.

Security model

• Read-only. This skill does not modify any files in your project.
• No secret values read or output. Scripts check for key existence only (e.g., "does STRIPE_SECRET_KEY exist in .env.production?") -- never reads or prints the value.
• Network: GET/HEAD to user's own domain only. The only outbound HTTP requests go to the production domain discovered from your env files. No requests to third-party servers.
• No POST to any server. All network checks use GET or HEAD methods.
• No eval. Patterns are sourced from a companion .sh file, not eval'd from markdown.
• stdout only. No files are written. The report is presented in the conversation.
• Every command is commented. Every curl, grep, dig, and find call has a # WHY: comment explaining what it checks and why. 102 WHY comments in scan.sh, 27 in discover.sh.
• Minimal allowed-tools. Only Read, Grep, Glob, and two pattern-restricted Bash calls (discover.sh and scan.sh). No unrestricted shell access.

Safe for review by Gen Trust Hub, Socket, and Snyk.

Legal disclaimer

This skill is provided as-is, for informational purposes only. It does not constitute security advice, and its output should not be treated as a professional security assessment. A passing audit does not guarantee the absence of vulnerabilities.

The security of your project is solely the responsibility of the project owner and builders. The authors of this skill are not responsible for any security issues, breaches, damages, or losses that may arise from the use or misuse of this tool, or from acting (or failing to act) on its output.

Do not run against systems you do not own or have written permission to test.

This skill sends GET/HEAD requests to your production domain to check security headers, exposed files, and error handling behavior. These are lightweight, non-destructive requests equivalent to loading your site in a browser. No exploitation, brute-forcing, or load testing is performed.

Standards cited

• OWASP Web Security Testing Guide (WSTG) v4.2
• OWASP API Security Top 10 2023
• OWASP Top 10 for LLM Applications 2025
• OWASP Top 10 2025
• OWASP ASVS 5.0 Level 1