Security Audit Report skill for Codex
Findings an engineer can fix and an exec can read. Codex turns raw notes, scanner exports and captured requests into a structured security report. It validates and de-duplicates findings by root cause, scores each with a CVSS vector plus a written contextual rationale, redacts evidence, and writes the executive summary last so it reflects the findings. Coverage gaps and retest status are recorded so the report holds up in an audit.
curl -fsSL codexskills.dev/install.sh \ | sh -s -- security-audit-reportInstalls to ~/.agents/skills/security-audit-report/ for every project on this machine.
curl -fsSL codexskills.dev/cli.mjs -o codex-skills.mjsnode codex-skills.mjs install security-audit-reportThe CLI also searches, updates and removes skills. Run it with no arguments to pick from a list. Needs Node 20.12+.
curl -fsSL codexskills.dev/install.sh \ | sh -s -- --project security-audit-reportInstalls to .agents/skills/security-audit-report/ in the current repository. Commit it and everyone who runs Codex there gets it.
curl -fsSLO codexskills.dev/downloads/security-audit-report.zipunzip -o security-audit-report.zip -d ~/.agents/skills/The archive holds the skill folder with its generated agents/openai.yaml. Unzip into .agents/skills/ to scope it to a repo.
& ([scriptblock]::Create((irm codexskills.dev/install.ps1))) security-audit-reportPowerShell 5.1 or 7. Installs to %USERPROFILE%\.agents\skills\. Add -Project for the current repo.
104-line POSIX script. No sudo, no telemetry. Read install.sh
Use it in Codex
Start a prompt with $security-audit-report, or pick it from /skills.
You can also just describe the task: Codex reads the description below and loads the playbook when your request matches.
What Codex reads before loading it
Writes security assessment and pentest reports that owners act on - executive summary, scope and methodology, findings with CVSS 4.0 or 3.1 vectors, business-context severity, reproducible evidence, remediation and retest status. Turns raw notes, scanner output and tool logs into consistent finding write-ups. Use when asked to write up a security audit, code review or penetration test, rate findings by severity, convert Semgrep or ZAP output into a report, or draft a retest letter.
Use it when
- A security assessment or pentest is done and needs a written report
- Scanner output must be triaged into validated findings
- Severities in an existing report are inconsistent or disputed
- Fixes shipped and the report needs retest results
Use something else when
- You are submitting a single issue to a bug bounty program: use bug-bounty-reporting
- The testing itself has not happened yet: use pentest-methodology
How to check the result
Each finding has evidence, reproduction steps and a CVSS vector that matches its rating, severity counts match the summary table, and a grep for tokens and secrets in the report returns nothing.
The mistake it prevents
Copying scanner alerts straight into the findings list, or filing one root cause as a dozen separate findings to inflate the count.
A good report lets three readers act without calling the tester: the executive learns the risk in one page, the engineer reproduces and fixes each finding, and the auditor sees what was and was not tested. Every severity is defensible from its vector and context, and no finding is in the report that the evidence does not prove.
Inputs to gather first
- Engagement letter or scope: targets, dates, tester names, test type (black/grey/white box), exclusions and constraints. If none exists, ask; a report without scope is not auditable.
- Raw notes, request/response captures, screenshots, scanner exports (SARIF, ZAP/Burp XML, Nessus), command logs with timestamps.
- The organisation’s severity policy if one exists (some use their own matrix, some a bug-bounty taxonomy). Their policy wins over defaults here.
Treat all evidence as confidential. Redact secrets, tokens, session cookies and personal data in every screenshot and snippet (keep the last 4 characters at most). Never paste client evidence into third-party tools or online CVSS calculators that log input.
Workflow
- [ ] 1. Inventory: list every candidate finding with its evidence file
- [ ] 2. Validate: drop anything not reproduced or not in scope; merge duplicates by root cause
- [ ] 3. Score: CVSS vector + contextual severity for each finding
- [ ] 4. Write findings (template below), most severe first
- [ ] 5. Write scope, methodology, coverage gaps
- [ ] 6. Write the executive summary last
- [ ] 7. Consistency pass (checks below), then hand to the user for review before deliveryScanner output is a lead list, not findings. A Semgrep hit or ZAP alert becomes a finding only after a human-reviewable proof (a reachable path, a working request, an exploitable config). Unverified items go in an appendix labelled “observations, not validated” or are dropped.
Severity
Use CVSS for the technical score and state the version. Default to CVSS 4.0 unless the client standardises on 3.1; never mix versions in one report.
| Rating | CVSS score | Typical example |
|---|---|---|
| Critical | 9.0-10.0 | Unauthenticated RCE; auth bypass to any account; full DB read |
| High | 7.0-8.9 | IDOR across tenants; stored XSS in admin panel; SSRF to cloud metadata |
| Medium | 4.0-6.9 | CSRF on a state change; reflected XSS needing interaction; verbose errors leaking internals |
| Low | 0.1-3.9 | Missing hardening headers; version disclosure with no known exploit |
| Informational | n/a | Best-practice gaps without a direct exploit path |
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N # authenticated cross-tenant read
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N # same issue in 3.1Then adjust to contextual severity and say why in one sentence: data classification, number of users affected, compensating controls actually observed, internet exposure. Raising or lowering a rating without a written reason is the most common complaint auditors raise.
Rules for consistent scoring:
- Score the finding as demonstrated, not the worst imaginable chain. If chaining two findings is what creates the impact, write a separate “attack chain” entry.
- One root cause, one finding. Twelve endpoints missing the same authorization check is one finding with twelve affected locations, not twelve findings.
PRreflects the privilege the tester actually needed. Self-registration counts as low.
Finding template
### H-02 Cross-tenant invoice read via predictable ID (IDOR)
| Severity | High (CVSS 4.0 7.1) |
|---|---|
| Vector | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N |
| Affected | GET /api/v2/invoices/{id} (api.example.com), commit a1b2c3d |
| CWE | CWE-639 Authorization Bypass Through User-Controlled Key |
| Status | Open |
**Description.** The endpoint loads an invoice by numeric ID without checking that it
belongs to the caller's tenant. Any authenticated user can read any tenant's invoices.
**Impact.** Billing names, addresses and line items for all ~4,000 tenants are exposed to
any account holder, including free-trial sign-ups.
**Steps to reproduce.**
1. Log in as tenant A user `[email protected]`; note invoice `10452`.
2. Log in as tenant B user `[email protected]`.
3. `curl -H "Authorization: Bearer <tenant-B token>" https://api.example.com/api/v2/invoices/10452`
4. Response 200 with tenant A's invoice (evidence/H-02-response.txt, redacted).
**Remediation.** Scope the query by tenant (`WHERE id = ? AND tenant_id = ?`) in
`InvoiceRepository.find`, and add an authorization test per tenant boundary. Consider
non-sequential IDs as defence in depth only.
**References.** OWASP API Security Top 10 2023 API1; CWE-639.Report structure
- Executive summary (one page): what was tested, overall risk posture in plain language, counts by severity, the two or three issues that matter most, and the recommended next action. No jargon, no CVSS vectors.
- Scope and approach: targets, dates, test type, accounts used, standards followed (OWASP WSTG, ASVS, MASVS, CIS), tools and versions.
- Coverage and limitations: what was not tested and why (time, access, excluded hosts, rate limits). This protects both parties.
- Findings summary table: ID, title, severity, status, owner.
- Detailed findings: template above, sorted by severity, then likelihood.
- Positive observations: controls that worked (useful to the owner, and shows the tester checked).
- Appendices: tool output summaries, unvalidated observations, retest log.
Retests
Keep the original finding IDs. Add a retest line per finding: date, build or commit, result (Fixed, Partially fixed, Not fixed, Risk accepted by named owner), and new evidence. Never delete a finding because it was fixed; change its status.
Consistency checks before delivery
- Every finding has evidence, a reproduction a third party can follow, and a remediation that names the component to change.
- Severity counts in the summary match the findings table; IDs are unique and sequential.
- No unredacted secrets, tokens, real customer data or internal IPs that the client asked
to omit (
rg -n "eyJ|Bearer [A-Za-z0-9]|AKIA|password=" report.md). - Titles describe the flaw and the asset, not the tool (“Stored XSS in ticket comments”, not “Burp issue 5245312”).
- The report goes to the named recipients only. Ask the user before sending or uploading it anywhere; Codex drafts, the user delivers.
What the zip contains
SKILL.md plus the interface file below. Nothing runs on install.
agents/openai.yaml
Gives the Codex app a display name, a one-line description and a starter prompt for this skill.
interface:
display_name: "Security Audit Report"
short_description: "Findings an engineer can fix and an exec can read"
default_prompt: "$security-audit-report Turn my pentest notes and Burp exports into a client-ready report"About this skill
Written and maintained by the Codex Skills editors to the same editorial standard as every skill here: a selective description, a real workflow, known pitfalls and a way to verify the work. First published , last updated . MIT licensed. Something wrong or out of date? Tell us.