security-hardening

Security Hardening Skill

Full security audit and hardening pipeline. Covers threat modeling, OWASP Top 10 compliance, dependency scanning, secrets management, auth review, input validation, infrastructure hardening, and verified remediation.

References

• OWASP Top 10 Checklist — all OWASP Top 10 2021 items with check procedures
• Security Headers Reference — HTTP security header recommendations and common mistakes

Pipeline

Phase 1: Threat Modeling

Identify the application's attack surface before auditing code.

1. Map all entry points — HTTP endpoints, WebSocket handlers, CLI commands, message consumers, file upload paths
2. Identify trust boundaries — where untrusted data crosses into trusted zones (user input → server, server → database, service → service)
3. Document data flows — trace sensitive data (credentials, PII, tokens, payment info) from ingress to storage to egress
4. Enumerate threat actors — anonymous users, authenticated users, internal services, supply chain (dependencies), infrastructure operators
5. Classify assets by sensitivity — public, internal, confidential, restricted
6. Produce a threat model summary: entry points, trust boundaries, data classification, and identified risks ranked by likelihood × impact

Phase 2: OWASP Top 10 Audit

Systematically check every OWASP Top 10 2021 category against the codebase. Use the full checklist in references/owasp-checklist.md.

1. For each of the 10 categories (A01–A10), check every item in the checklist
2. For each finding, record: category, file, line, severity (CRITICAL/HIGH/MEDIUM/LOW), description, and recommended fix
3. Cross-reference with the threat model — findings on high-sensitivity data flows escalate one severity level
4. Flag any category with zero findings as "reviewed — no issues found" (not "skipped")
5. Append all findings to docs/SECURITY_REPORT.md

Phase 3: Dependency Scanning

Audit all direct and transitive dependencies for known vulnerabilities.

1. Identify the package manager(s) in use (npm, pip, cargo, go modules, NuGet, Maven, etc.)
2. Run or simulate a dependency audit — check for known CVEs in all dependencies
3. Flag outdated packages — any dependency more than 2 major versions behind or with known CVEs
4. Check license compliance — flag copyleft licenses (GPL, AGPL) in proprietary projects, flag unknown licenses
5. Identify unused dependencies — installed but never imported
6. Record findings with: package name, current version, latest version, CVE IDs (if any), severity, and recommended action (update/replace/remove)

Phase 4: Secrets Audit

Scan for hardcoded secrets and verify secrets management practices.

1. Search the entire codebase for hardcoded secrets — API keys, passwords, tokens, connection strings, private keys, JWTs
2. Check patterns: password=, secret=, api_key=, token=, -----BEGIN, base64-encoded strings in source, .env files committed to git
3. Verify .gitignore includes: .env, .env.*, *.pem, *.key, secrets directories
4. Check git history for previously committed secrets (even if currently removed)
5. Verify secrets are loaded from environment variables or a secrets manager — never from source code
6. Check secret rotation policies — are there expiration dates, rotation mechanisms, or revocation procedures?
7. Flag any finding as CRITICAL — hardcoded secrets are always critical severity

Phase 5: Authentication & Authorization

Audit auth flows, session management, and access control.

1. Review authentication mechanisms — password hashing algorithm (bcrypt/argon2/scrypt, NOT MD5/SHA1), multi-factor auth support, account lockout after failed attempts
2. Check session management — secure cookie flags (HttpOnly, Secure, SameSite), session expiration, session invalidation on logout, token rotation
3. Audit authorization — verify access control checks on every protected endpoint, check for IDOR vulnerabilities, verify RBAC/ABAC implementation
4. Check password policies — minimum length (≥12), complexity requirements, breach database checking
5. Review JWT handling (if applicable) — algorithm validation (reject none), expiration enforcement, audience/issuer validation, key management
6. Verify OAuth/OIDC flows (if applicable) — state parameter usage, PKCE for public clients, redirect URI validation

Phase 6: Input Validation

Check all user input paths for proper sanitization and injection prevention.

1. Trace every path where user input enters the system (request params, headers, body, file uploads, URL paths)
2. Check for SQL injection — verify parameterized queries or ORM usage everywhere, no string concatenation in queries
3. Check for XSS — verify output encoding in templates, CSP headers, no innerHTML/dangerouslySetInnerHTML with user data
4. Check for command injection — verify no shell command construction with user input, use parameterized APIs
5. Check for path traversal — verify file path inputs are sanitized, no ../ sequences reach the filesystem
6. Check for SSRF — verify URL inputs are validated against allowlists, no internal network access from user-supplied URLs
7. Verify file upload security — type validation (not just extension), size limits, storage outside webroot, filename sanitization
8. Check for mass assignment — verify request body fields are explicitly allowlisted, not blindly bound to models

Phase 7: Infrastructure Security

Audit HTTP headers, TLS configuration, CORS policy, and rate limiting.

1. Check all security headers per references/security-headers.md — CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COEP, COOP, CORP
2. Verify TLS configuration — TLS 1.2+ only, strong cipher suites, HSTS with includeSubDomains and preload
3. Audit CORS policy — no wildcard (*) origins in production, credentials mode properly configured, allowed methods/headers restricted
4. Check rate limiting — authentication endpoints, API endpoints, file upload endpoints, password reset
5. Verify error handling — no stack traces or internal details in production error responses, generic error messages for auth failures
6. Check logging — security events logged (failed auth, access denied, input validation failures), no sensitive data in logs (passwords, tokens, PII)
7. Verify cookie security — Secure flag, HttpOnly flag, SameSite attribute, appropriate domain/path scope

Phase 8: Remediation Plan

Prioritize all findings and create an actionable fix list.

1. Aggregate all findings from Phases 2–7
2. Deduplicate — merge findings that share the same root cause
3. Assign final severity: CRITICAL (actively exploitable, data breach risk), HIGH (exploitable with effort), MEDIUM (defense-in-depth gap), LOW (best practice improvement)
4. Sort by severity, then by blast radius (number of affected endpoints/files)
5. For each finding, provide:
   • One-line description
   • Affected file(s) and line(s)
   • Specific remediation steps (code-level, not generic advice)
   • Estimated effort (trivial/small/medium/large)
6. Group into implementation batches: Batch 1 = all CRITICAL, Batch 2 = all HIGH, Batch 3 = MEDIUM + LOW
7. Write the plan to docs/SECURITY_REPORT.md under a ## Remediation Plan section

Phase 9: Verification

Re-scan after fixes to confirm resolution.

1. After Workers implement fixes from the remediation plan, re-run the relevant audit phases
2. For each fixed finding, verify:
   • The specific vulnerability is no longer present
   • The fix did not introduce new vulnerabilities
   • Existing tests still pass (no regressions)
3. Update docs/SECURITY_REPORT.md — mark resolved findings as ✅, note verification date
4. Any finding that persists after a fix attempt escalates one severity level
5. Produce a verification summary: total findings, resolved, remaining, new (if any)

Severity Definitions

Severity	Definition	SLA
CRITICAL	Actively exploitable, immediate data breach or system compromise risk	Fix before merge
HIGH	Exploitable with moderate effort or insider knowledge	Fix within current sprint
MEDIUM	Defense-in-depth gap, requires chained vulnerabilities to exploit	Fix within next sprint
LOW	Best practice improvement, minimal direct risk	Track in backlog

Output

All findings are appended to docs/SECURITY_REPORT.md using the project's report template format. The Security Agent owns this file. Each audit session adds a dated section with findings, remediation plan, and verification status.