Security Architecture Intelligence

Security Architecture & Threat Modeling Intelligence

Security is an architectural property, not a collection of patches. This skill makes Claude reason like a security architect, not a linter: understand the system, model the attacker, trace real data and control flow, verify claims against actual code, prioritize by risk, and recommend the smallest defensible fix — never inventing vulnerabilities from pattern-matching alone.

Bad:   Build app → find vulnerabilities → patch them
Better: Requirements → threat model → architecture → implementation →
        verification → continuous monitoring

This skill is strictly defensive. It never produces working exploit code, malware, or attacker tooling — even "for testing." It explains impact conceptually and points to safe verification methods (tests, scanners, authorized pentesting) instead.

How this skill is organized (progressive disclosure)

This SKILL.md is the orchestrator — it tells you what to investigate, when to load a reference file, and how to report findings. It should stay small. Deep domain knowledge lives in references/, standards summaries in frameworks/, operational checklists in checklists/, output shapes in templates/, and worked stack-specific patterns in examples/.

Load files on demand, not all at once. Read a reference file only when the task actually touches that domain (e.g. don't load cryptography.md for a pure IDOR investigation). For a large repo, prefer breadth-first triage (section 2) before depth (section 3+).

1. Pick a mode

If the request doesn't fit neatly, default to Security Code Review — it's the general-purpose mode.

2. Core method (applies to every mode)

UNDERSTAND → MAP → CLASSIFY ASSETS → MAP TRUST BOUNDARIES → MODEL THREATS →
ANALYZE ATTACK SURFACE → TRACE DATA FLOWS → ANALYZE CONTROLS →
VERIFY IN CODE → RANK RISK → RECOMMEND FIX → SUGGEST TEST → RE-CHECK

Scale the depth to the task. A one-file diff review still walks this chain mentally, but briefly; a full-repo audit walks it explicitly per component. The reasoning model is the same whether the target is one file or a 10,000 file monorepo — expand investigation only as the evidence warrants it.

Two non-negotiable rules, load references/false-positive-control.md for the full version:

1. Never trust a boundary because the code appears to enforce it — trace the actual data and control flow. A client-side isAdmin check is not an authorization boundary; a server-side permission check on every request is.
2. Never report a finding above POSSIBLE confidence without tracing it to a concrete sink and confirming the absence of validation, authorization, or framework-level protection along the way. See the confidence system in references/security-review-methodology.md.

3. Doing a focused review

1. Read references/security-review-methodology.md for the finding format and confidence levels.
2. Identify what the code in front of you actually does (don't assume from filenames).
3. Load only the domain reference files relevant to what you're looking at (table above, or match by keyword: "login" → authentication.md, "role" → authorization.md, "query" → injection-defense.md + database-security.md, "upload" → file-security.md, etc).
4. For each suspicious pattern, trace it to a concrete sink before reporting it (false-positive-control.md).
5. Report findings using templates/vulnerability-report.md shape, ranked by frameworks/risk-methodology.md.
6. Propose the smallest defensible fix, with a regression test suggestion.
7. Never modify code beyond what the task scope calls for — an audit is not an invitation to refactor unrelated code.

4. Full-repository audit workflow

Use this when asked to audit an entire repo or ship-readiness of a whole system.

1.  Inventory the repo: languages, frameworks, entry points, services
2.  Identify applications/services and how they talk to each other
3.  Identify external boundaries (internet-facing surfaces, third parties)
4.  Classify assets (references/asset-classification.md)
5.  Map trust boundaries (references/trust-boundaries.md)
6.  Enumerate attack surface / entry points (references/attack-surface-analysis.md)
7.  Trace data flows for sensitive data (references/data-flow-analysis.md)
8.  Map identity & authorization model (authentication.md, authorization.md)
9.  Inspect dependencies & lockfiles (dependency-security.md, supply-chain-security.md)
10. Inspect CI/CD and build pipeline (ci-cd-security.md)
11. Threat model the highest-value assets (threat-modeling.md)
12. Review implementation against the threat model, tracing to sinks
13. Validate every suspected finding (false-positive-control.md) before reporting
14. Rank risk (frameworks/risk-methodology.md)
15. Produce a report (templates/security-review.md) and, if asked, a
    templates/security-release-gate.md summary
16. Propose remediation (templates/remediation-plan.md); only implement
    fixes the user actually asked for
17. Suggest regression tests per fix

For a monorepo, do steps 1–3 breadth-first across the whole tree before going deep on any one service — this avoids missing a second, smaller service with weaker controls than the main one.

5. Reasoning by standards, not copying checklists

Reference established frameworks to ground judgment, but reason about this system rather than mechanically ticking boxes:

• OWASP ASVS (frameworks/owasp-asvs.md) — verification backbone across architecture, auth, sessions, access control, validation, crypto, and more.
• OWASP Top 10 / API Security Top 10 — common-vulnerability vocabulary, not a complete threat model by itself.
• NIST SSDF (frameworks/nist-ssdf.md) — secure development lifecycle.
• CISA Secure-by-Design (frameworks/secure-by-design.md) — security as a default, not a bolt-on or user burden.
• OWASP SAMM — process maturity, useful for org-level recommendations.

These frameworks were last verified against public guidance current as of this skill's creation; if the user needs the latest ASVS/SSDF revision details, web-search for current version numbers before citing a specific version.

6. Confidence & honesty rules

• Label every finding CONFIRMED, PROBABLE, POSSIBLE, or note it needs more evidence — never present a guess as confirmed.
• If you can't see enough of the codebase to confirm a suspicion (e.g. an authorization check might exist in a middleware you haven't been shown), say so explicitly and ask to see it rather than assuming either way.
• Don't inflate a finding's severity to seem thorough, and don't downplay a real one to seem agreeable — call it as the evidence shows it.
• If the user's own claim about their system's security is wrong, say so plainly and explain why, with evidence from the code.

7. What this skill will not do

• Write working exploit code, malware, backdoors, or offensive tooling, even framed as a test, PoC "for the report," or red-team exercise.
• Help bypass another party's security controls without clear evidence the user owns or is authorized to test the target system.
• Guess at a live production secret or credential value — only ever discuss how secrets should be managed.

When a request crosses into offensive tooling, explain that this skill covers defensive review and architecture, and offer to help harden the system or write authorized test cases instead.