Threat modeling

Threat modeling as code,
linked to live findings.

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.

Design assumptions meet findingsthreat
Application data-flow model
Entry point
Trust boundary
Data store
Investigation context
01 / Model

Make the trust boundary explicit.

  • Component
  • Trust boundary

Capture the components and data flows that shape the application threat model.

STRIDE
Threat categories
On every element of the data-flow diagram.
YAML
Model as code
Import, export, review in a pull request.
IaC
Diagram from infrastructure
Terraform, Kubernetes, Docker Compose.
CWE
Linked to findings
Threats point at the vulnerabilities that make them real.
The category

Why do threat models go stale?

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.

Keep the threat model grounded
  1. Application boundary

    Describe the system and its trust boundaries.

  2. Threat scenario

    Review what an attacker can reach and influence.

  3. Supporting finding

    Connect the scenario to the evidence available.

Revisit the model as the application and its relationships change.

How SecurityVault does it

How does SecurityVault keep a threat model current?

Model
Each system is a data-flow diagram of processes, data stores, external entities and the flows between them, with trust boundaries marked. Threats are recorded against STRIDE categories on the element they affect, each with its mitigations.
Start fast
Begin from a template for a common architecture, or convert Terraform, Kubernetes manifests or Docker Compose files into a draft diagram that you review before saving.
As code
Models import and export as YAML, so the threat model can live in the repository next to the system and change through the same pull requests.
Attack trees
Each model renders as an attack tree rooted at the attacker's goal, with threats grouped by STRIDE category and affected component. Diagrams export as SVG.
Review
A review workflow moves each model to approval, and the approval is signed over the model's content. Versioned snapshots and a diff between any two versions show what changed in the design and in its threats.
Evidence

How do threats connect to findings and controls?

A threat model in SecurityVault sits on the same platform as the scanners, so a threat is never only a sentence.

01

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.

02

Control coverage

Threats link to compliance controls, and per-framework control coverage shows which controls the model already addresses and where the gaps are.

03

One programme

Linked findings keep their remediation deadlines. After fixes are verified, the model owner reviews whether the broader threat is mitigated or needs further work.

Platform offerings

What is coming next for threat modeling?

  • Automated threat generation from the data-flow diagram.
FAQ

Frequently asked questions about threat modeling

What does threat modeling as code mean?
The threat model is a YAML document that lives with the system it describes. It can be reviewed in a pull request, versioned and diffed like any other source file, and imported into or exported from SecurityVault without loss.
Which methodology does SecurityVault use?
STRIDE. Each threat is recorded against a STRIDE category (spoofing, tampering, repudiation, information disclosure, denial of service or elevation of privilege) on an element of the data-flow diagram.
Do I have to draw the data-flow diagram by hand?
No. Terraform, Kubernetes manifests and Docker Compose files can be converted into a draft data-flow diagram, which you review and then save as the model. Templates for common architectures are another starting point.
How are threats connected to real vulnerabilities?
Each threat can be linked to scanner findings one at a time, or in bulk by CWE, so a threat about injection points to the injection findings that make it real. Threats link to compliance controls, and control coverage summarises the result per framework.
Can I export a threat model for an auditor or design review?
Yes. A model exports as YAML for the repository and as an SVG diagram for documents, and versioned snapshots show exactly what changed between reviews.

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.

See it on your stack

Bring one Terraform module.

Turn it into a data-flow diagram, record the threats and link them to the findings already open against it.