Audit Owasp Asvs

OWASP ASVS Security Audit

Audit software (frontend, backend, API, mobile/web session handling, config) against the official OWASP Application Security Verification Standard (ASVS) v5.0.0 and produce a read-only, evidence-based, severity-prioritized Markdown report that a product owner or security engineer can read and act on.

1. Hard operational rules (non-destructive)

This skill never modifies anything. Follow these rules without exception:

• Read-only inspection only. Use read/find tools (read, list, glob, grep) and read-only shell commands (ls, rg, git log, git show, git status, git diff, find). Do not use edit, write, move, delete, or patch tools on project files.
• Never run the audited application. No npm run, make, docker run, python app.py, tests, compilers, or scripts from the project. Do not install packages.
• No network activity against the target. Do not curl/wget/probe the application, its API, or its hosts. No active pentesting, fuzzing, or scanning.
• No side effects. Do not start servers, daemons, or background jobs. Do not touch .git index (no git add/commit/reset).
• Secrets handling. If credentials or keys are found, do not log or reproduce the full value; record the location (file:line) and that a secret of type X was found.
• Report is the only artifact. Produce the report as a new Markdown file, never overwriting an existing file. Default target: reports/ at the repo root with a unique name (e.g. reports/asvs-audit-<yyyy-mm-dd>.md) or the exact path the user supplied. If the user did not give a path and you are unsure, present the report in chat first and ask before writing it.

If a requested action would violate a rule, refuse and explain which rule blocks it.

2. ASVS essentials

• ASVS v5.0.0 groups requirements into 17 chapters (V1-V17) and 345 requirements, each identified V<chapter>.<section>.<requirement> (e.g. V6.2.1).
• Levels (from the standard):
  • Level 1 (L1, 70 reqs) - against opportunistic, low-effort attacks. Baseline for most applications.
  • Level 2 (L2, 183 reqs) - defense in depth against sophisticated attacks. Now the common best practice (roughly the old L2 recommended default).
  • Level 3 (L3, 92 reqs) - advanced/APT-grade controls for high-value targets (financial, health, security infrastructure).
• Default audit level: L1, unless the user asks for L2/L3.
• Cite requirements as v5.0.0-V6.2.1 in reports so IDs survive standard changes.
• Full machine-readable requirement list: references/asvs-v5.0.0-requirements.md.

3. Workflow

Phase 0 - Scope and parameters

Ask or confirm only what is not inferable from the project:

1. Audit level (L1/L2/L3; default L1) or full L1+L2.
2. Scope: whole repo, or specific modules/components (e.g. "the auth module", "the public API").
3. Report destination path (default reports/asvs-audit-<date>.md).
4. Applicability hints: web frontend? REST/GraphQL API? WebSocket? Mobile backend? OAuth/OIDC? WebRTC? - use to mark non-applicable chapters. Do not stall: if the user said "just go", pick sensible defaults (L1, full repo) and start. A scope is not required; proceed and note assumptions.

Phase 1 - Read-only reconnaissance

• Map the repo: language, frameworks, package manifests (package.json, requirements.txt, go.mod, Cargo.toml, Gemfile), entry points (routes, controllers, handlers, middlewares).
• Identify: web-facing surfaces, auth mechanism, session handling, ORM/SQL usage, template engine, file upload code, crypto usage, logging, secrets/config files.
• Record a short tech-stack note for the report.

Phase 2 - Applicability triage

Mark each chapter NOT-APPLICABLE when the component does not exist in scope (e.g. V17 WebRTC absent, V10 OAuth/OIDC unused). Keep all others as SCOPED.

Phase 3 - Requirement-by-requirement verification

For every scoped requirement (from L1 up to the chosen level):

• Gather evidence with read-only searches: rg/grep for patterns (e.g. ${query}/ string concatenation into SQL, innerHTML, eval(), read the relevant handler, review config (CSP/headers, cookie flags, TLS), auth/session code, crypto usage, log calls.
• Assign one verdict per references/asvs-v5.0.0-requirements.md requirement:
  • PASS - control present and effective (cite code).
  • FAIL - control absent or clearly ineffective.
  • PARTIAL - control exists but incomplete/weakly enforced.
  • NOT-APPLICABLE - component not in scope.
  • NOT-VERIFIABLE - cannot determine from static code alone (dynamic behavior, runtime config, external service). List these explicitly; do not guess.
• Record evidence as path:line pairs plus a 1-3 sentence rationale for every FAIL/PARTIAL/NOT-VERIFIABLE.
• Do not fabricate findings from templates; each FAIL must trace to observed code.

Phase 4 - Severity and priority scoring

Each FAIL/PARTIAL finding gets a priority P0-P3, then findings are sorted by priority (then by ASVS level) in the report.

Adjust by likelihood × impact in the actual context (an L1 failure on a non-sensitive public page may drop to P2; an L3 control protecting PII can still be P1). Add the ASVS level (L1/L2/L3) next to the requirement ID in every finding so readers see the standard's own weight.

Phase 5 - Generate the report

Use templates/asvs-audit-report.md. Required sections:

1. Header: project, date, scope, level(s), methodology, tooling (read-only static audit).
2. Executive summary (product-owner readable): overall posture, compliance %, count per severity, top 3-5 risks in plain language.
3. Findings list, sorted P0 -> P3: each with priority badge, v5.0.0-Vx.y.z, chapter, level, title, verdict, evidence path:line, impact, and "How to remediate" (concrete, project-local fix steps).
4. Compliance matrix per chapter (PASS/FAIL/PARTIAL/NA/NV counts + %).
5. Remediation roadmap (ordered work items the team can turn into issues).
6. Limitations: what static analysis cannot prove (NOT-VERIFIABLE list), and any out-of-scope areas.

4. Chapter inspection map (what to look for)

5. Parallel audit mode (multiple agents)

For large codebases or full L2/L3 audits, split the work across multiple read-only agents that audit different ASVS chapters in parallel and report back to one coordinator agent, which produces the single final report.

When to use: repo is large, many chapters are in scope, or the user explicitly asks to "run the audit in parallel" / "split across agents". For small projects or L1-only, Parallel mode is optional; single-agent remains the default.

Coordinator contract

1. Acquire the code once. If the project is already local, use it. If it only lives on GitHub or another remote, clone it once into a fresh local directory or git worktree (executed by the coordinator; the only network/write operation in the whole audit). Record the clone location and the commit/branch SHA audited. Servers must not be probed by workers.
2. Split chapters. Group the scoped ASVS chapters (see references/parallel-audit.md for a balanced default split). Aim for roughly equal requirement counts per worker; heavy chapters (V6 Authentication, V10 OAuth and OIDC) can stand alone; very small chapters (V9) can be joined with adjacent ones. L1-only: 2-4 workers suffices.
3. Dispatch one worker per group, each with this identical contract:
   • Scope: exact chapter IDs, audit level(s), and the repo path (the shared clone).
   • Rules: apply the same non-destructive rules (section 1) - read-only, no execution, no network, no writes, no secrets in output.
   • Method: Phase 1-4 of the workflow scoped to the assigned chapters.
   • Deliverable: return in the final message the findings for the assigned chapters in a structured form: per finding v5.0.0-Vx.y.z, chapter, title, verdict, evidence path:line, impact, P0-P3 priority, and a "How to remediate" line. Plus the per-chapter PASS/FAIL/PARTIAL/N/A/not-verifiable counts.
4. Merge and produce the report. Combine worker results: deduplicate overlapping findings (e.g. the same flag reported by two chapter agents), normalize priorities, fill templates/asvs-audit-report.md, and write the single report file. Workers never write files; only the coordinator writes the report (new path only).
5. Validate. Ensure every cited path:line exists in the repo, every priority has a rationale consistent with Phase 4, and no chapter of the chosen level is missing.

Worker guardrails (apply to every worker)

• Re-read the hard rules of section 1; a worker that would modify, execute, or contact the audited project must stop and report back instead.
• Workers answer only their assigned chapters; do not duplicate other agents' scope.
• Return findings even when a chapter is entirely NOT-APPLICABLE or NOT-VERIFIABLE (state so explicitly with counts).

Runtime-specific recipes to spawn workers (opencode vs Claude Code) are kept in references/parallel-audit.md; the recipes differ between agents, not the protocol.

6. Remediation guidance in the report

Every FAIL/PARTIAL finding must end with a concrete "How to remediate" paragraph that maps to the project's own stack (e.g. "switch parameterized queries in src/db/", "add HttpOnly; Secure; SameSite=Strict to the session cookie in middleware X", "move vault secrets in docker-compose.yml to the secrets manager Y", "add rate limiting middleware in src/middleware/"). Point at the exact file(s) that need changes so findings become trackable work items (issue/backlog).

7. Limitations and honesty

• This is a static, at-rest review; runtime behavior, live configuration, and external dependencies are not executed. Mark such requirements NOT-VERIFIABLE rather than guessing.
• Absence of evidence is not evidence of control; only PASS when the control is visible in code/config.
• ASVS compliance is not an authorization of production readiness; state so in the report.
• All findings must be traceable to files read during the audit. Never invent file paths.

8. Skills resources

• references/asvs-v5.0.0-requirements.md - full requirement text for mapping/citing.
• references/parallel-audit.md - runtime-specific recipes (opencode / Claude Code) to run the parallel audit mode, plus a balanced chapter split.
• templates/asvs-audit-report.md - the report skeleton to fill in.