security-code-audit

name

security-code-audit

description

Deep security review of software repositories, pull requests, patches, services, scripts, apps, infrastructure, and configuration to find exploitable vulnerabilities and security issues. Use when Codex is asked to audit code, find vulnerabilities, perform a security review, threat model software, harden an implementation, investigate auth/session/access-control flaws, validate scanner findings, review dependencies or IaC, or assess any codebase for security risk across any language or framework.

Security Code Audit

Overview

Use this skill to perform a defensive, evidence-driven security audit. Treat scanners as helpers only; read the code deeply enough to explain concrete attack paths, affected assets, exploit preconditions, and practical fixes.

Non-Negotiables

• Review only user-provided, local, or explicitly authorized targets.
• Do not perform destructive actions, persistence, lateral movement, credential use, data exfiltration, or live exploitation against third-party systems.
• Do not print secret values. If a secret may be exposed, report only the file, line, variable/key name, provider pattern, and a redacted fingerprint if useful.
• Do not fabricate findings. A finding needs an attack path, impact, and code evidence. Label uncertain issues as hypotheses and state the missing proof.
• Do not stop at dependency or scanner output. Trace at least the relevant source, guard, state change, and sink in application code.

Core Workflow

1. Establish scope.

   • Identify whether the target is a whole repository, changed files, a feature, an incident, a scanner report, or a specific vulnerability class.
   • If scope is not explicit, inspect the current repository and state assumptions.
   • Note any areas not reviewable because code, configuration, generated artifacts, or runtime context is missing.

2. Build a code and trust-boundary map before looking for bugs.

   • Inspect the repository structure, dependency manifests, entrypoints, routes/controllers, auth/session code, data stores, background jobs, parsers, file handling, outbound network calls, admin surfaces, CI/CD, deployment, and IaC.
   • Run scripts/repo_security_inventory.py when a fast first-pass map would help. Treat its output as leads, not conclusions.
   • Read references/deep-review-method.md for the full mapping and tracing method on non-trivial audits.

3. Create a lightweight threat model.

   • Identify assets, actors, trust boundaries, privilege levels, tenant boundaries, external integrations, data classifications, and sensitive operations.
   • Prioritize flows where untrusted input, identity, money, permissions, secrets, filesystem, network egress, or code execution meet.

4. Review source-to-sink and privilege flows.

   • Enumerate untrusted inputs: HTTP/API params, headers, cookies, webhooks, files, archives, URLs, CLI args, env vars, queues, browser messages, plugins, templates, database records controlled by users, and third-party callbacks.
   • Trace each high-risk input through validation, normalization, authorization, business rules, persistence, and sinks.
   • Work backward from sensitive sinks: database queries, command execution, template rendering, redirects, deserialization, file paths, uploads, cryptography, secrets, logs, network requests, admin actions, and billing/account state.
   • For pull requests, review changed code in context; inspect callers, callees, permissions, migrations, config, and tests around the diff.

5. Check vulnerability classes systematically.

   • Read references/vulnerability-classes.md for the checklist and evidence expectations.
   • Cover authentication, authorization, tenant isolation, injection, XSS/client trust, CSRF/CORS, SSRF, file/path handling, deserialization, crypto, secrets, logging, supply chain, CI/CD, cloud/IaC, business logic, race conditions, and dependency risk as applicable.

6. Verify claims.

   • Prefer existing tests, small local repros, static checks, dependency audit tools, and framework-native security checks when available.
   • Keep verification non-destructive and local unless the user explicitly authorizes a safe test environment.
   • When verification is not possible, explain why and reduce confidence accordingly.

7. Report findings with evidence.

   • Read references/reporting.md before the final response.
   • Lead with findings ordered by severity. Include exact file/line references, attack path, impact, preconditions, confidence, and fix guidance.
   • If no vulnerabilities are found, say so clearly and include coverage, commands run, and residual risk.

Depth Requirements

• Use rg and structured searches to identify all related code paths before concluding a control exists or is missing.
• For each serious issue, inspect enough surrounding code to answer: who can reach it, what data they control, what guard should stop them, what sink or state change is reached, and what the real impact is.
• Chase wrappers and framework abstractions. Do not assume a helper is safe from its name; inspect its implementation and its call sites.
• Check both positive and negative authorization logic: who is allowed, who is denied, default behavior, object ownership, tenant scoping, role hierarchy, and admin bypasses.
• Compare intended invariants against all mutation paths, including background jobs, imports, migrations, webhooks, retries, and batch APIs.
• Revisit likely false negatives before finalizing: generated routes, hidden admin endpoints, config defaults, environment-specific behavior, and code omitted by ignore rules.

Tooling

Use available local tools, but keep code reading primary.

Resolve bundled script paths relative to this skill directory.

python scripts/repo_security_inventory.py /path/to/repo
python scripts/repo_security_inventory.py /path/to/repo --json

Use language-specific tooling when present, such as test suites, type checks, linters, npm audit, pnpm audit, yarn npm audit, pip-audit, poetry audit, bundler-audit, cargo audit, govulncheck, mvn dependency-check, gradle dependencyCheckAnalyze, semgrep, gitleaks, trufflehog, checkov, tfsec, kubescape, or framework security checks. Do not install or run heavyweight tools without considering time, network, and project side effects.

When dependency advisories, CVEs, exploited-in-the-wild status, or vendor fixes matter, verify current details from primary sources before reporting them.

Resource Guide

• references/deep-review-method.md: Read for whole-repo reviews, unfamiliar architectures, PR security reviews, and any audit where shallow scanning would miss business logic or access-control bugs.
• references/vulnerability-classes.md: Read while enumerating vulnerability classes and deciding what evidence is needed for each class.
• references/reporting.md: Read before producing final findings or triaging scanner output.

When references are too broad for the current task, load only the relevant sections and summarize the rest.