threat-modeler

name	threat-modeler
description	Describe what this skill helps an agent do.
version	0.1.0
since	2026-07-28
last_modified	2026-07-28
authors	["platform-engineering"]
stability	experimental
min_platform_version	{"codex":"unknown","amazon-q":"unknown","antigravity":"unknown","auggie":"unknown","bob":"unknown","claude-code":"unknown","cline":"unknown","codebuddy":"unknown","continue":"unknown","costrict":"unknown","crush":"unknown","github-copilot":"unknown","gitlab-duo":"unknown","factory":"unknown","forgecode":"unknown","opencode":"unknown","openhands":"unknown","cursor":"unknown","roo-code":"unknown","kiro":"unknown","junie":"unknown","gemini-cli":"unknown","iflow":"unknown","kilocode":"unknown","kimi":"unknown","lingma":"unknown","pi":"unknown","qoder":"unknown","qwen":"unknown","windsurf":"unknown","ollama":"unknown"}
deprecated_since	null
replaces	null
supersedes	[]
changelog	[{"version":"0.1.0","date":"2026-07-28","change":"Initial generated production-ready SDLC / DevSecOps skill"}]

Threat Modeler

Purpose

Identify and prioritize threats for features, services, APIs, and architecture changes using assets, trust boundaries, entry points, data flows, STRIDE, abuse cases, mitigations, controls, and residual risk.

When to use

• A feature or service crosses trust boundaries or handles sensitive assets.
• An API, integration, data flow, or architecture change needs security analysis.
• Abuse cases, attack paths, mitigations, or residual risk need to be documented.
• Threat modeling is required for compliance, review, or release readiness.
• Existing controls are unclear or unverified.

Operating model

1. Define assets, actors, entry points, trust boundaries, and data flows.
2. Apply STRIDE to components, data flows, storage, identities, and integrations.
3. Write realistic abuse cases and attack paths.
4. Map each threat to existing controls, missing controls, tests, and residual risk.
5. Prioritize threats by impact, likelihood, exploitability, and control strength.

Spec-Driven Change Context

• Treat repository specs, ADRs, runbooks, change proposals, design notes, and task files as durable context that outlives a chat session.
• For non-trivial changes, prefer a checked-in change artifact or equivalent proposal/design/tasks record before implementation begins.
• Capture requirement deltas explicitly: added, modified, removed, deprecated, or unchanged behavior.
• Keep implementation tasks traceable to acceptance criteria, affected specs, validation commands, and owners.
• During verification, compare the implementation against the proposal, design decisions, task checklist, and spec deltas.
• After completion, sync or archive completed change artifacts so the repository's source of truth reflects the final behavior.
• If the repository has no spec workflow yet, report the missing artifact and provide a minimal proposal/spec/tasks outline instead of relying on chat-only intent.

Skill-Specific Review Scope

• Assets and sensitivity classification.
• Trust boundaries, privilege transitions, entry points, and attacker-controlled inputs.
• STRIDE threats, abuse cases, and attack paths.
• Mitigations, security controls, assumptions, unresolved threats, and residual risk.
• Security tests and validation for high-risk paths.

Skill-Specific Checklist

• Identify assets and classify their sensitivity.
• Identify trust boundaries and privilege transitions.