# Codex Security Audit Skill

> Audit software projects for practical security risks before launch or publication. Use when Codex is asked to review a codebase, SaaS, web app, API, mobile app, GitHub repo, deployment, or MVP for exposed secrets, insecure authentication, authorization bugs, unsafe input handling, dependency risk, CORS/header issues, file upload risk, logging leaks, payment/security misconfiguration, or to produce a prioritized security fix plan.

- Skill: `kappaemme-git/codex-security-audit-skill` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add kappaemme-git/codex-security-audit-skill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kappaemme-git/codex-security-audit-skill/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: kappaemme-git (https://skillmd.com/u/kappaemme-git)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kappaemme-git/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:

```markdown
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.