Threat model

Skill Hayatelin/devsecops-skills/skills/threat-model

A security skills pack for Claude Code, Cursor, Codex and Gemini CLI: secrets pre-flight, dependency audit, secret rotation, STRIDE threat modeling, secure code review, Dockerfile hardening and env hygiene.

Install

npx -y skills add Hayatelin/devsecops-skills --skill threat-model

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Produce a lightweight, one-page STRIDE threat model for a feature or system. Trigger when the user says "threat model this", "what could go wrong security-wise", "STRIDE", or before designing/shipping a feature that handles auth, money, PII, uploads, or external input.

SKILL.md

2.9 KB, as published. Nobody here has run it

When to use

Designing a new feature, endpoint, or service before it is built.
A change introduces a new trust boundary: user input, third-party API, file upload, auth flow, payment, or PII.
The user asks "how could an attacker abuse this?" or wants a security design review on a one-page budget.

Process

Scope it. One feature/flow at a time. Get the data flow: actors → entry points → components → data stores → external services.
List assets worth protecting — credentials, PII, money, tokens, the integrity of records, availability of the service.
Draw trust boundaries — where data crosses from less-trusted to more-trusted (browser→API, service→DB, your code→third party). Threats live at these boundaries.
Walk STRIDE at each boundary (table below). For each applicable threat, write one concrete attack and one concrete mitigation.
Rank the threats by rough likelihood × impact and mark which mitigations are must-do-before-ship vs. follow-up.
Output one page — no novel, just the table plus the top risks.

What to check — STRIDE

Spoofing (identity) — can someone pretend to be another user/service? → strong authn, signed tokens, mTLS.
Tampering (integrity) — can data/requests be modified in transit or at rest? → integrity checks, input validation, parameterized queries, signed/immutable records.
Repudiation — can an actor deny an action? → audit logs, signed/append-only trails.
Information disclosure (confidentiality) — can data leak? → encryption in transit/at rest, least-privilege, scrubbed errors/logs, no secrets in responses.
Denial of service (availability) — can it be exhausted/crashed? → rate limits, quotas, timeouts, payload size caps, pagination.
Elevation of privilege (authorization) — can a user do more than allowed? → per-object authz checks, deny-by-default, no trusting client-supplied roles/IDs.

How to fix

Pair every accepted threat with a specific, assignable mitigation (control + where it lives), not a vague "validate input".
Prefer platform/framework controls over hand-rolled ones (the framework's authz, the cloud's KMS, the gateway's rate limiter).
For threats you accept without mitigating, record an explicit risk-acceptance note so it is a decision, not an oversight.

Report back

Deliver a one-page model: a short data-flow description, the asset list, and a STRIDE table (threat → attack scenario → mitigation → priority). Close with the top 3 risks to address before shipping and any explicitly accepted residual risks.