security-threat-model
security-threat-model
Overview
security-and-hardening audits existing code line-by-line against OWASP rules — it answers "does this code follow the security playbook?". This skill operates one level up: it answers "should this code exist, and where is the boundary it crosses?". Threat modeling is the practice of naming the attacker, the assets, the trust boundaries, and the abuse paths before the code is written (and re-asserting them after significant changes).
This is the threat-side counterpart to:
| Phase | Skill | Question |
|---|---|---|
| Pre-design (this skill) | security-threat-model |
What can go wrong? Where? Who? |
| Implementation | security-and-hardening |
Does the code follow the controls? |
| Pre-deploy | security-devsecops / gha-security-review |
Did we lock the supply chain / pipeline? |
| Post-deploy | pre-ship-gate |
Is the deploy actually running safely? |
| Post-incident | security-incident-response |
Contain / recover / postmortem |
Threat model output is a single Markdown file per session — saved at docs/threat-model/<repo-hash>-<date>/threat-model.md (git-tracked project audit log, see Path Convention below) — with concrete file:line citations. The model is only useful if the evidence can be checked in one read — vague narratives get thrown away.