Security Audit Skill

Structured procedures for defensive security assessments, threat modeling, vulnerability identification, and compliance mapping.

Overview

This skill provides systematic workflows for security audits without requiring deep security expertise. Use it to conduct STRIDE threat modeling, check for OWASP Top 10 vulnerabilities, and map security controls to compliance frameworks (SOC2, HIPAA, GDPR, PCI DSS).

Alignment: Defensive-only guidance. This skill does NOT create exploits, attack tools, or offensive security capabilities.

Core Capabilities

1. STRIDE Threat Modeling - Systematic threat identification using STRIDE framework
2. OWASP Top 10 Checks - Vulnerability scanning against OWASP categories
3. Compliance Mapping - Map controls to SOC2, HIPAA, GDPR, PCI DSS
4. Security Review - Code + architecture security assessment

How to Use

Threat modeling:

• "Run STRIDE threat model on this API"
• "Identify security threats in this authentication flow"
• "Create threat model for multi-tenant SaaS"

Vulnerability checks:

• "Check for OWASP Top 10 vulnerabilities"
• "Scan this code for SQL injection risks"
• "Review authentication for broken access control"

Compliance:

• "Map our controls to SOC2 requirements"
• "Check HIPAA compliance for this data handling"
• "Generate GDPR compliance checklist"

Security review:

• "Review security of this OAuth implementation"
• "Assess security architecture of payment service"
• "Identify security risks in this API design"

---

Workflow: STRIDE Threat Modeling

Step 1: System Decomposition

Use the STRIDE template to decompose the system:

python scripts/stride_template.py --system-name <name> --components <component-list>

Manual approach:

1. Identify trust boundaries (user ↔ app, app ↔ database, app ↔ external APIs)
2. List data flows across boundaries
3. Enumerate assets (user data, credentials, PII, financial data)
4. Document actors (users, admins, external systems)

Step 2: Apply STRIDE Categories

For each component/data flow, check STRIDE threats:

Category	Threat	Example	Mitigation
Spoofing	Identity impersonation	User forges JWT token	Strong authentication, token signing
Tampering	Data modification	Attacker modifies API request	Input validation, integrity checks
Repudiation	Deny actions	User claims didn't make purchase	Audit logging, non-repudiation
Information Disclosure	Data leakage	SQL injection reveals PII	Parameterized queries, encryption
Denial of Service	Resource exhaustion	API rate limiting bypass	Rate limiting, quotas
Elevation of Privilege	Unauthorized access	Regular user gains admin	RBAC, least privilege

Use the template:

python scripts/stride_template.py --interactive

Outputs a pre-filled threat model markdown file.

Step 3: Risk Assessment

For each identified threat, assess:

• Likelihood: Low / Medium / High
• Impact: Low / Medium / High
• Risk Level: Likelihood × Impact

Prioritize High/High and High/Medium threats.

Step 4: Recommendations

For each threat, propose:

• Preventive control: Stop attack before it succeeds
• Detective control: Detect attack in progress
• Responsive control: Mitigate damage after attack

Reference: references/stride-mitigations.md for common mitigation patterns.

---

Workflow: OWASP Top 10 Vulnerability Checks

Step 1: Identify Application Type

Determine scan scope:

• Web application (OWASP Web Top 10)
• API (OWASP API Security Top 10)
• Mobile app (OWASP Mobile Top 10)

Step 2: Run Automated Scan

python scripts/owasp_check.py --type <web|api|mobile> --path <codebase-path>

Checks performed:

1. A01:2021 Broken Access Control - Authorization bypass, IDOR
2. A02:2021 Cryptographic Failures - Weak encryption, plaintext secrets
3. A03:2021 Injection - SQL, NoSQL, OS command, LDAP injection
4. A04:2021 Insecure Design - Missing security controls by design
5. A05:2021 Security Misconfiguration - Default configs, verbose errors
6. A06:2021 Vulnerable Components - Outdated libraries, known CVEs
7. A07:2021 Identification/Auth Failures - Weak passwords, session fixation
8. A08:2021 Software/Data Integrity - Unsigned updates, insecure deserialization
9. A09:2021 Security Logging Failures - Missing logs, log injection
10. A10:2021 SSRF - Server-Side Request Forgery

Step 3: Manual Code Review

For critical code paths, manually check:

• Input validation (allowlist > denylist)
• Output encoding (context-aware escaping)
• Authentication flows (MFA, password policies)
• Authorization checks (at every endpoint)
• Cryptography (strong algorithms, proper key management)

Reference: references/owasp-top-10.md for detailed vulnerability descriptions + examples.

Step 4: Remediation Tracking

For each finding:

• Severity: Critical / High / Medium / Low
• Remediation: Specific fix (code change, config update, process change)
• Owner: Who will fix it
• Timeline: When it will be fixed

---

Workflow: Compliance Framework Mapping

Step 1: Select Framework

Choose applicable compliance framework(s):

• SOC2 - Service Organization Control (Type I or Type II)
• HIPAA - Health Insurance Portability and Accountability Act
• GDPR - General Data Protection Regulation
• PCI DSS - Payment Card Industry Data Security Standard

Step 2: Generate Compliance Checklist

python scripts/compliance_mapper.py --framework <soc2|hipaa|gdpr|pci> --output checklist.md

Generates markdown checklist with:

• Control requirements
• Evidence needed
• Implementation status (✅/⚠️/❌)

Step 3: Map Existing Controls

For each requirement, document:

• Control Description: What the requirement mandates
• Current Implementation: How you implement it (or don't)
• Evidence: Where proof exists (docs, code, config, logs)
• Gaps: What's missing

Reference: references/compliance-frameworks.yaml for requirement details.

Step 4: Gap Analysis

Identify:

• Missing controls: Requirements with no implementation
• Partial controls: Requirements partially implemented
• Documentation gaps: Implemented but not documented

Prioritize by:

• Regulatory risk (critical requirements first)
• Implementation effort (quick wins vs long-term projects)

---

Workflow: Security Code Review

Step 1: Scope Definition

Define review scope:

• Files: Which files to review (authentication, authorization, data handling)
• Focus: Specific concerns (input validation, crypto, access control)
• Depth: Surface scan vs deep review

Step 2: Checklist-Based Review

Use security review checklist:

Authentication:

• Strong password policies (length, complexity)
• MFA available for sensitive operations
• Session management (timeout, fixation prevention)
• Credential storage (hashed + salted passwords)

Authorization:

• RBAC or ABAC implemented
• Least privilege enforced
• Access checks at every endpoint
• IDOR prevention (no direct object references)

Input Validation:

• Allowlist validation (not denylist)
• Schema validation for structured data
• File upload restrictions (type, size, content)
• SQL injection prevention (parameterized queries)

Cryptography:

• Strong algorithms (AES-256, RSA-2048+, SHA-256+)
• TLS 1.2+ for transit encryption
• Encryption at rest for sensitive data
• Proper key management (rotation, secure storage)

Reference: references/security-checklist.md for complete checklist.

Step 3: Automated Scanning

# Run dependency scanner
python scripts/dependency_scan.py --path <codebase>

# Output: CVEs in dependencies + recommended upgrades

Step 4: Findings Report

Generate findings report with:

• Finding ID: Unique identifier
• Category: OWASP category or CWE
• Severity: Critical / High / Medium / Low / Info
• Location: File path + line number
• Description: What the issue is
• Recommendation: How to fix it
• Reference: OWASP/CWE link

---

Scripts

stride_template.py

Purpose: Generate pre-filled STRIDE threat model template.

Usage:

# Interactive mode (prompts for system details)
python scripts/stride_template.py --interactive

# Non-interactive mode
python scripts/stride_template.py \
  --system-name "Payment API" \
  --components "API Gateway, Payment Service, Database, Stripe Integration" \
  --trust-boundaries "User → API, API → Database, API → Stripe" \
  --output threat-model.md

Output: Markdown file with STRIDE table + threat categories pre-filled.

owasp_check.py

Purpose: Automated OWASP Top 10 vulnerability scanner.

Usage:

# Scan web application
python scripts/owasp_check.py --type web --path ./src

# Scan API
python scripts/owasp_check.py --type api --path ./api

# Output JSON report
python scripts/owasp_check.py --type web --path ./src --format json > owasp-report.json

Checks:

• Pattern matching for common vulnerabilities (SQL injection, XSS, etc.)
• Dependency scanning (known CVEs)
• Configuration checks (HTTPS, security headers)

Output: Report with findings categorized by OWASP Top 10.

compliance_mapper.py

Purpose: Generate compliance checklist for specific framework.

Usage:

# Generate SOC2 checklist
python scripts/compliance_mapper.py --framework soc2 --output soc2-checklist.md

# Generate HIPAA checklist
python scripts/compliance_mapper.py --framework hipaa --output hipaa-checklist.md

# All frameworks
python scripts/compliance_mapper.py --framework all --output compliance.md

Output: Markdown checklist with checkboxes for each requirement.

dependency_scan.py

Purpose: Scan dependencies for known vulnerabilities.

Usage:

# Scan Python dependencies
python scripts/dependency_scan.py --type python --requirements requirements.txt

# Scan Node dependencies
python scripts/dependency_scan.py --type node --package-json package.json

# Output with severity filter
python scripts/dependency_scan.py --type python --requirements requirements.txt --min-severity high

Output: List of vulnerable dependencies with CVE IDs + recommended versions.

---

References

owasp-top-10.md

Content: Detailed descriptions of OWASP Top 10 vulnerabilities with:

• Vulnerability explanation
• Attack scenarios
• Code examples (vulnerable + secure)
• Remediation guidance
• Testing methods

Use when: Conducting manual code review or explaining findings.

stride-mitigations.md

Content: Common mitigation patterns for each STRIDE category:

• Spoofing → MFA, certificate pinning, token signing
• Tampering → Input validation, integrity checks, HMAC
• Repudiation → Audit logging, digital signatures
• Information Disclosure → Encryption, access control, data minimization
• Denial of Service → Rate limiting, resource quotas, graceful degradation
• Elevation of Privilege → RBAC, least privilege, privilege separation

Use when: Recommending controls for identified threats.

compliance-frameworks.yaml

Content: Structured data for compliance requirements:

soc2:
  cc1.1:
    description: "Organization defines security policies"
    evidence: "Security policy document, approval records"
    category: "Control Environment"
  cc2.1:
    description: "Management monitors system components"
    evidence: "Monitoring dashboards, alert logs"
    category: "Communication"
  # ... more controls

Use when: Mapping controls to compliance requirements.

security-checklist.md

Content: Comprehensive security review checklist covering:

• Authentication & authorization
• Input validation & sanitization
• Cryptography & key management
• Session management
• Error handling & logging
• Security headers (CSP, HSTS, X-Frame-Options)
• API security (rate limiting, CORS, authentication)

Use when: Conducting security code reviews.

---

Assets

threat-model-template.md

Content: Fillable STRIDE threat model template with:

• System diagram placeholder
• STRIDE threat table
• Risk assessment matrix
• Mitigation recommendations

Use when: Creating threat model from scratch (non-automated).

compliance-report-template.md

Content: Fillable compliance audit report template with:

• Executive summary
• Control mapping table
• Gap analysis
• Remediation roadmap

Use when: Documenting compliance audit results.

---

Best Practices

Threat Modeling

• Start with architecture diagram (visual system decomposition)
• Focus on trust boundaries (where privilege changes)
• Prioritize high-impact, high-likelihood threats
• Document assumptions (what's in scope, what's not)

Vulnerability Scanning

• Combine automated + manual review (tools miss logic flaws)
• Test actual exploitability (not just pattern matching)
• Prioritize by risk (critical user-facing > low internal)
• Retest after remediation (verify fix)

Compliance Mapping

• Start with gap analysis (what's missing)
• Document evidence trails (where proof lives)
• Automate where possible (continuous compliance)
• Review annually or after major changes

Security Review

• Use checklists (consistency + completeness)
• Focus on critical paths (auth, data access, payment)
• Review dependencies (known CVEs)
• Document findings clearly (actionable recommendations)

---

Limitations

• Automated scans detect patterns, not all vulnerabilities (false negatives)
• Compliance checklists are guidance, not legal advice (consult compliance team)
• Threat models require system understanding (generic templates need customization)
• Scripts are defensive tools only (no exploit generation)

---

Integration with security-specialist Role

This skill complements the security-specialist agent role:

Role responsibilities:

• Assess security threats (strategic)
• Recommend defensive controls (judgment)
• Risk-based prioritization (decision-making)

Skill responsibilities:

• Execute STRIDE threat modeling (procedural)
• Run OWASP vulnerability checks (automated)
• Generate compliance checklists (templated)

Workflow:

1. User requests security review
2. security-specialist role invoked
3. Role loads security-audit skill
4. Skill provides procedures + scripts
5. Role applies judgment to findings
6. Role makes recommendations to user

---

See Also

• .claude/agents/roles/security-specialist.md - Security specialist role definition
• docs/research/ace/core/alignment-constraints.md - Defensive-only mandate