Linked findings
Link a threat to the SAST, DAST, API or dependency findings that realise it, one by one or in bulk by CWE. The model then shows which threats have live evidence today.
Threat modeling is the structured practice of identifying what can go wrong in a system's design before an attacker finds it. A team maps how data flows between components and across trust boundaries, records the threats at each point, and decides how each one is mitigated, accepted or tested, so security is designed in rather than patched on.
Capture the components and data flows that shape the application threat model.
Link threats to relevant findings so a model is grounded in technical evidence.
Review the planned control alongside its threat and supporting findings.
Most threat models are a diagram and a spreadsheet produced for a design review, then filed. The system keeps changing and the model does not. Worse, the model never meets the evidence: the threat "attacker injects SQL through the search API" sits in one document while the SQL injection finding on that API sits in a scanner console. A useful threat model is versioned with the system, built from what is actually deployed and connected to the findings that prove or disprove each threat.
SecurityVault keeps the model next to the evidence. The data-flow diagram can start from the Terraform, Kubernetes or Compose files you already deploy, lives as YAML in the repository, and sits on the same platform as the scanners. A threat links to the live findings that realise it and to the controls it supports, and each approval is signed over the model's content. Architects get a model that stays current; auditors get a reviewed, versioned record of design risk.
Describe the system and its trust boundaries.
Review what an attacker can reach and influence.
Connect the scenario to the evidence available.
Revisit the model as the application and its relationships change.
A threat model in SecurityVault sits on the same platform as the scanners, so a threat is never only a sentence.
Link a threat to the SAST, DAST, API or dependency findings that realise it, one by one or in bulk by CWE. The model then shows which threats have live evidence today.
Threats link to compliance controls, and per-framework control coverage shows which controls the model already addresses and where the gaps are.
Linked findings keep their remediation deadlines. After fixes are verified, the model owner reviews whether the broader threat is mitigated or needs further work.
A threat model is only as current as its evidence. The findings it links to come from SAST, DAST, API security and SCA; the diagram can start from the same files IaC security checks; and the controls it covers roll up into continuous compliance. Built for AppSec teams and security engineers who run design reviews. Glossary: threat, control, weakness.
Turn it into a data-flow diagram, record the threats and link them to the findings already open against it.