Threat Models

Path: /threat-models · Sidebar: Intelligence → Threat Models

A threat model captures the architecture of an application - its components, trust boundaries and data flows - and enumerates concrete STRIDE threats against it. Unlike a pure modelling tool, apPosture doesn't just describe threats: it grounds them in evidence (parsed infrastructure, source code and confirmed runtime findings) and feeds the gaps back into scanning and the CI gate.

Model → prove → enforce. Most tools stop at "model". apPosture models the attack surface, proves which threats are real with DAST/SAST/IaC evidence, then blocks risky releases at the gate.

Generating a model

1. Open Threat Models and pick an application.
2. Click Generate. Choose which sources to use:
   • Source code - static ingest of the app's connected repos (entry points, handlers, data access).
   • DAST findings - the app's confirmed runtime findings (these prove threats and mark them covered).
   • IaC - Terraform, CloudFormation, Kubernetes, Helm and docker-compose are parsed into real components and exposures.
3. The model is synthesised in the background (local LLM) and the page refreshes to ready.

If there's no source or DAST yet, apPosture falls back to a black-box model from the app's external surface and recon fingerprint, so you always get a starting point.

You can also import an existing diagram (see Import & export) and let apPosture refine it with code, IaC and findings.

Infrastructure-as-Code grounding

apPosture parses your IaC instead of guessing the architecture. From Terraform / CloudFormation / Kubernetes / Helm / docker-compose it extracts:

• Typed components - datastores, queues, compute, external entry points.
• Trust zones - internet, DMZ, internal, data.
• Public exposure (proven facts) - a security group open to 0.0.0.0/0, an aws_db_instance with publicly_accessible = true, a public-read S3 bucket, a Kubernetes LoadBalancer/Ingress, or a non-loopback published compose port.

Each parsed component carries its evidence (main.tf (aws_db_instance.orders)) and is merged into the architecture deterministically. So a trust boundary like "the orders database is reachable from the internet" is a parsed fact, not a model hypothesis. Public components are flagged 🌐 and outlined in red on the diagram.

Evidence & confidence

Every threat carries a confidence badge - the honesty bar that stops the model over-claiming:

Confidence	Meaning
proven	Confirmed by a real DAST finding that matches the threat's endpoint. The only authoritative "proven" signal - the model can never self-declare it.
likely	Grounded in source (a cited file:line) or a parsed IaC component, but not confirmed at runtime.
inferred	A model hypothesis with no supporting evidence yet.

Each threat also lists its evidence - 🎯 dast (a confirmed finding), 📐 iac (a parsed resource) or 💻 source (a code location) - plus its CWE(s) and the compliance controls it touches.

Attack paths

apPosture chains per-component threats into reachability-weighted attack paths over the data-flow graph: a public/internet entry point → … → a datastore. A publicly-exposed datastore is a one-hop path on its own. Paths are ranked by the worst severity on the path, whether any threat on it is proven, whether the entry is public, and whether it reaches data - surfacing the shortest real route to your crown-jewel data first.

Blind spots

The inverse of coverage - threats with no assurance:

• untested - DAST-testable but never scanned → run a scan.
• unverified - critical/high but confidence is not yet proven.
• unmitigated - open, with no mitigation and not covered.

Blind spots close the loop: critical/high unverified ones also surface as a warning on the CI gate (see Gates & Policies), so the pipeline nudges you to confirm them.

Coverage

Each DAST-testable threat is back-mapped against the app's findings:

• covered - a matching finding exists (the threat is proven).
• tested - clean - the endpoint was tested, nothing found.
• untested - never exercised (a blind spot).
• design / logic - not something a scanner can test.

A coverage bar shows the percentage of testable threats actually tested.

Compliance mapping

Every threat is mapped to the controls it violates across OWASP Top 10, PCI-DSS, ISO 27001, NIST 800-53, SOC 2, HIPAA and GDPR, so an audit can trace a modelled risk straight to its clauses.

The diagram

The architecture renders as an interactive data-flow diagram (drag, pan, zoom):

• Components are laid out in trust-zone columns (internet → data).
• Public nodes are outlined in red and flagged 🌐.
• Clicking a node focuses its threats - the threat list filters to that component.
• Data flows that cross a trust boundary are animated.

Switch to lanes view for a compact swim-lane layout.

Import & export

apPosture round-trips with the standard threat-modelling formats:

• Import - OWASP Threat Dragon JSON, a Mermaid diagram, or an OpenAPI spec. The imported architecture becomes the baseline the model refines with code, IaC and findings (importing a diagram can add knowledge the scanners can't see - e.g. an external payment gateway).
• Export - Mermaid (renders inline on GitHub/GitLab/docs and copies to your clipboard) or OWASP Threat Dragon JSON.

Versioning & diff

Every regeneration or edit bumps a version. The What changed view diffs two versions and reports threats and components added / removed / changed - matched by STRIDE + title (stable across regenerations), so you can see, for example, that a threat went from inferred to proven, or that a new internet-facing component appeared.

IaC drift

The Check IaC drift action re-parses your infrastructure and compares it to what the model was built on, surfacing new attack surface:

• a newly public component (e.g. a bucket that flipped to public-read),
• an added component, or a removed one.

When drift is detected, regenerate the model to fold in the new surface.

Why use them

• Context for findings - a vulnerability on an internet-facing, proven path matters more than the same issue deep inside a trusted zone.
• Coverage planning - make sure scanning actually exercises the surface.
• Design-time risk - spot missing controls (and public exposure) before they become incidents.

Threat models complement the Attack Map: the model describes intended + parsed surface; the attack map shows demonstrated exploitable paths.