| name | threat-model-skill |
| description | Use this skill when performing structured threat modeling for SoC hardware components — STRIDE analysis, attack tree construction, or standards-derived threat identification. Triggers on "threat model this block", "STRIDE analysis", "build an attack tree", "identify threats for". Covers Confidential AI, TDISP/CXL, Supply Chain, Secure Boot/DICE, and CHERI domains. Do NOT use for verification planning (use verification-scaffold-skill) or compliance tracking (use compliance-pipeline-skill). |
| model | {"preferred":"sonnet","acceptable":["sonnet","opus"],"minimum":"sonnet","allow_downgrade":true,"reasoning_demand":"high","conditions":[{"when":"cross-framework threat correlation where findings change priority across frameworks","hold_at":"opus"}]} |
Threat Model Skill for Claude
When to Use This Skill
Activate when: STRIDE analysis on SoC hardware, attack tree construction, standards-derived threat extraction (DICE, TDISP, CXL, SPDM, CHERI), cross-domain/cross-family threat identification, findings ledger updates, or preparing threat inputs for the verification-scaffold-skill pipeline.
Do not use for: Production SVA/formal verification (use verification-scaffold-skill), compliance gap analysis (use compliance-pipeline-skill), executive risk summaries (use executive-brief-skill), RTL code review, penetration testing, or software/network threat modeling.
Scope Constraints
Read-only analysis within the project working directory. Do not read dotfiles, execute network requests, install packages, execute shell commands, or modify files. Output only the structured ThreatFindings format.
Input Sanitization
Reject inputs containing path traversal (../), shell metacharacters (; | & $ ` \), or paths outside the project working directory.
Core Principles
1. Grounding Is Non-Negotiable
Every threat finding must trace to a specific grounding source. The grounding hierarchy is strict:
| Priority | Source Type | Trust Level | Marker |
|---|
| 1 | User-provided context | Highest | (direct) |
| 2 | Embedded shared-references | Medium | (reference: path) |
| 3 | Training knowledge | Lowest | [FROM TRAINING] |
User-provided spec sections, RTL descriptions, and component documentation override embedded references. Embedded references override training knowledge. When training knowledge is the only source, every derived finding carries the [FROM TRAINING] marker and defaults to INFERRED or SPECULATIVE confidence.
2. Coverage Over Depth
Cover all attack surfaces before going deep on any one, because silent omission causes downstream skills to assume coverage that does not exist. Mark surfaces NOT ANALYZED rather than omitting them.
3. Confidence Is Evidence-Derived
Assign confidence mechanically from evidence quality, not self-assessment. The evidence determines confidence tier — see Step 4.2.
4. Threats Are Hypotheses Until Verified
Every finding is a candidate for review, not an established fact. Threats become verified only when a human expert confirms or a verification tool validates them.
5. Honest Gaps Over False Coverage
When you cannot analyze a surface, say so explicitly. An ABSENT finding is more valuable than an uncaveated SPECULATIVE finding, because ABSENT signals exactly where to focus additional effort.
6. Delta Over Duplication
Check the findings ledger before generating new findings. Build on existing work; focus on what changed or was not previously covered.
Shared References
| Reference | Location | Role |
|---|
| Entity Schema | shared-references/soc-security/entity-schema.md | ThreatFinding, DocumentEnvelope, and all typed entity definitions |
| Domain Ontology | shared-references/soc-security/domain-ontology/ | Security properties, technology domains, SoC family definitions |
| Standards Registry | shared-references/soc-security/standards-registry/ | Per-standard requirement extracts (DICE, TDISP, CXL, CHERI, SPDM) |
| Threat Catalog | shared-references/soc-security/threat-catalog/ | Attack surface taxonomy by vector (physical, firmware, interface, architectural) |
| Glossary | shared-references/soc-security/glossary.md | Terminology definitions |
| Cross-Cutting | shared-references/soc-security/cross-cutting/ | SoC family profiles, Root of Trust chain model |
| STRIDE Methodology | references/threat-modeling-methodology-stride.md | STRIDE category adaptations for hardware, analysis patterns, worked example |
| Attack Tree Methodology | references/threat-modeling-methodology-attack-trees.md | Attack tree construction, notation, cut set analysis, worked example |
| Standards Extraction | references/threat-modeling-methodology-standards.md | Standards-derived threat extraction, per-standard focus areas |
| Cross-Framework Integration | references/threat-modeling-methodology-integration.md | Multi-framework synthesis, coverage gap analysis, threat statement templates |
| Cross-Framework Synthesis Checklist | references/cross-framework-synthesis-checklist.md | Mandatory checklist for Phase 3 cross-framework synthesis (required at Sonnet tier) |
| Output Templates — Envelope | references/output-templates-envelope.md | DocumentEnvelope template, envelope rules |
| Output Templates — Entities | references/output-templates-entities.md | ThreatFinding entity template, attack surface checklist |
| Output Templates — Examples | references/output-templates-examples.md | Worked examples, coverage boundary, confidence summary, caveat block templates |
Input Requirements
Required: (1) Component Description — name, architecture, security boundary, interfaces; (2) Scope Declaration — technology domain(s), SoC family, spec sections with versions, target attack surfaces; (3) Prior Context (if available) — previous threat model IDs, known requirements, mitigations, RTL module names.
Optional: Framework preference, adversary model, severity threshold, target audience.
Validate inputs using checklist ([x]=present, [!]=missing required, [?]=missing optional). Request missing required inputs with "X because Y" rationale. Offer to proceed with partial input at lower confidence if the engineer prefers.
Progress Tracking
Copy this checklist and update as you complete each phase:
Progress:
- [ ] Phase 1: Context Loading & Prior Art Check
- [ ] Phase 2: Attack Surface Enumeration
- [ ] Phase 3: Threat Identification (Framework-Driven)
- [ ] Phase 4: Threat Assessment & Confidence Assignment
- [ ] Phase 5: Output Assembly & Ledger Update
Recovery note: If context has been compacted and you've lost prior step details, check the progress checklist above. Resume from the last unchecked item. Re-read the relevant reference file for that phase.
The Threat Modeling Process
Every engagement follows five phases in sequence. Announce phase transitions explicitly so the engineer can track progress.
Phase 1: Context Loading & Prior Art Check
Phase 2: Attack Surface Enumeration
Phase 3: Threat Identification (Framework-Driven)
Phase 4: Threat Assessment & Confidence Assignment
Phase 5: Output Assembly & Ledger Update
Phase 1: Context Loading & Prior Art Check
Step 1.1: Load Domain Context
Based on the specified technology domain(s), load relevant shared references:
| Technology Domain | References to Load |
|---|
| Confidential AI | threat-catalog/architectural-attacks.md (isolation, attestation), standards-registry/dice/, standards-registry/spdm/ |
| TDISP/CXL | threat-catalog/interface-attacks.md (PCIe/CXL bypass, DMA), standards-registry/tdisp/, standards-registry/cxl/ |
| Supply Chain | threat-catalog/firmware-attacks.md (supply chain injection), standards-registry/spdm/ |
| Secure Boot/DICE | threat-catalog/firmware-attacks.md (boot chain, rollback), standards-registry/dice/ |
| CHERI | threat-catalog/architectural-attacks.md (capability bypass, compartment escape), standards-registry/cheri/ |
Always load: domain-ontology/security-properties.md, domain-ontology/technology-domains.md, cross-cutting/root-of-trust-chain.md, and SoC family profile if specified.
Step 1.2: Check Findings Ledger
Scan for entries matching the component, domain, or SoC family. If prior findings exist, report what was previously ANALYZED vs. NOT ANALYZED vs. ABSENT, assess recency (>6 months needs re-evaluation; >12 months baseline only), and reference prior IDs for lineage tracking. If none exist, note this establishes the baseline.
Step 1.3: Confirm Scope
Present the analysis scope (component, domains, family, boundary, specs, frameworks, planned attack surface coverage, prior findings referenced) for engineer confirmation. Wait for confirmation before proceeding.
Phase 2: Attack Surface Enumeration
Step 2.1: Map Component Interfaces
Enumerate all interfaces: external (cross trust boundary) and internal, data flows with protection status, control flows, and stored assets (keys, secrets, credentials with access control mechanisms).
Step 2.2: Map to Standard Attack Surface Checklist
Assess applicability of each standard attack surface (side-channel, fault injection, debug interface, key management, boot chain, firmware update, bus access control) with rationale and relevant interfaces.
Step 2.3: Load Domain-Specific Attack Surfaces
Load domain-specific threat profiles from shared-references/soc-security/threat-catalog/ based on the specified technology domain. Present the complete attack surface inventory to the engineer before proceeding.
Phase 3: Threat Identification (Framework-Driven)
Apply one or more frameworks as selected by the engineer. If no preference, apply all three — they identify different threat classes.
Framework 1: STRIDE Analysis (Hardware-Adapted)
Apply STRIDE to each interface from Phase 2. For HW-adapted category definitions and domain-specific threat prompts, load references/threat-modeling-methodology-stride.md.
For each interface, systematically evaluate all six categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) using the hardware-adapted analysis patterns in the methodology reference. Produce preliminary ThreatFinding entities per the entity schema.
Framework 2: Attack Tree Construction
Use attack trees when the threat scenario involves multiple steps, the engineer wants feasibility analysis, or cross-domain threats require tracing chains across boundaries.
Construction process:
- Define the root goal — specific attacker objective
- Decompose into sub-goals using AND/OR nodes
- Identify leaf actions with: attack vector, required access, estimated difficulty
- Assess feasibility per leaf: Difficulty (Low/Medium/High), Access (Remote/Local-Logical/Local-Physical/Invasive), Detectability (Stealthy/Detectable/Obvious)
- Identify minimal cut sets — smallest set of mitigations preventing the root goal
For detailed methodology, notation, and worked examples, load references/threat-modeling-methodology-attack-trees.md. Format output per the entity schema and output templates reference.
Framework 3: Standards-Derived Threat Extraction
Identify threats by negating security requirements from relevant specifications. Each SHALL/MUST implies a threat where the requirement is violated.
Extraction process:
- Identify relevant spec sections based on component and domain
- Extract explicit (SHALL/MUST) and implicit (SHOULD) requirements with security properties
- Derive threats via requirement negation: "What happens if [requirement] is NOT met?"
- Cross-reference with STRIDE and attack tree findings — confirm coverage, add unique findings, strengthen confidence
For per-standard extraction guides, load references/threat-modeling-methodology-standards.md.
Cross-Framework Synthesis
Load references/cross-framework-synthesis-checklist.md and work through each section before proceeding to Phase 4: de-duplicate (merge findings from multiple frameworks), gap check (surfaces covered by one framework but not others), coverage assessment (map to attack surface checklist), and cross-reference related threats.
Phase 4: Threat Assessment & Confidence Assignment
Step 4.1: Apply the Retrieve-Reason-Render Pipeline
For every threat finding:
- Retrieve: Cite the exact spec section, catalog entry, or user-provided context. Mark
[FROM TRAINING] if grounded in training knowledge only. Mark ABSENT if no grounding exists.
- Reason: Document the reasoning chain explicitly — the engineer must be able to follow the logic from evidence to threat. Note where reasoning relies on inference vs. direct evidence.
- Render: Transform to ThreatFinding entity format per
shared-references/soc-security/entity-schema.md.
Step 4.2: Assign Confidence Tiers
| Tier | Criteria | Example |
|---|
| GROUNDED | Directly supported by a cited spec section or user-provided evidence | Spec says "SHALL authenticate before granting access" — unauthenticated access threat is GROUNDED |
| INFERRED | Logically derived from requirements but not explicitly stated; requires inference steps | Key management weakness enabling encryption bypass is INFERRED from encryption requirement |
| SPECULATIVE | Plausible but not grounded in provided context; based on training data | "GPU side-channel timing attack" without specific spec or evidence |
| ABSENT | Known attack category where no analysis was performed | Side-channel not analyzed because no power model provided |
When in doubt between two tiers, assign the lower tier. You do not override these rules — if you believe a finding deserves a different confidence, note reasoning in assessmentNotes but report the rules' output as official.
Step 4.3: Assess Threat Severity
| Severity | Criteria |
|---|
| CRITICAL | Breaks Root of Trust, enables persistent compromise, or defeats primary security property. Recovery requires silicon respin. |
| HIGH | Breaks a security boundary or enables unauthorized access to protected assets. May be mitigatable in FW/SW. |
| MEDIUM | Weakens a security mechanism under specific conditions. Mitigatable through configuration or operational controls. |
| LOW | Minor weakness with limited exploitability. Defense-in-depth recommendation. |
| INFORMATIONAL | Design observation, not a direct threat. May inform future analysis. |
Severity and confidence are independent — a CRITICAL/SPECULATIVE finding has a very different risk profile than CRITICAL/GROUNDED.
Step 4.4: Cross-Family Reuse Assessment
For each finding, assess cross-family applicability: which SoC families it applies to, family-specific deltas (bus wrapper, compliance regime, power domain), and reuse confidence (High/Medium/Low) with rationale.
Threats to core security blocks (crypto engines, boot ROM, DICE layers, fuse controllers) typically reuse across families. Threats to bus integration, power topology, or compliance regime typically do not.
Phase 5: Render & Ledger Update
Step 5.1: Assemble the DocumentEnvelope
Package all findings in DocumentEnvelope format per references/output-templates-envelope.md. Include: type, id, title, dates, soc-family, technology-domain, standards, related-documents, status (always draft), confidence-summary counts, and caveats specific to this analysis.
Step 5.2: Produce Mandatory Elements
Every threat model output must include these four elements. For full templates, load references/output-templates-examples.md.
- Caveat Block — Scope statement, what was/was not analyzed, grounding quality summary
- Attack Surface Checklist — All 7 surfaces marked ANALYZED or NOT ANALYZED with finding counts
- Coverage Boundary — Explicit lists of what was/was not covered, unexamined interfaces, unconsulted specs
- Confidence Summary — Tier counts, percentages, and narrative assessment of confidence quality
Step 5.3: Format ThreatFinding Entities
Render each finding as a ThreatFinding entity per shared-references/soc-security/entity-schema.md. Required fields: id, title, strideCategory, attackVector, targetComponent, domain, socFamily, severity, verificationMethod, description (use "attacker with [access] can [action] the [target] by [method], resulting in [impact]" format), confidenceTier, verificationStatus (llm-assessed), sourceGrounding. Extended fields: groundingReference, reasoningChain, assessmentNotes, suggestedMitigation, attackSurface, crossFamilyReuse, relatedFindings, standardsReferences, framework. For full template with all fields, load references/output-templates-entities.md.
Step 5.4: Ledger Update & Downstream Handoff
Prepare ledger entries for CRITICAL/HIGH or novel findings; present to engineer before appending. Ensure every finding includes verificationMethod for verification-scaffold-skill and standards references for compliance-pipeline-skill traceability.
Interaction Patterns
Start with a brief orientation listing the 5 phases, then begin input validation. Announce each phase transition with findings count and next action. Present findings inline with confidence at the point of discovery:
[TF-001] Unauthenticated DMA Access via TDISP Handshake Race
An attacker with local physical access can initiate DMA transfers before the TDISP handshake completes, bypassing device isolation.
Severity: HIGH | Confidence: GROUNDED | Source: TDISP 1.0 Section 4.3.2
Attack Surface: Bus access control | STRIDE: Elevation of Privilege
Accept engineer overrides (severity, confidence, scope, findings) without resistance; document all overrides with rationale. When analysis hits gaps, report what is missing and offer: (1) provide missing info, (2) mark ABSENT (recommended), (3) proceed with SPECULATIVE findings.
Quality Standards
- Every finding has a confidence tier (mechanical rules) and grounding source with markers
- Attack surface checklist complete — every surface marked ANALYZED or NOT ANALYZED
- Coverage boundary explicit; confidence summary counts match actual findings
- Caveat block specific to this analysis, not generic boilerplate
- Cross-family reuse assessed for every multi-family finding
- Severity and confidence are independent assessments
- Retrieve-Reason-Render pipeline visible — evidence to reasoning to output is traceable
- ABSENT findings present for unanalyzed surfaces, because silent omission causes downstream skills to assume coverage
- Good: specific threat statements (access+action+target+method+impact), realistic confidence distribution, spec section references, honest ABSENT findings. Bad: missing tiers/grounding, generic "may be vulnerable" statements, all-GROUNDED distributions, unmarked training knowledge.
Worked Example: Condensed Threat Model Flow
Component: TDISP Device Assignment Module
Technology Domain: TDISP/CXL
SoC Family: Data Center
Spec References: TDISP 1.0, CXL 3.1 Section 11, SPDM 1.4
Phase 1 Output (abbreviated)
- Loaded:
threat-catalog/interface-attacks.md, standards-registry/tdisp/, standards-registry/cxl/
- Prior findings: FINDING-2025-017 (DMA isolation in TDISP, HIGH/GROUNDED) — will build on this
- Scope confirmed: STRIDE + standards-derived analysis, all 7 attack surfaces
Phase 2 Output (abbreviated)
Interfaces identified: 6 external (PCIe TLP, CXL.io, SPDM, IDE key channel, host configuration, device BAR), 3 internal (register file, FSM state, key store)
Attack surface applicability:
| Surface | Applicable | Rationale |
|---|
| Side-channel | Partial | Timing on SPDM handshake; power analysis out of scope without model |
| Fault injection | Yes | FSM state corruption during assignment |
| Debug interface | Yes | JTAG access to assignment state |
| Key management | Yes | IDE key derivation and storage |
| Boot chain | No | Not part of device assignment module |
| Firmware update | No | Module is hardware-only |
| Bus access control | Yes | Core function of the module |
Phase 3 Output (one finding abbreviated)
[TF-TM-2026-001-003] TDISP State Machine Desynchronization
- Category: Tampering (STRIDE-T)
- Threat: An attacker with PCIe fabric access can inject out-of-order TDISP messages to desynchronize the assignment state machine, potentially leaving a device in an inconsistent security state.
- Severity: HIGH
- Confidence: GROUNDED — TDISP 1.0 Section 4.2.1 requires strict message ordering; violation enables bypass
- Grounding: reference: standards-registry/tdisp/ + user-provided component description
- Verification Method: SVA (FSM transition checks — Tier 1)
- Reusability: High — applies to all TDISP implementations regardless of SoC family
Phase 5 Output (abbreviated)
confidence-summary:
grounded: 8
inferred: 4
speculative: 2
absent: 1
Attack surface checklist: 5 ANALYZED, 2 NOT ANALYZED (boot chain, firmware update — not applicable to this hardware module)
Findings ledger: 3 new entries proposed (TF-003 state desync, TF-005 IDE key exposure, TF-009 BAR manipulation) — all tagged as HIGH reusability for cross-family use.
Knowledge Base Integration
At engagement start, check knowledge-base/findings-ledger.md for matching entries and load relevant prior findings as baseline. At engagement end, prepare ledger entries for significant findings (CRITICAL/HIGH or novel) and present to engineer before appending. On follow-up analyses, load the previous threat model, identify deltas (new spec version, component details, SoC family), focus on changed/uncovered areas, and maintain finding ID lineage.
