Security Audit Context Kit

Comprehensive security audit framework that provides structured methodologies for code review, infrastructure assessment, compliance checking, and vulnerability documentation in authorized security testing contexts.

When to Use This Skill

Choose Security Audit Context when:

• Conducting authorized security code reviews of applications
• Assessing infrastructure configurations for security weaknesses
• Performing compliance audits (OWASP, CIS, SOC2, PCI-DSS)
• Building security assessment reports for stakeholders
• Establishing security baselines for new projects

Consider alternatives when:

• Need automated vulnerability scanning — use DAST/SAST tools
• Performing penetration testing — use specialized pentest frameworks
• Need continuous monitoring — use SIEM/CSPM solutions

Quick Start

Copy
# Activate security audit toolkit
claude skill activate precision-security-audit-context-kit

# Audit application code
claude "Security audit the authentication module in src/auth/"

# Infrastructure review
claude "Review the Kubernetes manifests in k8s/ for security best practices"

Example Audit Checklist

Copy
## Application Security Audit Checklist

### Authentication & Authorization
- [ ] Passwords hashed with bcrypt/argon2 (cost factor >= 10)
- [ ] Session tokens are cryptographically random (>= 128 bits)
- [ ] Multi-factor authentication available for privileged accounts
- [ ] OAuth/OIDC state parameter validated against CSRF
- [ ] JWT tokens have reasonable expiration (< 24h)
- [ ] Role-based access control enforced at API level, not just UI

### Input Validation
- [ ] All user input validated server-side (not just client-side)
- [ ] SQL queries use parameterized statements
- [ ] HTML output properly escaped (context-aware encoding)
- [ ] File uploads restricted by type, size, and stored outside webroot
- [ ] API rate limiting on sensitive endpoints

### Data Protection
- [ ] Sensitive data encrypted at rest (AES-256)
- [ ] TLS 1.2+ enforced for all connections
- [ ] PII logged only when necessary, masked in non-production
- [ ] Database credentials not hardcoded in source
- [ ] Secrets managed via vault, not environment variables in code

Core Concepts

Audit Methodology

Phase	Activities	Output
Scoping	Define systems, boundaries, and compliance requirements	Audit scope document
Reconnaissance	Understand architecture, data flows, trust boundaries	Architecture diagram
Assessment	Test controls against checklist and known vulnerability patterns	Finding worksheets
Analysis	Evaluate risk severity, exploitability, and business impact	Risk matrix
Reporting	Document findings with evidence, impact, and remediation	Audit report
Verification	Confirm remediation effectiveness through retesting	Retest results

Risk Severity Matrix

Severity	CVSS Range	Description	SLA
Critical	9.0 - 10.0	Immediate exploitation risk, data breach likely	24 hours
High	7.0 - 8.9	Significant risk requiring prompt remediation	7 days
Medium	4.0 - 6.9	Moderate risk with mitigating factors	30 days
Low	0.1 - 3.9	Minor risk with limited impact	90 days
Info	0.0	Best practice recommendation, no direct risk	Backlog

Copy
// Security finding documentation template
interface SecurityFinding {
  id: string;                    // AUDIT-2024-001
  title: string;                 // "SQL Injection in User Search"
  severity: 'critical' | 'high' | 'medium' | 'low' | 'info';
  cvss: number;                  // 8.6
  category: string;              // "Injection"
  owaspRef: string;              // "A03:2021"
  location: string;              // "src/api/users.ts:45"
  description: string;           // What was found
  impact: string;                // Business impact
  evidence: string;              // Proof/reproduction steps
  remediation: string;           // How to fix
  references: string[];          // CWE, CVE, documentation links
}

Configuration

Parameter	Description	Default
audit_standard	Compliance standard: owasp, cis, pci, soc2, custom	owasp
severity_threshold	Minimum severity to include in report	low
include_evidence	Attach evidence screenshots and logs	true
output_format	Report format: markdown, html, pdf, json	markdown
risk_rating	Risk rating system: cvss, qualitative, custom	cvss
retest_tracking	Track remediation and retest status	true

Best Practices

1. Define scope and rules of engagement before starting — Document which systems are in scope, testing windows, escalation contacts, and any off-limits areas. Written authorization prevents legal issues and ensures the audit stays focused on agreed objectives.

2. Follow the OWASP Testing Guide systematically — Use OWASP WSTG as your baseline checklist rather than ad-hoc testing. Systematic methodology ensures consistent coverage and makes it easy to track which tests have been completed across audit cycles.

3. Rate findings by business impact, not just technical severity — A medium-severity vulnerability in a payment processing system may warrant higher priority than a high-severity finding in an internal documentation tool. Context matters more than CVSS scores alone.

4. Provide actionable remediation guidance with code examples — Each finding should include specific fix recommendations with code snippets in the project's language and framework. Generic advice like "validate input" is unhelpful — show exactly what parameterized queries or encoding functions to use.

5. Track findings through remediation and retest — An audit report is only valuable if findings get fixed. Maintain a findings tracker with status, owner, and remediation deadline. Schedule retesting to verify fixes actually resolve the vulnerability without introducing new issues.

Common Issues

Audit scope is too broad, resulting in superficial coverage of all areas. Prioritize by risk. Focus deep testing on authentication, authorization, and data handling first. Use automated scanning for broad coverage of lower-risk areas. A thorough audit of critical paths is more valuable than shallow testing of everything.

Development team disputes finding severity or rejects remediation recommendations. Provide clear evidence including reproduction steps, impact analysis, and industry standards references. Use CVSS scoring for objective severity assessment. Offer multiple remediation options ranked by effort and risk reduction to give teams flexibility in their approach.

Compliance requirements conflict with development velocity. Build security checks into the CI/CD pipeline so compliance is verified automatically. Use pre-commit hooks for secrets detection, SAST tools in pull request checks, and infrastructure-as-code scanning in deployment pipelines. Automated checks catch issues early when they're cheapest to fix.