OWASP Top 10 2025 Security Audit

Goal

Systematic codebase audit against the OWASP Top 10 2025 framework. Produces a structured severity-rated report with evidence-backed findings. Emphasizes semantic code understanding over regex pattern matching — grep patterns are starting points, real analysis happens by reading and reasoning about code context.

When to use

• “Run an OWASP audit on this codebase”
• “Check for OWASP Top 10 vulnerabilities”
• “Security audit against OWASP 2025”
• “Audit A01 and A03 only”
• “Check this repo for common vulnerabilities”
• “OWASP security review”

When not to use

• PR code review (use review skill)
• npm audit / pip audit / dependency scanning only
• SOC2 / ISO 27001 compliance checks (use drata-api skill)
• General security questions without audit intent
• Threat modeling (use security-threat-model skill)
• Single-file code review

Inputs

• Codebase accessible via Glob/Grep/Read
• Optional: specific OWASP categories (e.g. “A01 and A03 only”)
• Optional: focus areas or known concerns

Outputs

• Markdown report inline (write to file only if user requests)
• Executive summary table
• Per-category findings with severity/confidence/evidence/remediation
• Summary statistics and next steps

Workflow

Phase 1: Reconnaissance

Classify the project before auditing. Use Glob/Read on key files:

Glob: package.json, requirements.txt, go.mod, Cargo.toml, *.tf, *.csproj, pom.xml
Glob: Dockerfile*, docker-compose*, .github/workflows/*
Glob: **/routes/*, **/api/*, **/controllers/*, **/handlers/*
Read: README.md (first 100 lines), main entry points

Determine:

• Project type: web-app | api | iac | library | cli | mobile | monorepo
• Languages/frameworks: e.g. Node/Express, Python/Django, Go/Gin, Terraform/AWS
• Deployment model: serverless, containers, VMs, static hosting
• Data sensitivity signals: auth, PII, payments, healthcare, crypto

Phase 2: Relevance Filtering

Use project type to set audit depth per category. Prevents nonsensical checks (e.g. SQL injection on Terraform).

• Full: run all grep patterns + semantic analysis
• Light: grep patterns only, flag but don’t deep-dive
• Skip: mention as not applicable in report, move on

Phase 3: Evidence Gathering

For each relevant category, run Grep/Glob patterns from CATEGORIES.md. Use parallel tool calls for independent categories. Collect file paths and matching lines as evidence.

Phase 4: Semantic Analysis

For each flagged file/pattern:

1. Read surrounding code context (not just matched line)
2. Determine if finding is true positive or false positive
3. Check for existing mitigations (guards, validators, middleware)
4. Assign severity: Critical / High / Medium / Low
5. Assign confidence: High / Medium / Low
6. Note specific remediation

Severity criteria:

• Critical: exploitable without authentication, leads to data breach or RCE
• High: exploitable with low-privilege access, significant data exposure
• Medium: requires specific conditions, limited exposure
• Low: defense-in-depth issue, minimal direct impact

Phase 5: Report Generation

Use this template:

# OWASP Top 10 2025 Security Audit Report

**Project**: <name>
**Type**: <project-type> | **Languages**: <langs> | **Date**: <date>
**Scope**: <full audit | partial: categories listed>

## Executive Summary

| Severity | Count |
|----------|-------|
| Critical | N |
| High     | N |
| Medium   | N |
| Low      | N |
| Info     | N |

<1-3 sentence summary of key findings and overall posture>

## Findings

### A0X: <Category Name> — <PASS | FINDINGS | N/A>

> Relevance: Full | Light | Skip

#### Finding X.1: <title>
- **Severity**: Critical | High | Medium | Low
- **Confidence**: High | Medium | Low
- **Location**: `path/to/file:line`
- **Evidence**: <code snippet or pattern match>
- **Issue**: <what's wrong and why it matters>
- **Remediation**: <specific fix>

(repeat per finding)

---

## Summary Table

| Category | Status | Critical | High | Medium | Low |
|----------|--------|----------|------|--------|-----|
| A01 | ... | ... | ... | ... | ... |
(all 10 categories)

## Methodology

- Automated pattern matching via Grep/Glob
- Semantic code analysis of flagged locations
- False positive filtering based on code context
- Project-type relevance filtering applied

## Next Steps

1. <prioritized remediation actions>
2. <recommended tooling or processes>
3. <categories needing deeper manual review>

Partial Audit Support

When user requests specific categories (e.g. “audit A01 and A03 only”):

1. Skip Phase 2 (relevance filtering)
2. Minimal Phase 1 — detect language/framework only
3. Run only requested categories through Phases 3-5
4. Report covers only requested categories, notes others as out-of-scope

Decision Points

• Large codebase (>500 files): Focus on entry points, auth boundaries, and config files. Note coverage limitations in report.
• Monorepo: Run Phase 1 per sub-project. Produce per-project section or single unified report based on user preference.
• No findings: Report as clean audit with methodology notes. Don’t fabricate issues.

Validation Checklist

• All 10 categories addressed (or noted as N/A/out-of-scope)
• Every finding has severity + confidence + location + evidence + remediation
• False positives filtered (not just raw grep output)
• Project type correctly identified and relevance matrix applied
• Report uses consistent severity definitions
• Executive summary accurately reflects findings

References

• Category details, grep patterns, semantic checks: CATEGORIES.md
• Evaluation prompts: EVALUATIONS.md