1. Ten clusters, one shared vocabulary
Every cyber threat exploits one of ten generic vulnerabilities. That's the whole taxonomy. A developer does not need all of it at once — only enough to stop arguing about what kind of bug this is and start arguing about where it sits in an attack path.
| # | Cluster | Generic vulnerability |
|---|---|---|
| #1 | Abuse of Functions | Scope of designed functionality |
| #2 | Exploiting Server | Server-side code flaws |
| #3 | Exploiting Client | Client-side code flaws |
| #4 | Identity Theft | Weak identity–credential binding |
| #5 | Man in the Middle | Insufficient transit protection |
| #6 | Flooding Attack | Finite resource capacity |
| #7 | Malware | Code-execution capability (FEC) |
| #8 | Physical Attack | Physical accessibility |
| #9 | Social Engineering | Human psychology |
| #10 | Supply Chain Attack | Third-party trust reliance |
Full definitions live on the 10 clusters page. The canonical source is the v2.1 white paper.
- One step = one cluster. Don't label a single action with two clusters. If two feel like they apply, you have a sequence — write it as
#X → #Y. #2vs#3is where the flaw executes, not two different flaw types. Buffer overflow in a request parser =#2. Same bug in a PDF reader =#3. Same CWE, different cluster.
2. Threat modeling that produces attack paths
A design review passes only when every step in a plausible attack path has a named interruption — a control, a check, a circuit-breaker. No interruption, no pass. This is the output the review owes the team: not a matrix, not a diagram — a sequence with holes that somebody actually plugged.
Common sequences worth reviewing on any web product:
- Phishing to execution:
#9 → #3 → #7 - Credential theft to privileged misuse to execution:
#9 → #4 → #1 → #7 - Dependency compromise to execution on install:
#10 ||[dev][@Vendor→@Org]|| → #7 - Abuse-based amplification to volume exhaustion:
#1 → #6
For each step in the path, record the control that stops it. Empty cells are the review's output — they are the risk.
More patterns: attack-path examples. The ||…|| notation for trust-boundary crossings is defined in the white paper §5.
3. Your SDLC, phase by phase
Each phase asks the same question — "which generic vulnerabilities are we addressing now, and how do we know?" — and produces cluster-tagged deliverables. The detailed per-phase tables live on the phase-by-phase lifecycle reference. One-liners:
#1; first attack-path hypotheses.#1, secrets #4, TLS #5, rate-limits #6, artifact integrity #10→#7.4. Pick your path
Four focused deep-dives. Go where your current pain is.
5. Canonical references
- TLCTC v2.1 white paper — axioms, cluster definitions, attack-path notation (
||…||), Section 10 on SSDLC integration. - The 10 clusters — full definitions.
- Bow-tie causality — cause vs. event vs. consequence.
- Attack-path examples — realistic sequences with notation.
- MITRE CWE strategic mapping — the cluster context behind CWE IDs.
Pick one plausible attack path for your product (start with #9 → #4 → #1 → #7). Walk it through your next design review. For every step without a named interruption, you have a finding. That's threat modeling doing work.