Security Hardening Audit

Security Hardening Audit

Security bugs are found by structure, not by luck. An ad-hoc "look for vulnerabilities" pass catches the easy ones and misses the systemic ones. A structured multi-pass audit — threat modeling, code review, edge case analysis, test hardening — finds the bugs that matter because each pass is optimized for a different class of vulnerability.

Most codebases have security gaps not because the team is careless, but because security review happens as a single pass with no framework. This workflow runs four distinct passes, each targeting a different vulnerability class, and produces a hardened codebase with evidence — not just a checklist.

When to use this workflow

• Hardening a codebase before a public launch or major release
• Responding to a security incident by auditing the affected areas and beyond
• Preparing for a compliance audit (SOC2, HIPAA, PCI-DSS)
• Running a periodic (quarterly/annual) security review
• Onboarding a new codebase that hasn't had a security audit

When NOT to use this workflow

• Real-time incident response — this is a proactive audit, not a reactive playbook; use your incident response runbook
• Infrastructure/network security — this covers application code; use infrastructure-specific tools for network, firewall, and cloud IAM
• Dependency-only vulnerability scanning — use npm audit, pip-audit, or Snyk directly; this workflow covers code, not just dependencies
• Quick one-file fix for a known vulnerability — just fix it; this workflow is for systematic audits, not patch management

Prerequisites

/plugin marketplace add viktorbezdek/skillstack
/plugin install risk-management@skillstack
/plugin install code-review@skillstack
/plugin install edge-case-coverage@skillstack
/plugin install testing-framework@skillstack

Core principle

Every security finding must produce both a fix and a test that proves the fix works. A finding without a fix is a report that collects dust. A fix without a test is a fix that can regress silently. The audit is not complete when findings are listed — it's complete when every finding has a corresponding test that would catch the vulnerability if it were reintroduced.

Secondary principle: layer the passes by vulnerability class. Each phase targets a different attack surface. Threat modeling finds design-level vulnerabilities (missing auth boundaries, data flow issues). Code review finds implementation-level vulnerabilities (injection, leakage). Edge case analysis finds validation-level vulnerabilities (boundary bypasses, malformed input). Test hardening ensures the fixes stick.

The phases

Phase 1 — threat surface mapping (risk-management)

Load the risk-management skill. Before looking at any code, map the attack surface:

• Entry points — every way data enters the system: API endpoints, form inputs, file uploads, webhooks, message queues, CLI arguments, environment variables
• Trust boundaries — where does trusted data become untrusted? Where does internal data cross to external? Map every boundary.
• Data sensitivity — classify data by sensitivity: PII, credentials, financial data, health data, public data. Each class has different protection requirements.
• Attack vectors per entry point — for each entry point, list the attacks that apply: injection (SQL, XSS, command), authentication bypass, authorization escalation, information disclosure, denial of service, CSRF
• Risk scoring — likelihood x impact for each vector. High-likelihood, high-impact vectors get audited first.

This phase produces the audit scope — a prioritized list of what to examine and in what order. Without it, the code review in Phase 2 has no focus and will spend time on low-risk areas while missing high-risk ones.

Output: a threat model document with entry points, trust boundaries, attack vectors, and prioritized risk scores.

Phase 2 — security-focused code review (code-review)

Load the code-review skill. Run a review focused exclusively on security, using the threat model from Phase 1 to prioritize:

For each high-risk entry point, check:

• Injection — is all user input parameterized before reaching SQL, shell, or template engines? Are there any string concatenation patterns near these boundaries?
• Authentication — can any endpoint be reached without proper auth? Are tokens validated on every request, not just at login?
• Authorization — can user A access user B's data by manipulating IDs or paths? Are authorization checks at the data layer, not just the route layer?
• Information leakage — do error messages expose stack traces, database schemas, or internal paths? Do API responses include fields the client shouldn't see?
• Cryptography — are secrets stored hashed (not encrypted, not plaintext)? Are deprecated algorithms in use (MD5, SHA1 for security purposes)?
• Session management — are sessions invalidated on logout? Do tokens expire? Is there session fixation protection?
• OWASP Top 10 — systematic check against the current OWASP Top 10 for the relevant platform (web, API, mobile)

Document every finding with: location (file + line), vulnerability class, severity (critical/high/medium/low), and a specific remediation.

Output: a findings list with severity, location, and remediation for each vulnerability.

Phase 3 — edge case and validation analysis (edge-case-coverage)

Load the edge-case-coverage skill. This phase catches what the code review misses — vulnerabilities that exist in boundary conditions and validation gaps:

• Input boundaries — maximum length strings, empty strings, null bytes, Unicode edge cases (zero-width characters, right-to-left override), extremely large numbers, negative values where only positive expected
• Type coercion — what happens when a string is passed where a number is expected? When an array is passed where an object is expected? Loose typing languages are especially vulnerable.
• Race conditions — are there time-of-check-to-time-of-use (TOCTOU) vulnerabilities? Can concurrent requests bypass rate limits or create duplicate resources?
• State transitions — can the system be put into an invalid state by calling operations in an unexpected order? (e.g., paying before checkout, accessing before auth)
• Resource exhaustion — can an attacker trigger unbounded memory allocation, file creation, or database writes? Are there missing limits on batch operations?
• Encoding mismatches — do different parts of the system interpret encoding differently? (URL encoding, HTML encoding, JSON encoding — mismatches are injection vectors)

For each gap found, trace whether it's exploitable in context. Not every edge case is a vulnerability — but every unhandled edge case near a trust boundary is a candidate.

Output: an edge case catalog with exploitability assessment for each finding.

Phase 4 — security test hardening (testing-framework)

Load the testing-framework skill. For every finding from Phases 2 and 3, build tests:

Per-finding tests:

• Write a test that reproduces the vulnerability (the "red" state — confirming the bug exists or would exist without the fix)
• Implement the fix
• Verify the test passes with the fix in place
• The test now serves as a regression guard

Systematic security tests:

• Fuzzing — for parsers, deserializers, and input handlers, add fuzz tests that throw random/malformed data at them. Property: the system never crashes, never leaks internal state.
• Property-based tests — for authorization logic: "for any user and any resource, if the user doesn't own the resource and isn't admin, access is denied." For input validation: "for any string input, the output is always properly escaped."
• Negative test suite — a dedicated suite of tests that verify the system rejects what it should: invalid tokens, expired sessions, malformed payloads, unauthorized access attempts

Output: a security test suite with per-finding regression tests, fuzz tests, and property-based invariants.

Phase 5 — remediation and re-audit

With findings from Phases 2-3 and tests from Phase 4:

1. Fix all critical and high findings first — these are blocking for any release
2. Fix medium findings — schedule low findings if not immediately fixable
3. Re-run the Phase 2 code review on the changed code — fixes sometimes introduce new vulnerabilities
4. Re-run the full test suite — confirm all security tests pass, no regressions in functional tests
5. Update the threat model — if fixes changed the architecture (new auth middleware, new validation layer), update the Phase 1 document

The audit is complete when: all critical/high findings are fixed, all fixes have regression tests, the test suite passes, and the threat model reflects the current state.

Output: a remediation report with fix evidence, test results, and updated threat model.

Decision Tree

What's the security situation?
│
├─ Hardening before launch
│   └─ Run all 5 phases — full audit is the point
│
├─ After a security incident
│   └─ Phase 1 (threat model, scoped to affected area) → Phase 2 → Phase 4 → Phase 5
│      skip Phase 3 (edge cases) if the incident was a known vuln class
│
├─ Compliance preparation (SOC2, HIPAA, PCI-DSS)
│   └─ Phase 1 (threat model with compliance controls) → Phase 2 → Phase 4
│      Phase 3 optional — compliance usually needs evidence, not edge cases
│
├─ Periodic security review
│   └─ Phase 1 → Phase 2 only — focused review, not full hardening
│
├─ New codebase, never audited
│   └─ Run all 5 phases — you have no baseline
│
└─ Quick one-file fix for known vulnerability
    └─ Skip this workflow — just fix it directly

Anti-Patterns

Gates and failure modes

Gate 1: the threat model gate. Phase 2 cannot start until Phase 1's threat model exists. Reviewing code without knowing where the risks are produces unfocused reviews.

Gate 2: the findings gate. Phase 4 cannot start until Phases 2 and 3 have produced findings. Writing security tests without findings means testing what you imagine, not what's actually vulnerable.

Gate 3: the regression gate. Phase 5 cannot conclude until every fix has a corresponding test. Fixes without tests will regress.

Failure mode: checklist-only audit. The team runs through OWASP Top 10 as a checklist without mapping it to their specific entry points and data flows. Generic checklists miss application-specific vulnerabilities. Mitigation: Phase 1's threat model ensures the review targets actual risk.

Failure mode: findings without fixes. The audit produces a beautiful report with 47 findings, but nobody fixes them. The report sits in a wiki and the vulnerabilities ship. Mitigation: Phase 5 requires fixes and tests, not just findings.

Failure mode: fix-and-forget. Vulnerabilities are fixed but no regression tests are added. Six months later, a refactor reintroduces the same vulnerability. Mitigation: Phase 4 requires a test for every finding.

Failure mode: scope creep into infrastructure. The audit starts reviewing Kubernetes configs, firewall rules, and cloud IAM policies. Those are important but require different expertise and tools. Mitigation: the scope is application code only, stated in "When NOT to use."

Output artifacts

1. Threat model — entry points, trust boundaries, attack vectors, risk scores
2. Findings list — from code review and edge case analysis, with severity and remediation
3. Security test suite — per-finding regression tests, fuzz tests, property-based invariants
4. Remediation report — fixes applied, test evidence, remaining items with schedule
5. Updated threat model — reflecting post-fix architecture

Related workflows and skills

• For building a new API with security built in from the start, use the api-to-production workflow
• For debugging a specific security incident, use the debug-complex-issue workflow
• For ongoing risk management beyond code, use risk-management directly
• For compliance-specific testing frameworks, use testing-framework with compliance-oriented test patterns

SkillStack Workflows by Viktor Bezdek — licensed under MIT.

Source: viktorbezdek/skillstack — distributed by TomeVault.