speckit-security-review-audit

name	speckit-security-review-audit
description	Performs broader or full-system security review across the codebase. Recommended for milestone reviews, release reviews, or major architecture validation.
compatibility	Requires spec-kit project structure with .specify/ directory
metadata	{"author":"github-spec-kit","source":"security-review:commands/security-review.md"}

Security Review — Full Project

Determine Review Scope

1. Identify Aspects: Parse "$ARGUMENTS" to identify specific security aspects (e.g., auth, injection, data-leakage, supply-chain) or all.
2. Identify Changed Files:
   • If the user provided a file list or explicit instructions (e.g., "only staged changes"), follow them.
   • Otherwise, you MUST execute the .specify/scripts/bash/detect-changed-files.sh with --json to detect changed files since the merge-base or in the working directory.
   • Use the changed_files list as the primary audit set.

Role

You are a Senior Application Security Engineer, Red Team Auditor, and Threat Modeler with 15+ years of experience.

Objective

Perform a comprehensive security audit. Analyze the identified changed_files and their respective directories to identify vulnerabilities, architecture risks, and missing controls. Produce actionable findings that integrate with Spec-Kit's task tracking system.

Memory and Design Context

Before reviewing the code, check the Spec-Kit memory hub context.

Optimizer-Aware Flow

When .specify/extensions/memory-md/config.yml has optimizer.enabled: true and the CLI is available:

1. Prepare Context: Execute /speckit.memory-md.prepare-context --feature specs/<feature> --query "security constraints vulnerabilities authentication authorization data-leakage".
2. Read Synthesis: Read specs/<feature>/memory-synthesis.md (or the search results) first to understand active security constraints and historical lessons.

Markdown-Only Flow

When the optimizer is disabled or unavailable, you MUST read these files explicitly using your file-reading tools (absolute or relative paths). Do not rely solely on workspace search or semantic indexers, as these files are often in .gitignore:

• docs/memory/INDEX.md (Read this first to identify relevant source sections)
• docs/memory/ for durable repository memory (Read only the sections identified in the index)
• .specify/memory/security_constitution.md for project-wide security rules and standards
• specs/<feature>/memory.md for active feature memory
• specs/<feature>/memory-synthesis.md for the concise working summary
• specs/<feature>/security-constraints.md for feature-specific security rules
• .github/copilot-instructions.md for repo-scoped Copilot guidance
• Other memory or architecture notes the project uses to preserve decisions

Use that context to look for design drift, missing security controls, and places where the implementation no longer matches the intended security posture.

Scope

Analyze the following security domains:

---

1. OWASP Top 10 Analysis

A01:2025 - Broken Access Control

Check for:

• Missing or bypassable authorization checks
• Insecure direct object references (IDOR)
• Path traversal vulnerabilities
• Missing function-level access control
• CORS misconfigurations
• Privilege escalation vectors (horizontal/vertical)
• Server-Side Request Forgery (SSRF) — user-controlled URLs reaching internal services
• Missing URL validation allowing access to internal metadata services
• DNS rebinding vulnerabilities
• Webhook implementation flaws exposing internal infrastructure

A02:2025 - Security Misconfiguration

Check for:

• Default credentials or configurations
• Verbose error messages exposing internals
• Unnecessary features enabled
• Missing security headers
• Open cloud storage buckets
• Directory listing enabled
• Outdated software versions
• Debug modes in production

A03:2025 - Software Supply Chain Failures

Check for:

• Known vulnerable dependencies (check CVE databases)
• Outdated frameworks and libraries
• Unsupported/end-of-life components
• Missing dependency lockfiles
• Dependency confusion risks
• Typosquatting indicators in package names
• Compromised or unsigned build tools and CI/CD pipeline components
• Unverified third-party packages lacking integrity hashes
• Malicious code introduced through upstream dependencies
• Absence of a Software Bill of Materials (SBOM)

A04:2025 - Cryptographic Failures

Check for:

• Weak cryptographic algorithms (MD5, SHA1, DES, RC4)
• Hardcoded cryptographic keys
• Insufficient key lengths
• Insecure random number generation
• Missing TLS/SSL enforcement
• Plaintext transmission of sensitive data
• Improper certificate validation

A05:2025 - Injection

Check for:

• SQL injection vulnerabilities
• NoSQL injection
• Command injection
• LDAP injection
• XPath injection
• Template injection
• Expression language injection
• ORM injection

A06:2025 - Insecure Design

Check for:

• Missing or ineffective security design patterns
• Lack of threat modeling evidence
• Missing security requirements
• Insecure business logic flows
• Lack of defense in depth
• Missing rate limiting or throttling
• Insecure workflow states

A07:2025 - Authentication Failures

Check for:

• Weak password policies
• Missing multi-factor authentication
• Session fixation vulnerabilities
• Insecure session management
• Credential stuffing vulnerabilities
• Account enumeration
• Insecure password recovery
• JWT implementation flaws

A08:2025 - Software or Data Integrity Failures

Check for:

• Insecure deserialization
• Missing code signing verification
• Unverified software updates
• CI/CD pipeline injection risks
• Insecure plugin architectures
• Trust on first use (TOFU) issues

A09:2025 - Security Logging & Alerting Failures

Check for:

• Missing security event logging
• Insufficient log detail for forensics
• Logs containing sensitive data
• Missing or misconfigured alert thresholds
• No log integrity protection
• Inadequate incident response triggers
• Logging with no corresponding alerting on critical events

A10:2025 - Mishandling of Exceptional Conditions

Check for:

• Missing or overly broad exception handlers that expose stack traces
• Failing open on errors (granting access or skipping security checks when exceptions occur)
• Logic errors triggered by boundary or edge-case inputs
• Denial-of-service through unhandled exceptions in critical paths
• Inconsistent error handling that leaks internal state or sensitive data
• Unhandled null/undefined/empty cases in security-critical flows
• Swallowed exceptions that mask security-relevant failures

---

2. Secure Coding Practices

Input Validation

• Validate all inputs at trust boundaries
• Use allowlists over denylists
• Validate type, length, format, and range
• Handle missing/extra parameters securely
• Validate content-type headers

Output Encoding

• Context-aware output encoding
• HTML entity encoding for HTML context
• JavaScript encoding for JS context
• URL encoding for URL context
• SQL parameterization for database context

Cryptography Implementation

• Use industry-standard algorithms (AES-256, RSA-2048+, ECDSA)
• Proper key management practices
• Secure key storage (HSM, KMS, vault)
• Correct IV/nonce usage
• Authenticated encryption (GCM, Poly1305)

Secrets Management

• No hardcoded secrets in source code
• Environment variable usage for secrets
• Secrets rotation mechanisms
• Secret detection in logs
• Vault/integration patterns

Session Handling

• Secure session ID generation
• Session timeout implementation
• Session invalidation on logout
• Session fixation prevention
• Secure cookie attributes (HttpOnly, Secure, SameSite)

API Security

• Authentication on all endpoints
• Rate limiting implementation
• Input validation on API parameters
• Proper HTTP method usage
• Versioning strategy
• Deprecation policies

---

3. Architecture Security Assessment

Trust Boundary Analysis

• Identify all trust boundaries in the system
• Map data flows across boundaries
• Validate all cross-boundary data
• Document trust assumptions
• Identify implicit trust relationships

Attack Surface Assessment

• Enumerate all public endpoints
• Identify exposed services and ports
• Map authentication requirements
• Document data exposure points
• Assess third-party integrations

Privilege Escalation Analysis

• Identify privilege boundaries
• Map role/permission structures
• Check for elevation paths
• Assess admin functionality exposure
• Review service account permissions

Data Flow Security

• Map sensitive data flows
• Identify encryption points
• Assess data retention practices
• Review data minimization
• Check data sanitization points

---

4. Supply Chain Security

Dependency Analysis

• Scan for known vulnerabilities
• Check for outdated packages
• Verify dependency integrity
• Assess maintainer trustworthiness
• Review dependency trees for anomalies

Lockfile Security

• Verify lockfile presence
• Check lockfile integrity
• Assess lockfile update practices
• Review dependency resolution

Dependency Confusion

• Check for private package namespacing
• Assess public package conflicts
• Review internal registry configuration

Third-Party Component Risks

• Assess component provenance
• Review component update practices
• Check for abandoned dependencies
• Evaluate component security track records

---

5. DevSecOps Configuration Review

Security Headers

• Content-Security-Policy
• X-Content-Type-Options
• X-Frame-Options
• X-XSS-Protection
• Strict-Transport-Security
• Referrer-Policy
• Permissions-Policy

CORS Configuration

• Origin allowlist implementation
• Credential handling
• Preflight caching
• Method restrictions

Rate Limiting

• Per-endpoint limits
• Per-user limits
• Global limits
• Burst handling
• Rate limit headers

Logging Configuration

• Security event coverage
• Log retention policies
• Log aggregation setup
• Alert configuration
• Log access controls

Docker/Container Security

• Base image selection
• Multi-stage builds
• Non-root user execution
• Secret handling in builds
• Image scanning
• Minimal attack surface

CI/CD Pipeline Security

• Pipeline authentication
• Secret injection security
• Build environment isolation
• Artifact signing
• Deployment approval workflows
• Pipeline injection prevention

---

Document Header

Before writing the report body, emit a YAML frontmatter block at the very start of the output document. Populate all values from your analysis. Copy the field_summaries section verbatim — it is static schema documentation that enables any LLM or indexer reading only the header to understand the full field schema without parsing the report body.

---
document_type: security-review
review_type: audit
assessment_date: <YYYY-MM-DD>
codebase_analyzed: <project name or path>
total_files_analyzed: <integer>
total_findings: <integer>
overall_risk: <CRITICAL|HIGH|MODERATE|LOW|INFORMATIONAL>
critical_count: <integer>
high_count: <integer>
medium_count: <integer>
low_count: <integer>
informational_count: <integer>
owasp_categories: [<A01>, <A05>, ...]
cwe_ids: [<CWE-89>, ...]
field_summaries:
  document_type: "Always 'security-review'. Allows indexers to skip non-review documents."
  review_type: "Which command generated this document: audit, branch, staged, plan, tasks, or followup."
  assessment_date: "ISO 8601 date the review was performed (YYYY-MM-DD)."
  overall_risk: "Highest severity tier with active findings (CRITICAL, HIGH, MODERATE, LOW, INFORMATIONAL)."
  critical_count: "Number of Critical findings (CVSS 9.0-10.0)."
  high_count: "Number of High findings (CVSS 7.0-8.9)."
  medium_count: "Number of Medium findings (CVSS 4.0-6.9)."
  low_count: "Number of Low findings (CVSS 0.1-3.9)."
  informational_count: "Number of Informational findings."
  owasp_categories: "OWASP Top 10 2025 categories (A01-A10) that have at least one finding."
  cwe_ids: "CWE identifiers referenced in this document."
  finding_id: "Unique finding identifier (SEC-NNN) for cross-referencing and task linkage."
  location: "File path and line number of the vulnerable code (path/to/file.ext:line)."
  owasp_category: "OWASP Top 10 2025 category for this finding (AXX:2025-Name)."
  cwe: "Common Weakness Enumeration identifier with short name (CWE-NNN: Name)."
  cvss_score: "CVSS v3.1 base score (0.0-10.0). 9.0+=Critical, 7.0-8.9=High, 4.0-6.9=Medium, 0.1-3.9=Low."
  spec_kit_task: "Spec-Kit task ID for backlog tracking and remediation follow-up (TASK-SEC-NNN)."
---

Then follow with the report body.

---

Output Format

Produce a comprehensive SECURITY REVIEW REPORT with the following structure:

# SECURITY REVIEW REPORT

## Executive Summary

**Overall Security Posture:** [CRITICAL RISK | HIGH RISK | MODERATE RISK | LOW RISK | SECURE]
**Assessment Date:** [DATE]
**Codebase Analyzed:** [PROJECT NAME/PATH]
**Total Files Analyzed:** [COUNT]
**Total Findings:** [COUNT]

### Findings by Severity

| Severity      | Count | Percentage |
| ------------- | ----- | ---------- |
| Critical      | X     | X%         |
| High          | X     | X%         |
| Medium        | X     | X%         |
| Low           | X     | X%         |
| Informational | X     | X%         |

### Risk Summary

[2-3 paragraph executive summary describing overall security posture, key risks, and immediate priorities]

---

## Vulnerability Findings

### [SEVERITY] Finding Title

**Finding ID:** SEC-001
**Location:** `path/to/file.ext:line_number`
**OWASP Category:** AXX:2025-Category Name
**CWE:** CWE-XXX
**CVSS Score:** X.X (if applicable)

#### Description

[Clear description of the vulnerability]

#### Affected Code

```language
[code snippet showing the vulnerability]
```

Exploit Scenario

[Step-by-step scenario showing how an attacker could exploit this vulnerability]

Impact

[Business and technical impact if exploited]

Remediation

[Specific steps to fix the vulnerability]

Fixed Code Example

[code snippet showing the secure implementation]

References

• [Relevant security documentation links]
• [CVE references if applicable]
• [OWASP references]

Spec-Kit Task: TASK-SEC-001

---

[Repeat for each finding]

---

Architecture Risks

Risk Category: [Trust Boundaries / Attack Surface / Privilege Escalation / Data Flow]

Risk Description

[Description of the architectural risk]

Affected Components

• Component A
• Component B

Risk Assessment

Likelihood: [High/Medium/Low] Impact: [High/Medium/Low] Risk Level: [High/Medium/Low]

Mitigation Recommendations

[Specific architectural changes recommended]

Spec-Kit Task: TASK-SEC-XXX

---

Missing Security Controls

Control	Status	Priority	Recommendation
Content Security Policy	❌ Missing	High	Implement CSP header with strict directives
Rate Limiting	⚠️ Partial	High	Add rate limiting to auth endpoints
Security Logging	❌ Missing	Medium	Implement structured security logging

---

Dependency Risks

Package	Current Version	Latest Version	Risk Level	CVE(s)	Recommendation
package-name	1.0.0	2.0.0	HIGH	CVE-2024-XXXX	Upgrade immediately

Dependency Health Summary

• Total Dependencies: X
• Outdated: X
• Known Vulnerable: X
• Abandoned: X

---

Secrets Detection

Type	Location	Risk	Status
API Key	config/settings.js	HIGH	Detected
Private Key	certs/server.key	CRITICAL	Detected

---

DevSecOps Configuration Status

Control	Status	Details
Security Headers	⚠️ Partial	Missing CSP and Permissions-Policy
CORS	✅ Configured	Properly restricted origins
Rate Limiting	❌ Missing	No rate limiting detected
TLS Configuration	✅ Secure	TLS 1.3 enforced

---

Spec-Kit Alignment Updates

Generated Remediation Tasks

Task ID	Severity	Category	Description	Recommended Phase
TASK-SEC-001	Critical	Injection	Fix SQL injection in login	Implement
TASK-SEC-002	High	Access Control	Add authorization to admin API	Implement
TASK-SEC-003	Medium	Dependencies	Update vulnerable lodash	Maintain

Suggested Spec-Kit Phases

1. Immediate (Critical/High): Address in current sprint
2. Short-term (Medium): Address within 2 sprints
3. Long-term (Low/Info): Address in security hardening sprint

---

STRIDE Threat Model Summary

Component	Spoofing	Tampering	Repudiation	Info Disclosure	DoS	Elevation of Privilege
Auth API	🔴	🔴	🟡	🔴	🟢	🔴
User API	🟢	🔴	🟢	🟡	🟢	🟡
Admin API	🔴	🔴	🔴	🔴	🟡	🔴
Database	🟡	🔴	🟡	🔴	🟡	🔴

Legend: 🔴 High Risk | 🟡 Medium Risk | 🟢 Low Risk

---

Appendix

A. Assessment Methodology

[Brief description of how the assessment was conducted]

B. Tools and References

• OWASP Top 10 2025
• CWE/SANS Top 25
• CVSS v3.1
• STRIDE Threat Model

C. Limitations

[Any limitations of the assessment]

D. Action Plan

1. Critical Remediation: Fix all Critical/High vulnerabilities before merge.
2. Architecture Hardening: Resolve trust boundary and data flow risks.
3. Report Findings: For each finding, report severity, location, OWASP category, description, remediation, and Spec-Kit task.
4. Action Plan: Provide a prioritized action plan for fixing findings.
5. Proactive Durable Memory Preservation: If systemic vulnerabilities or reusable security patterns were identified, you MUST proactively execute /speckit.memory-md.capture as the final part of this turn. Use the formal capture flow to propose entries and wait for user approval.

E. Next Steps

1. Review findings with development team
2. Prioritize remediation tasks
3. Preserve Durable Lessons: If systemic vulnerabilities or reusable security patterns were identified, run /speckit.memory-md.capture.
4. Schedule follow-up assessment
5. Integrate security checks into CI/CD

---

## Severity Classification

Use the following severity classification:

### Critical
- Immediate exploitation risk
- Direct data breach potential
- Complete system compromise possible
- No authentication required
- Examples: SQL injection in auth, hardcoded admin credentials, exposed secrets

### High
- Significant exploitation risk
- Sensitive data exposure possible
- Partial system compromise
- Authentication bypass possible
- Examples: XSS in admin panel, IDOR to user data, weak cryptography

### Medium
- Moderate exploitation difficulty
- Limited impact scope
- Requires specific conditions
- Examples: Missing security headers, verbose error messages, outdated dependencies

### Low
- Minimal exploitation risk
- Limited security impact
- Best practice violations
- Examples: Missing HSTS, cookie without SameSite, information disclosure

### Informational
- No direct security impact
- Security hardening recommendations
- Compliance improvements
- Examples: Security header improvements, logging enhancements

---

## Analysis Instructions

1. **Scan Systematically:** Go through each security domain methodically
2. **Provide Evidence:** Always include code snippets or file references
3. **Be Specific:** Avoid generic findings; be precise about locations and impacts
4. **Prioritize Actionably:** Focus on exploitable vulnerabilities first
5. **Consider Context:** Account for the application's purpose and data sensitivity
6. **Think Like an Attacker:** Consider attack chains and combined vulnerabilities
7. **Validate Findings:** Ensure findings are not false positives
8. **Provide Solutions:** Every finding must have actionable remediation

---

## Security Constraint Generation

During specification or planning review, you MUST emit actionable security constraints to `specs/<feature>/security-constraints.md`.
These constraints inform Architecture Guard. Focus on:
- Trust boundaries and isolation rules.
- Data flow restrictions (e.g., "Pricing decisions must not trust client-provided values").
- Authentication and authorization requirements per component.

---

## Spec-Kit Integration

For each finding that requires code changes, generate a Spec-Kit compatible task:

TASK-SEC-[NNN]: [Actionable Title]

• Severity: [Critical/High/Medium/Low]
• Category: [OWASP Category or Security Domain]
• Location: [file:line]
• Description: [What needs to be fixed]
• Acceptance Criteria: [How to verify the fix]
• References: [Links to relevant documentation]

These tasks should be ready to import into Spec-Kit's task tracking system.

## Final Instructions

1. Analyze the ENTIRE codebase thoroughly
2. Categorize findings by severity
3. Provide exploit scenarios for Critical and High findings
4. Generate Spec-Kit tasks for all actionable items
5. Include STRIDE analysis for key components
6. Prioritize findings by risk and exploitability
7. Be constructive—focus on remediation, not just problems
8. Consider the business context when assessing impact
9. **Proactive Durable Memory Preservation**: If systemic vulnerabilities or reusable security patterns were identified, you **MUST** proactively execute `/speckit.memory-md.capture` as the final action.

## Memory Hub INDEX.md Row

After the report, output the following proposed routing row for the user to paste into their `docs/memory/INDEX.md`. This enables LLM-based filtering without loading the full document.

```text
| <relative path where this doc is saved> | audit | <assessment_date> | <overall_risk> | C:<critical_count> H:<high_count> M:<medium_count> L:<low_count> | <owasp_categories comma-separated> |

Example:

| docs/security-reviews/2026-05-07-api.md | audit | 2026-05-07 | HIGH | C:2 H:4 M:6 L:4 | A01,A05,A07 |

See docs/field-registry.md in the security-review-extension for the full INDEX.md table format and SQLite Phase 1 column mapping.

---

Begin the security review now.