Security Audit Methodology
Security is not a checklist — it's a posture. This methodology covers systematic evaluation of code, architecture, dependencies, and operational practices for security weaknesses.
The Security Engineer's Domain
| You own |
You don't own |
| Threat modeling — STRIDE, attack trees, trust boundaries |
General code review — that's the reviewer |
| Vulnerability assessment — classification, severity, reproduction |
Performance analysis — that's the debugger |
| Security architecture review — authn/authz, data flow, secrets management |
Operational reliability — that's SRE |
| Dependency analysis — supply chain, known vulnerabilities, license risk |
Compliance certification — that's legal |
| Security testing guidance — fuzzing, SAST/DAST integration |
Incident response execution — that's SRE/on-call |
Reference Files
| Reference |
When to load |
references/threat-modeling.md |
Evaluating a system's attack surface — STRIDE per component, trust boundaries, data flow analysis |
references/vulnerability-classification.md |
Assessing a finding — CVSS scoring, CWE mapping, severity triage, exploitability assessment |
references/security-architecture-dependency-audit.md |
Reviewing authentication (OAuth 2.0, OIDC, SAML, mTLS), authorization (RBAC/ABAC/ReBAC), session management, secrets management, and dependency/supply chain security (SBOM, CVE matching, license analysis, SLSA framework) |
references/testing-and-tooling.md |
Recommending SAST/DAST tools, fuzzing strategies, and security test patterns |
Core Principles
Trust nothing, verify everything — Every input, every boundary, every assumption is a potential attack surface. Default deny, explicit allow.
Defense in depth — No single control is sufficient. Authentication without rate limiting, encryption without key management, input validation without output encoding — each is a vulnerability waiting to chain.
Least privilege — Every component, every user, every process should have exactly the permissions it needs and no more. Over-privilege is the most common security debt.
Understand the attacker's perspective — The question isn't "can this be exploited?" It's "how would an attacker think about this system?" Model their incentives, constraints, and capabilities.
Fix the class, not the instance — One SQL injection means you need parameterized queries everywhere, not just at that one endpoint. A single XSS means review the entire rendering pipeline.
1---2name: security-audit-methodology-23description: Security audit and vulnerability assessment methodology — threat modeling, vulnerability classification, defense-in-depth review, dependency analysis, and security architecture evaluation. Grounded in OWASP, CWE, and STRIDE/LINDDUN frameworks.4license: MIT5---67# Security Audit Methodology89Security is not a checklist — it's a posture. This methodology covers systematic evaluation of code, architecture, dependencies, and operational practices for security weaknesses.1011## The Security Engineer's Domain1213| You own | You don't own |14|---------|--------------|15| Threat modeling — STRIDE, attack trees, trust boundaries | General code review — that's the reviewer |16| Vulnerability assessment — classification, severity, reproduction | Performance analysis — that's the debugger |17| Security architecture review — authn/authz, data flow, secrets management | Operational reliability — that's SRE |18| Dependency analysis — supply chain, known vulnerabilities, license risk | Compliance certification — that's legal |19| Security testing guidance — fuzzing, SAST/DAST integration | Incident response execution — that's SRE/on-call |2021## Reference Files2223| Reference | When to load |24|-----------|-------------|25| `references/threat-modeling.md` | Evaluating a system's attack surface — STRIDE per component, trust boundaries, data flow analysis |26| `references/vulnerability-classification.md` | Assessing a finding — CVSS scoring, CWE mapping, severity triage, exploitability assessment |27| `references/security-architecture-dependency-audit.md` | Reviewing authentication (OAuth 2.0, OIDC, SAML, mTLS), authorization (RBAC/ABAC/ReBAC), session management, secrets management, and dependency/supply chain security (SBOM, CVE matching, license analysis, SLSA framework) |28| `references/testing-and-tooling.md` | Recommending SAST/DAST tools, fuzzing strategies, and security test patterns |2930## Core Principles3132**Trust nothing, verify everything** — Every input, every boundary, every assumption is a potential attack surface. Default deny, explicit allow.3334**Defense in depth** — No single control is sufficient. Authentication without rate limiting, encryption without key management, input validation without output encoding — each is a vulnerability waiting to chain.3536**Least privilege** — Every component, every user, every process should have exactly the permissions it needs and no more. Over-privilege is the most common security debt.3738**Understand the attacker's perspective** — The question isn't "can this be exploited?" It's "how would an attacker think about this system?" Model their incentives, constraints, and capabilities.3940**Fix the class, not the instance** — One SQL injection means you need parameterized queries everywhere, not just at that one endpoint. A single XSS means review the entire rendering pipeline.
magnus919