determine-threat-model

Threat modeling a repository involves identifying the component's purpose, mapping untrusted entry points like HTTP endpoints and CLI arguments, documenting trust boundaries and auth assumptions, and tracing sensitive data flows. The result is written as a structured Security Threat Model section in implementation_plan.md.

Evaluate each finding against the threat model: check whether the flagged code is reachable from an untrusted entry point, whether existing auth or trust boundaries mitigate the risk, and whether it is exploitable in the actual deployment context. Classify it as True Positive, False Positive, or Needs Manual Review.

A threat model should include a component overview, a table of entry points with trust and validation status, authentication and authorization assumptions, sensitive data paths, privileged actions with their guards, priority review areas, and dispositions for scanner findings.

Threat modeling is not appropriate for general code modifications or non-security tasks. It is intended for security reviews, scanner finding triage, and producing security overviews of new or unfamiliar components.

It ranks review areas by risk: untrusted input with insufficient validation first, then privileged actions like shell execution and file I/O, then trust boundary crossings without auth checks, and finally sensitive data handling. Downstream skills read this context to prioritize fixes and audit reports.