threat-modeling — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited threat-modeling (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Produce a threat model for a user-described system using STRIDE-per-element on a data flow diagram.
Deliver in phases, presenting each for user review before proceeding. For "quick" or "draft" requests, produce the full document in one pass.
⬭), data stores (▭▭), external entities (⬜), data flows (→), and trust boundaries (┄┄┄).Present the DFD and asset list. Ask the user to confirm or correct before proceeding.
Trust boundaries to check:
For DFD construction details, see references/01-foundations-and-system-modeling.md.
Apply STRIDE-per-element, starting at trust boundary crossings.
| STRIDE | Threat | Violates | Applies to |
|---|---|---|---|
| S Spoofing | Forged identity | Authenticity | Processes, external entities |
| T Tampering | Modified data | Integrity | Processes, data stores, data flows |
| R Repudiation | Deniable action | Non-repudiability | Processes, data stores\*, external entities |
| I Info disclosure | Data leak | Confidentiality | Processes, data stores, data flows |
| D Denial of service | Unavailability | Availability | Processes, data stores, data flows |
| E Elevation of privilege | Unauthorized access | Authorization | Processes |
\* Only if the store serves as an audit log.
For each element or flow crossing a trust boundary:
Present the threat list. Ask the user to confirm before proceeding.
Example threat row (data flow: User → Web Frontend over HTTPS):
| STRIDE | Element/Flow | Threat | Mitigation |
|---|---|---|---|
| S | User → Frontend | Attacker impersonates user with stolen session token | TLS 1.3, short-lived tokens, MFA |
| I | User → Frontend | Session cookie leaked via XSS | HttpOnly, Secure, SameSite=Lax, strict CSP |
Does this system include AI, LLM, or agentic components? If yes, read references/05-ai-and-agentic-threats.md and apply its additional threat categories.
For STRIDE session details and pitfalls, see references/02-methodologies-and-stride.md.
| Field | Values |
|---|---|
| Likelihood | Low (1) / Medium (2) / High (3) |
| Impact | Low (1) / Medium (2) / High (3) / Severe (4) |
| Exposure | Internal (1) / Authenticated (2) / Public (3) |
| Score | Likelihood × Impact × Exposure |
| Tier | 1–5 Low · 6–12 Medium · 13–24 High · 25+ Critical |
For each threat, assign disposition:
| Disposition | When |
|---|---|
| Mitigate | Reduce likelihood/impact with controls |
| Transfer | Shift to a party better positioned to bear it |
| Accept | Below tolerance; document owner + review date |
| Eliminate | Remove the feature or asset |
For alternative scoring schemes (CVSS, OWASP Risk Rating), see references/03-risk-scoring-and-mitigations.md.
For each threat not accepted or transferred, define a mitigation that is concrete (specific control, not "improve security"), testable, layered (multiple controls for Critical/High), and owned.
| STRIDE | Canonical controls |
|---|---|
| S | MFA, mTLS, FIDO2, token binding, service identity (SPIFFE) |
| T | Input validation, parameterized queries, HMAC/signing, CSP |
| R | Append-only audit logs, signed actions, centralized SIEM |
| I | Encryption (transit + rest), least privilege, data minimization, output sanitization |
| D | Rate limiting, circuit breakers, autoscaling, quotas, WAF, CDN |
| E | Least privilege, authz on every request, separation of duties, sandboxing |
Present mitigations. Ask the user to confirm before producing the final document.
For mitigation catalogs and MITRE ATT&CK/D3FEND integration, see references/03-risk-scoring-and-mitigations.md.
Assemble the final document using this template:
# Threat Model: <System Name>
## Metadata
- **Owner(s):**
- **Last reviewed:** YYYY-MM-DD
- **Next review due:** YYYY-MM-DD
## System Description
<1–3 paragraphs: what the system does, who uses it.>
## Scope
- **In scope:**
- **Out of scope:**
- **Assumptions:**
## Assets
| Asset | Description | C | I | A | Notes |
|---|---|---|---|---|---|
## Actors
| Actor | Legitimate? | Motivation | Capability |
|---|---|---|---|
## Data Flow Diagram
<ASCII DFD with trust boundaries marked.>
## Trust Boundaries
| Boundary | Separates | Controls |
|---|---|---|
## Threats
| ID | STRIDE | Element/Flow | Threat | L | I | E | Score | Tier | Mitigation | Owner | Status |
|----|--------|--------------|--------|---|---|---|-------|------|-----------|-------|--------|
## Accepted Risks
| ID | Description | Rationale | Owner | Review Date |
|---|---|---|---|---|
## Open Questions
-
## Change Log
- YYYY-MM-DD: Initial threat modelLoad on demand for deeper guidance:
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.