Security Audit

Security Audit

Perform a structured security audit of code, configuration, and architecture. Identify vulnerabilities, rank them by severity, and recommend concrete fixes grounded in OWASP standards, framework-specific best practices, and DevSecOps controls.

This is a read-only analysis. Do not modify code — audit, then report.

Usage

/security-audit [scope]

• With no argument, audit the current branch's diff against the default branch.
• With a path or module name, audit that scope.
• Use full to audit the whole repository for systemic issues.

Knowledge Base

The audit draws on five reference areas. Load the relevant reference file when a finding needs grounding or when you need detailed requirements for a topic:

Use progressive disclosure: keep the reference files unloaded until a finding maps to them. Load only the file the current finding needs.

Audit Process

1. Scope and gather context

# Detect the default branch
BASE_BRANCH=$(git remote show origin 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}' || echo main)

# Diff under audit
git diff "$BASE_BRANCH"...HEAD --stat
git diff "$BASE_BRANCH"...HEAD

# Dependency surface
cat package.json 2>/dev/null | jq '.dependencies, .devDependencies'
npm audit --json 2>/dev/null | jq '.metadata.vulnerabilities' 2>/dev/null

# Configuration surface
find . -maxdepth 2 \( -name '*.yml' -o -name '*.yaml' -o -name 'Dockerfile*' -o -name '.env*' \) -not -path './node_modules/*'

For a full audit, also enumerate: auth/session code, input handlers, file upload paths, database query construction, crypto usage, CI/CD workflow files, and container definitions.

Completion criteria:

• Default branch and diff under audit are identified.
• Dependency and configuration surfaces are enumerated for the selected scope.
• For full audits, the additional security-critical code paths are listed.

2. Run the checklist

Walk every changed or in-scope file against this checklist. Each item maps to an OWASP Top 10 category — use reference/owasp-top-10.md for the full category definitions and examples.

Input validation & injection (A03:2021 Injection, A05:2025 Injection; A02:2021 Cryptographic Failures, A04:2025 Cryptographic Failures)

• All external input (body, query, params, headers, cookies) is validated with an allow-list schema (zod, joi, ajv, class-validator)
• SQL/NoSQL queries use parameterized queries or ORM builders — no string concatenation
• OS command execution avoids exec/spawn with user input; uses argument arrays
• Output encoding is applied contextually (HTML, JS, URL, CSS) to prevent XSS
• Template engines use auto-escaping; dangerouslySetInnerHTML/v-html/|raw justified and sanitized
• Path traversal prevented — user input never reaches file path construction unsanitized
• SSRF prevented — outbound URLs validated against an allow-list, internal IPs blocked

Authentication & session (A07:2021 Identification and Authentication Failures, A07:2025 Authentication Failures)

• Passwords hashed with bcrypt/argon2/scrypt — never MD5/SHA1/plain text
• MFA available; credential recovery does not leak account existence
• Session IDs are high-entropy, rotated on login, invalidated on logout
• JWTs (if used) verified for signature, expiry, audience; secrets strong and rotated — see reference/owasp-cheat-sheets.md
• Brute-force protection (rate limiting, lockout) on auth endpoints
• No default or weak credentials

Authorization & access control (A01:2021 Broken Access Control, A01:2025 Broken Access Control)

• Deny by default; explicit allow on every protected resource
• Object-level (IDOR) checks — user cannot access other users' records by ID
• Role checks at the right layer (middleware/guard), not scattered in handlers
• No privilege escalation paths; admin functions gated
• CORS configured with an explicit origin allow-list — never * with credentials

Data protection & cryptography (A02:2021 Cryptographic Failures, A04:2025 Cryptographic Failures; A08:2021/2025 Software and Data Integrity Failures)

• TLS enforced everywhere; HSTS enabled; weak ciphers disabled
• Sensitive data encrypted at rest; secrets in a vault/env, never committed
• No sensitive data in logs, error messages, or URLs
• Strong algorithms only (AES-GCM, ChaCha20); no deprecated crypto (DES, RC4, ECB)
• Random values use crypto.randomUUID()/crypto.randomBytes() — never Math.random() for security
• Deserialization of untrusted data avoided or integrity-checked

Configuration & dependencies (A05:2021 Security Misconfiguration, A02:2025 Security Misconfiguration; A06:2021 Vulnerable and Outdated Components, A03:2025 Software Supply Chain Failures; A04:2021/A06:2025 Insecure Design)

• No hardcoded secrets, tokens, or API keys — see reference/devsecops.md for secret scanning
• Debug/verbose error pages disabled in production; stack traces not exposed
• Security headers present (CSP, HSTS, X-Frame-Options, X-Content-Type-Options) — helmet/ equivalents
• Dependencies pinned and audited; no known high/critical CVEs
• npm ci used in CI; lockfile committed; --ignore-scripts considered
• File uploads validated (type, size, content); stored outside web root — see reference/owasp-cheat-sheets.md
• Rate limiting on API and auth endpoints

Logging & error handling (A09:2021 Security Logging and Monitoring Failures, A09:2025 Security Logging and Alerting Failures; A10:2025 Mishandling of Exceptional Conditions)

• Security events logged (auth failures, access denials, input validation failures)
• Logs do not contain passwords, tokens, or PII
• Errors fail closed (deny) not open (allow) on unexpected conditions
• Generic error messages to users; details server-side only
• NULL/missing-parameter paths handled, not crashing or leaking info

Completion criteria:

• Every changed or in-scope file is checked against all relevant checklist sections.
• Each unchecked item is either confirmed not applicable or recorded as a finding.

3. Framework-specific checks

For Node.js projects, load reference/nodejs-security.md and check framework-specific concerns:

• Express: helmet(), express-rate-limit, cors allow-list, no X-Powered-By, body size limits, prototype pollution defenses
• NestJS: ValidationPipe with whitelist + forbidNonWhitelisted, ClassSerializerInterceptor to strip sensitive fields, Guards for authz, helmet middleware, throttler
• Fastify: @fastify/helmet, @fastify/rate-limit, @fastify/cors with origin allow-list, schema validation on routes, @fastify/under-pressure
• All: dependency pinning, npm audit/Snyk/Socket, non-root container user, event-loop blocking (ReDoS, sync APIs), prototype pollution

Completion criteria:

• The active framework stack is identified.
• Matching framework checks are reviewed and any gaps are captured as findings.

4. Pipeline & deployment checks

When the scope includes CI/CD or deployment, load reference/devsecops.md and verify:

• Dependency scanning (npm audit / Snyk / Dependabot / Trivy) runs in CI and gates on high/critical
• Secret scanning (Gitleaks pre-commit, TruffleHog in CI) prevents leaked credentials
• Container scanning (Trivy / Grype) on built images; base image minimal (distroless/slim)
• SAST (Semgrep / CodeQL) runs on PRs; results triaged
• DAST (OWASP ZAP) against staging on deploys
• IaC scanning (Checkov / tfsec) on Terraform/K8s manifests
• Least privilege: non-root container, read-only FS, dropped capabilities
• SBOM generated (CycloneDX / SPDX) for supply-chain traceability

Completion criteria:

• CI/CD and deployment controls in scope are reviewed against this checklist.
• Missing controls are documented with severity and remediation guidance.

5. Rank findings and report

Severity

Output format

## Executive Summary

- Overall posture: Secure / Needs attention / Critical issues
- N findings: 🔴 x  🟠 x  🟡 x  🟢 x  ℹ️ x
- Top recommendations (ordered by impact)

## Findings

### [Severity] Title
- **OWASP**: A03:2021-Injection (and A05:2025 if reclassified)
- **Location**: `src/api/upload.ts:42`
- **Issue**: One-line description
- **Impact**: What an attacker can do
- **Recommendation**: Concrete fix with code snippet or config change
- **Reference**: OWASP Cheat Sheet — File Upload; ASVS v5.0.0-5.2.1

## Positive Practices

- Well-implemented controls worth keeping

Cite the relevant OWASP category, ASVS requirement ID (e.g. v5.0.0-6.2.3), and Cheat Sheet in each finding so the recommendation is traceable to a standard.

Completion criteria:

• Every finding has severity, location, impact, recommendation, and standard references.
• Executive summary totals match the findings list.

Guidelines

• Be concrete: every finding needs a fix the developer can act on, not just a description of the problem.
• Map to standards: cite the OWASP Top 10 category and, where relevant, the ASVS requirement ID and Cheat Sheet. This makes findings auditable and educational.
• Verify, don't assume: read the actual code before flagging. A pattern that looks vulnerable may be mitigated elsewhere — confirm the mitigation is missing before reporting.
• Prioritize by exploitability: a Critical finding that requires no auth and is internet-reachable outranks a theoretical issue behind admin auth.
• Stay read-only: never modify code during an audit. Use inspection-only commands (git diff, npm audit, cat, grep). If your environment provides an execute() wrapper, prefer it for read-only command execution.
• Note the version: when citing OWASP Top 10, state whether you are using the 2021 or 2025 edition — they differ (see reference/owasp-top-10.md).