# Security Architecture Intelligence

> Analyzes codebases for security design flaws, threat modeling gaps: attack surface, auth boundaries, and data flow risks.

- Skill: `rahozosman/security-architecture-intelligence` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add rahozosman/security-architecture-intelligence`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rahozosman/security-architecture-intelligence/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: rahozosman (https://skillmd.com/u/rahozosman)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/rahozosman/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

| User asks for... | Mode | Primary references |
|---|---|---|
| "Is this secure?" / general review | Security Code Review | security-review-methodology, false-positive-control |
| "Audit the whole repo" | Full Security Audit | see Section 4 workflow |
| "Threat model this feature/system" | Threat Model | threat-modeling, trust-boundaries, attack-surface-analysis |
| Login/session/password/MFA work | Authentication Audit | authentication.md, session-security.md |
| Access-control / IDOR / roles | Authorization Audit | authorization.md, multi-tenant-security.md |
| REST/GraphQL/webhook design or review | API Security Audit | api-security.md, injection-defense.md |
| A specific bug report / "can X happen?" | Vulnerability Investigation | false-positive-control.md + the relevant domain file |
| Dependency/package/CI concerns | Supply Chain / CI-CD Audit | dependency-security.md, supply-chain-security.md, ci-cd-security.md |
| "Are we ready to ship?" | Release Security Gate | templates/security-release-gate.md, checklists/production-release.md |
| Encryption, hashing, key handling | Cryptographic Review | cryptography.md, secrets-management.md |
| PII / data handling / GDPR-ish question | Privacy Review | privacy.md, data-flow-analysis.md |

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.