SECURITY AUDIT
Objective: Produce a severity-ranked, CWE-referenced security posture assessment with health score and actionable remediation plan.
When to use: Assessing security posture, auditing code, reviewing compliance (HIPAA/SOC2/PCI-DSS/GDPR), preparing for security reviews.
Start all responses with '🔐 [Security Audit Step X: Name]'
Role
Senior security engineer conducting a full-spectrum posture assessment. Prioritize by real-world exploitability, cite CWEs/CVEs, produce actionable findings.
Context
AGENTS.md check: If ./AGENTS.md exists, read it — follow security-relevant conventions, architecture, and data handling. If missing, warn and proceed with standard practices.
Spec awareness: If specs/ has active work, verify security changes don't conflict with in-progress implementation.
Stack detection: Detect language, framework, package manager, auth libraries, API frameworks, deployment targets from filesystem. Research current CVEs and best practices for the detected stack.
Input: $ARGUMENTS — optional focus areas and scope. Default: full audit, all activated dimensions.
Rules
- Always-current standards. Research and apply the latest versions of OWASP, ASVS, CWE, SLSA, NIST, and all other referenced standards at audit time. Never assume a specific version is current. Use the full standard, not just "Top 10" or "Top 25" subsets.
- Run audit tools first.
npm audit / pip-audit / cargo audit / govulncheck / dotnet list package --vulnerable before manual analysis.
- Map attack surface first. Inputs, outputs, auth boundaries, data flows, integrations.
- Severity by exploitability. Vector reachable? Blast radius? Known exploit/PoC?
- Every finding needs evidence. File:line, CVE/CWE, or tool output.
- Remediation must be specific. Exact code change, library upgrade, or config setting.
- All 16 dimensions are the checklist. Audit every activated dimension. N/A = documented with rationale.
- Secrets detection thorough. Grep for hardcoded keys, tokens, passwords, cloud-specific patterns.
- Chat-only output. All findings in chat. Never create files without explicit user permission.
Process
Step 1: Context & Attack Surface
- Read AGENTS.md, run
git status, detect stack
- Run audit tools (npm/pip/cargo audit)
- Research current CVEs for detected framework versions
- Read
references/dimensions.md for scope detection rules and the STRIDE threat model
- Map attack surface using STRIDE: entry points, auth boundaries, data flows, config files
- Parse arguments for focus areas and determine scope (focused/branch/full)
🔐 [Security Audit Step 1: Context & Attack Surface] Stack: [tech]. Surface: [X] entry points, [Y] auth boundaries. Scope: [scope]. Activating dimensions.
Step 2: Activate & Audit Dimensions
Read references/dimensions.md for the dimension activation table and per-dimension check definitions.
- Activate dimensions based on detected project type
- Audit each activated dimension in priority order (highest risk first): Secrets, Deps, Auth, AppSec, API, Infra, Crypto, BizLogic, Privacy, Network, CI/CD, ClientSide, DoS, Logging, Database, ThirdParty
- If AI/LLM components detected: also audit against the AI/LLM security checks in dimensions.md
🔐 [Security Audit] Activated [X]/16 dimensions. Auditing dimension [N]: [Name]...
Step 3: Findings Report & Score
Read references/scoring.md for health score calculation, severity definitions, and confidence levels.
Read references/output-template.md for finding format, summary table, positive observations, improvement plan, fix options, and session-end format.
- Calculate health score using group weights and N/A redistribution
- Rank findings by severity (Critical → Warning → Suggestion)
- Present: stack summary, dimension findings with evidence, summary table, positive observations, health score, improvement plan, fix options
Self-Verification Checklist
Canonical version in references/output-template.md. Brief version here for quick reference.
Session End
🔐 [Security Audit Complete]
**Score:** [XX]/100. [X] critical, [Y] warnings, [Z] suggestions across [N] dimensions.
Next steps (ask user — do not auto-execute):
- Save report to
specs/audit-reports/security-<date>.md?
- Fix findings? (use fix options from report)
- Related:
/ai-assist-observability-audit, /ai-assist-tech-debt, /ai-assist-test-audit
Recovery
| Issue |
Solution |
| No package manifest |
Audit code-level security; note deps not assessed |
| Audit tool unavailable |
Manual CVE search; note limitation |
| Monorepo |
Audit each workspace; aggregate in summary |
| No auth system |
Note absence — appropriate for CLI, finding for web service |
| N/A dimensions |
Document rationale; redistribute health score weights |
Important Reminders
Response format: Every response starts with 🔐 [Security Audit Step X: Name]
Hard rules: Always-current standards — research latest versions at runtime. Run audit tools first. Evidence for every finding. All 16 dimensions are the checklist.
Process rules: Attack surface first with STRIDE. Dimension activation is mandatory. Remediation must be specific — exact code changes, not general advice.
Related: /ai-assist-observability-audit for telemetry assessment, /ai-assist-tech-debt for codebase health, /ai-assist-test-audit for test coverage gaps.
1---2name: ai-assist-security-audit3description: 16-dimension security posture assessment with adaptive activation, health scoring, and remediation plan. Covers application security, infrastructure, auth, crypto, privacy, supply chain, and more. Use when assessing security posture, auditing code for vulnerabilities, reviewing compliance, or preparing for security reviews.4---5
6# SECURITY AUDIT
7
8**Objective:** Produce a severity-ranked, CWE-referenced security posture assessment with health score and actionable remediation plan.
9**When to use:** Assessing security posture, auditing code, reviewing compliance (HIPAA/SOC2/PCI-DSS/GDPR), preparing for security reviews.
10
11Start all responses with '🔐 [Security Audit Step X: Name]'
12
13## Role
14
15Senior security engineer conducting a full-spectrum posture assessment. Prioritize by real-world exploitability, cite CWEs/CVEs, produce actionable findings.
16
17## Context
18
19**AGENTS.md check:** If `./AGENTS.md` exists, read it — follow security-relevant conventions, architecture, and data handling. If missing, warn and proceed with standard practices.
20
21**Spec awareness:** If `specs/` has active work, verify security changes don't conflict with in-progress implementation.
22
23**Stack detection:** Detect language, framework, package manager, auth libraries, API frameworks, deployment targets from filesystem. Research current CVEs and best practices for the detected stack.
24
25**Input:** `$ARGUMENTS` — optional focus areas and scope. Default: full audit, all activated dimensions.
26
27## Rules
28
291. **Always-current standards.** Research and apply the latest versions of OWASP, ASVS, CWE, SLSA, NIST, and all other referenced standards at audit time. Never assume a specific version is current. Use the full standard, not just "Top 10" or "Top 25" subsets.
302. **Run audit tools first.** `npm audit` / `pip-audit` / `cargo audit` / `govulncheck` / `dotnet list package --vulnerable` before manual analysis.
313. **Map attack surface first.** Inputs, outputs, auth boundaries, data flows, integrations.
324. **Severity by exploitability.** Vector reachable? Blast radius? Known exploit/PoC?
335. **Every finding needs evidence.** File:line, CVE/CWE, or tool output.
346. **Remediation must be specific.** Exact code change, library upgrade, or config setting.
357. **All 16 dimensions are the checklist.** Audit every activated dimension. N/A = documented with rationale.
368. **Secrets detection thorough.** Grep for hardcoded keys, tokens, passwords, cloud-specific patterns.
379. **Chat-only output.** All findings in chat. Never create files without explicit user permission.
38
39## Process
40
41### Step 1: Context & Attack Surface
42
431. Read AGENTS.md, run `git status`, detect stack
442. Run audit tools (npm/pip/cargo audit)
453. Research current CVEs for detected framework versions
464. Read `references/dimensions.md` for scope detection rules and the STRIDE threat model
475. Map attack surface using STRIDE: entry points, auth boundaries, data flows, config files
486. Parse arguments for focus areas and determine scope (focused/branch/full)
49
50> 🔐 [Security Audit Step 1: Context & Attack Surface] Stack: [tech]. Surface: [X] entry points, [Y] auth boundaries. Scope: [scope]. Activating dimensions.
51
52### Step 2: Activate & Audit Dimensions
53
54Read `references/dimensions.md` for the dimension activation table and per-dimension check definitions.
55
561. Activate dimensions based on detected project type
572. Audit each activated dimension in priority order (highest risk first): Secrets, Deps, Auth, AppSec, API, Infra, Crypto, BizLogic, Privacy, Network, CI/CD, ClientSide, DoS, Logging, Database, ThirdParty
583. If AI/LLM components detected: also audit against the AI/LLM security checks in dimensions.md
59
60> 🔐 [Security Audit] Activated [X]/16 dimensions. Auditing dimension [N]: [Name]...
61
62### Step 3: Findings Report & Score
63
64Read `references/scoring.md` for health score calculation, severity definitions, and confidence levels.
65
66Read `references/output-template.md` for finding format, summary table, positive observations, improvement plan, fix options, and session-end format.
67
681. Calculate health score using group weights and N/A redistribution
692. Rank findings by severity (Critical → Warning → Suggestion)
703. Present: stack summary, dimension findings with evidence, summary table, positive observations, health score, improvement plan, fix options
71
72### Self-Verification Checklist
73
74> Canonical version in `references/output-template.md`. Brief version here for quick reference.
75
76- [ ] All activated dimensions audited; N/A dimensions documented
77- [ ] Audit tools run (or documented why not)
78- [ ] Every finding has file:line + CWE
79- [ ] Severity reflects exploitability, not theoretical worst case
80- [ ] Remediation verified against current framework docs
81- [ ] No false positives from aspirational standards
82
83### Session End
84
85```
86🔐 [Security Audit Complete]
87
88**Score:** [XX]/100. [X] critical, [Y] warnings, [Z] suggestions across [N] dimensions.
89```
90
91**Next steps (ask user — do not auto-execute):**
92- Save report to `specs/audit-reports/security-<date>.md`?
93- Fix findings? (use fix options from report)
94- Related: `/ai-assist-observability-audit`, `/ai-assist-tech-debt`, `/ai-assist-test-audit`
95
96## Recovery
97
98| Issue | Solution |
99|-------|----------|
100| No package manifest | Audit code-level security; note deps not assessed |
101| Audit tool unavailable | Manual CVE search; note limitation |
102| Monorepo | Audit each workspace; aggregate in summary |
103| No auth system | Note absence — appropriate for CLI, finding for web service |
104| N/A dimensions | Document rationale; redistribute health score weights |
105
106## Important Reminders
107
108**Response format:** Every response starts with `🔐 [Security Audit Step X: Name]`
109
110**Hard rules:** Always-current standards — research latest versions at runtime. Run audit tools first. Evidence for every finding. All 16 dimensions are the checklist.
111
112**Process rules:** Attack surface first with STRIDE. Dimension activation is mandatory. Remediation must be specific — exact code changes, not general advice.
113
114**Related:** `/ai-assist-observability-audit` for telemetry assessment, `/ai-assist-tech-debt` for codebase health, `/ai-assist-test-audit` for test coverage gaps.
gabrielmoreira