Security audit

Security Audit

Perform a structured security assessment of an application. This skill goes far deeper than the security checklist in code-reviewing — it's a dedicated, systematic analysis covering the OWASP Top 10 and beyond.

Scope Boundary

This skill analyzes code, configuration, and architecture for security vulnerabilities through static analysis and design review. It does not replace penetration testing, but it prepares code for one by catching the issues a pentester would find. It is the reactive half of the pair: for design-time analysis of a system that isn't built yet (trust boundaries, STRIDE, abuse cases), use threat-modeling — and when a threat model exists, use it as this audit's checklist.

⛔ The Iron Law

"No obvious problems" is not a pass.

Absence of evidence is not evidence of security. Every clearance is backed by evidence — the specific control you read and where it's enforced — and every finding cites the exact code path plus a concrete exploit scenario. If you can't write the exploit, you haven't assessed the risk; if you can, it isn't theoretical.

Workflow

Step 1: Define the Attack Surface

Before reviewing code line by line, map what's exposed:

• Entry points: HTTP endpoints, WebSocket connections, GraphQL resolvers, CLI inputs, file uploads, webhooks, cron jobs
• Authentication boundaries: What's public vs authenticated vs admin-only?
• Data flows: Where does sensitive data enter, travel, and get stored?
• External integrations: Third-party APIs, OAuth providers, payment processors
• Infrastructure: Cloud services, databases, caches, queues

Record the attack surface map as the first section of the report — gaps in understanding here mean gaps in the audit, so anything you could not map (unreachable config, undocumented integrations) goes under Open questions rather than being assumed safe.

Step 2: Assess by OWASP Top 10

Walk through each category systematically. See references/owasp-top-10.md for the detailed checklist.

For each finding:

• Severity: Critical / High / Medium / Low
• Location: File, line, endpoint
• Vulnerability: What the issue is
• Exploit scenario: How an attacker would use this (concrete, not theoretical)
• Remediation: Specific code change or configuration fix

Step 3: Authentication & Authorization Deep Dive

Auth is where the highest-impact vulnerabilities live. Review:

Authentication:

• How are credentials stored? (bcrypt/argon2 with sufficient rounds, never MD5/SHA)
• Session management: secure flags, httpOnly, sameSite, expiration
• Token handling: JWT validation (algorithm, expiry, issuer), refresh token rotation
• Password policy: minimum complexity, breached password checking
• MFA implementation (if present): bypass resistance, recovery flow security
• Rate limiting on login: brute force protection

Authorization:

• Is authorization checked on every protected endpoint (not just the UI)?
• Are there IDOR vulnerabilities? (Can user A access user B's resources by changing an ID?)
• Is the authorization model consistent? (role-based, attribute-based, or ad-hoc?)
• Are there privilege escalation paths? (Can a regular user reach admin functionality?)
• Are API endpoints and UI permissions in sync?

Step 4: Data Security Review

• At rest: Is sensitive data encrypted in the database? (PII, payment data, health data)
• In transit: Is TLS enforced everywhere? Any HTTP-only endpoints?
• In logs: Are passwords, tokens, SSNs, or credit card numbers logged?
• In errors: Do error messages leak internal details (stack traces, SQL queries, file paths)?
• In responses: Do API responses include fields the client shouldn't see?
• Retention: Is data deleted when it should be? GDPR/CCPA compliance?

Step 5: Dependency Audit

Run dependency vulnerability scanners and review results:

# JavaScript/TypeScript
npm audit
npx better-npm-audit audit

# Python
pip audit
safety check

# Go
govulncheck ./...

# Ruby
bundle audit check --update

For each vulnerability found:

• What is the CVE and its severity?
• Is the vulnerable code path actually used in this project?
• Is there a patched version available?
• If no patch exists, what's the mitigation?

Suggest using the dependency-management skill for remediation planning.

Step 6: Secrets and Configuration

• Scan for hardcoded secrets: API keys, passwords, tokens, private keys
• Check .gitignore covers sensitive files (.env, key files, certificates)
• Review git history for accidentally committed secrets: git log --all -p | grep -i "password\|secret\|api_key\|token"
• Verify environment variable usage for all secrets
• Check that different environments use different credentials

Step 7: Produce the Report

Output the audit report using the template at templates/security-report.md. Organize findings by severity, with Critical and High items first.

Write the full report to a file (default a gitignored location, e.g. .local/security-audit-<date>.md) and state its path in your final summary — this skill runs in a forked context: only the summary returns, everything unwritten is lost. The summary must lead with the Critical/High count. Judgment calls that need user input (unclear trust boundary, whether a data store is in scope, unverifiable control) go in an Open questions section of the report — never silently assumed safe.

What This Skill Does NOT Cover

• Runtime penetration testing (requires running the application)
• Network-level security (firewall rules, VPN configuration)
• Physical security or social engineering
• Compliance certification (SOC 2, HIPAA, PCI DSS — though findings may relate)

Principles Applied

• Defense in depth: Don't rely on a single security control. Layer protections.
• Least privilege: Every component should have the minimum permissions it needs.
• Fail secure: When something goes wrong, it should deny access, not grant it.
• KISS: Simpler security is more auditable security. Complex auth flows breed bugs.

Rationalizations to reject

Excuse	Reality
"I didn't see anything obviously wrong"	You audited the absence of obvious bugs, not the presence of security. Trace each control.
"The framework handles that"	Verify the control is actually enabled and configured correctly — don't assume.
"Auth is checked in the UI"	UI checks are not authorization. Confirm server-side enforcement on every protected endpoint.
"This input is internal/trusted"	Trust boundaries shift. Validate anyway — defense in depth.
"That CVE doesn't apply to us"	Confirm the vulnerable code path is unused before dismissing it.
"It's only a theoretical risk"	If you can't write the exploit scenario, you haven't assessed it.

Red flags — stop and correct course

• Signing off a category without naming the file/endpoint you verified.
• A finding with no concrete exploit path.
• Concluding "secure" because nothing jumped out.
• Trusting that a control exists without reading where it's enforced.