Threat Model Analyst
Run evidence-based threat modeling on code and configs so you flag real security gaps instead of false positives from missing platform context.
Overview
Threat Model Analyst is an agent skill most often used in Ship (also Build) that applies an evidence-based security methodology so agents only flag threats confirmed in code or configuration.
Install
npx skills add https://github.com/github/awesome-copilot --skill threat-model-analystWhat is this skill?
- Mandatory verify-before-flag rule with three-step confirmation before any finding
- Checklist of security infrastructure (Sentry, mesh, OPA, Vault, IdP) before claiming controls are absent
- Platform-default literacy for Dapr mTLS, Kubernetes RBAC, Istio modes, and Azure encryption
- Explicit configuration states: disabled versus unset versus implicitly secure defaults
- Evidence-quality bar requiring specific config or code proof for every reported gap
- Three-step verification workflow before any security gap is flagged
- Five infrastructure categories checked before claiming missing security (CA, mesh, policy, secrets, identity)
Adoption & trust: 1k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Automated or naive security reviews flood you with false positives because they treat missing config as a vulnerability without checking platform defaults and installed controls.
Who is it for?
Indie developers threat-modeling microservices, Dapr or Kubernetes apps, or cloud-backed SaaS before release or after major architecture changes.
Skip if: Replacing formal penetration tests, compliance sign-off, or unattended bulk scanning when you will not manually validate agent conclusions.
When should I use this skill?
User requests threat modeling, security gap analysis, or architecture review where findings must be proven in config or code rather than inferred from absence.
What do I get? / Deliverables
You get a threat-oriented write-up where each finding is backed by proof, implicit controls are documented as controls, and only verified gaps enter your remediation list.
- Evidence-backed threat findings list
- Documented security controls versus verified gaps
- Platform-default notes where implicit protection applies
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the methodology is framed as pre-release security analysis and threat-model quality gates before you launch. Security subphase matches verify-before-flag rules, control identification, and gap versus default handling typical of threat models and reviews.
Where it fits
Map Dapr, Vault, or OIDC components in a new microservice repo before assuming TLS is missing.
Produce a pre-launch threat model that separates disabled mTLS from permissive mesh defaults.
Re-run analysis after a control-plane upgrade to see whether previously flagged gaps are now explicitly disabled settings.
How it compares
Use as a disciplined analysis playbook instead of raw linter or SAST output that cannot reason about mesh mTLS or default cloud encryption.
Common Questions / FAQ
Who is threat-model-analyst for?
It is for solo and small-team builders who want Copilot-class or other agents to perform structured threat modeling with verification rules suited to modern platforms.
When should I use threat-model-analyst?
Use it in Ship security reviews before launch, when revisiting architecture in Build backend work, or whenever you need a evidence-based pass over configs for TLS, RBAC, secrets, and policy gaps.
Is threat-model-analyst safe to install?
It is analysis guidance only and does not execute exploits; review the Security Audits panel on this page and treat all severity calls as draft until you validate evidence in your repo.
SKILL.md
READMESKILL.md - Threat Model Analyst
# Analysis Principles — Security Analysis Methodology This file contains ALL rules for how to analyze code for security threats. It is self-contained — everything needed to perform correct, evidence-based security analysis is here. --- ## ⛔ CRITICAL: Verify Before Flagging **NEVER flag a security gap without confirming it exists.** Many platforms have secure defaults. ### Three-Step Verification 1. **Check for security infrastructure components** before claiming security is missing: - Certificate authorities (Dapr Sentry, cert-manager, Vault) - Service mesh control planes (Istio, Linkerd, Dapr) - Policy engines (OPA, Kyverno, Gatekeeper) - Secret managers (Vault, Azure Key Vault, AWS Secrets Manager) - Identity providers (MISE, OAuth proxies, OIDC) 2. **Understand platform defaults** — research before assuming: - Dapr: mTLS enabled by default when Sentry is deployed - Kubernetes: RBAC enabled by default since v1.6 - Istio: mTLS in PERMISSIVE mode by default, STRICT available - Azure: Many services encrypted at rest by default 3. **Distinguish configuration states**: - **Explicitly disabled**: `enabled: false` → Flag as finding - **Not configured**: No setting present → Check platform default first - **Implicitly enabled**: Default behavior is secure → Document as control, not gap ### Evidence Quality Requirements For every finding: - Show the specific config/code that proves the gap (not just absence of config) - For "missing security" claims, prove the default is insecure - Cross-reference with platform documentation when uncertain --- ## Security Infrastructure Inventory Before STRIDE-A analysis, identify ALL security-enabling components present in the codebase: | Category | Components to Look For | Security They Provide | |----------|----------------------|----------------------| | Service Mesh | Dapr, Istio, Linkerd, Consul Connect | mTLS, traffic policies, observability | | Certificate Management | Sentry, cert-manager, Vault PKI | Automatic cert issuance/rotation | | Authentication | MISE, OAuth2-proxy, Dex, Keycloak | Token validation, SSO | | Authorization | OPA, Kyverno, Gatekeeper, RBAC | Policy enforcement | | Secrets | Vault, External Secrets, CSI drivers | Secret injection, rotation | | Network | NetworkPolicy, Calico, Cilium | Microsegmentation | **If these components exist, their security features are likely active unless explicitly disabled.** --- ## Security Analysis Lenses Apply these frameworks during analysis: - **Zero Trust**: Verify explicitly, least privilege, assume breach - **Defense in Depth**: Identify missing security layers - **Abuse Cases**: Business logic abuse, workflow manipulation, feature misuse --- ## Comprehensive Coverage Requirements **Do NOT truncate analysis for larger codebases.** All components must receive equal analytical depth. ### Sidecar Security Analysis ⚠️ **Sidecars (Dapr, MISE, Envoy, etc.) are NOT separate components in the DFD** — they are co-located in the same pod as the primary container (see diagram-conventions.md Rule 2). However, sidecar communication MUST still be analyzed for security vulnerabilities. **How to analyze sidecar threats:** - Sidecars with distinct threat surfaces (e.g., MISE auth bypass, Dapr mTLS) get their own `## Component` section in `2-stride-analysis.md` — but are NOT separate DFD nodes (see diagram-conventions.md Rule 2) - Use the format: threat title includes the sidecar name, e.g., "Dapr Sidecar Plaintext Communication" - Common sidecar threats: - **Information Disclosure (I):** Dapr/MISE sidecar communicating with main container over plaintext HTTP within the pod - **Tampering (T):** Dapr pub/sub messages not signed or encrypted - **Spoofing (S):** MISE token validation bypass if sidecar is compromised - **Elevation of Privilege (E):** Sidecar running with elevated privileges that the main container doesn't need - CWE mapping: CWE-319 (Cleartext Transmission), CWE-311 (Missi