Codex Security Audit Skill

Codex Security Audit Skill

Overview

Use this skill to perform pragmatic security reviews of software projects. Focus on concrete exploitable risks and launch-blocking issues, not generic checklists.

Workflow

1. Establish scope: app type, stack, auth model, data sensitivity, deployment target, public/private status, and whether fixes should be implemented.
2. Inspect repository structure and entry points: package files, env examples, routes/controllers, middleware, auth/session code, API clients, database access, upload paths, logging, deployment config, and README.
3. Run scripts/scan_secrets.py <path> when local files are available to catch common secret patterns. Treat output as leads, not proof.
4. Load references/security-checks.md for detailed category checks when reviewing web/API/SaaS/mobile projects.
5. Classify findings by severity:
   • Critical: likely secret exposure, auth bypass, user data exposure, remote code execution, payment bypass, or production compromise.
   • High: serious authorization, injection, insecure upload, session, dependency, or privacy issue exploitable under realistic conditions.
   • Medium: meaningful hardening gap, missing validation, weak defaults, unsafe headers/CORS, incomplete rate limiting, or risky operational behavior.
   • Low: defense-in-depth, documentation, observability, or polish issue.
6. If asked to fix issues, patch the smallest necessary surface, preserve existing architecture, and verify with tests or targeted commands.

Audit Rules

• Prefer evidence from files and commands. Do not invent vulnerabilities without a plausible code path.
• Separate confirmed issues from suspicious patterns that need manual verification.
• Never print full secrets. Show only file path, line number, variable/key name, and a short redacted preview when needed.
• Prioritize server-side authorization over UI-only controls.
• Check whether data access is scoped by user, tenant, organization, role, or ownership.
• Treat client-side feature gates, admin checks, and plan checks as insufficient unless backed by server-side enforcement.
• For third-party services, verify environment variable naming, public/private key separation, webhook verification, and test/live mode boundaries.
• For dependency issues, avoid claiming current CVEs unless verified with an actual audit command or authoritative source.
• For legal/compliance topics, identify engineering risks and missing controls, but do not provide legal conclusions.

Output Format

Use this format unless the user asks for code changes only:

Security decision: Pass / Pass after fixes / Do not launch yet
Risk level: Low / Medium / High / Critical

Confirmed findings
- [Severity] Title
  Evidence: file/path:line or command output summary
  Risk: concrete impact
  Fix: specific remediation

Needs verification
- ...

Fastest safe fix plan
1. ...
2. ...
3. ...

Verification
- Commands run, files inspected, and areas not covered.

Implementation Guidance

When fixing security issues:

• Add validation close to the boundary where untrusted input enters.
• Add authorization checks close to data access or protected action execution.
• Keep secrets on the server and remove them from client bundles, logs, and committed files.
• Prefer framework-native security helpers over custom logic.
• Add regression tests for auth, ownership, injection, upload, and webhook paths when feasible.
• Update .env.example, README, or deployment notes when fixes require configuration.

Resources

• references/security-checks.md: Detailed checklist for web, API, SaaS, mobile, deployment, and repo hygiene reviews.
• scripts/scan_secrets.py: Lightweight local scanner for common secret-like patterns.