Threat models

Nearly every application security tool ingests scanner output. Very few connect design-time intent to what actually shipped. Sinterly treats a threat model as a first-class source, and then does something with it that a scanner cannot: it checks what the model claims against the evidence.

What is accepted

Open Threat Model (OTM) version 0.2.0, uploaded like any other file. Two common routes in:

IriusRisk. Export your project as OTM and upload it.
pytm. pytm does not emit OTM directly, so Sinterly includes an adapter that converts pytm output on import. You upload the pytm JSON and it is handled for you.

What happens on import

Each threat becomes a design finding. Where a component in the model references a threat, one design finding is created per component and threat pair, so the affected part of the architecture is preserved. Threats no component references arrive once as global design findings.

Severity is derived from the threat's own risk block. Impact leads, because impact is the business consequence dimension. Where a generator uses words such as "high" rather than numbers, those are mapped too. Severity is never invented.

Design findings appear in the Threat register, not in your main findings list. They resolve differently from code defects, so mixing them into the same queue would be misleading.

Trust zones and target tiers

If your model describes trust zones, Sinterly reads the trust rating of the zone each component sits in. A threat on a component in a low-trust, high exposure zone is a signal that the code addressing it lives on a business-critical surface.

This produces a suggestion to promote the tier of the linked target, which an AppSec Lead approves or dismisses. It never changes scoring on its own. A stale or untrusted threat model must not be able to inflate your scores quietly.

Linking threats to code

In the Threat register, an AppSec Lead links each threat to the implementation findings that evidence it in code. A link is a deliberate, audited statement that this code finding addresses this threat.

Two link types exist, and the difference matters:

Addresses. This code finding is evidence about the control for that threat. This is what counts as evidence.
Relates to. Someone saw a connection worth recording. This is explicitly not treated as evidence that a control exists.

Where the model and the code disagree

This is the part no scanner can produce. OTM records the model's own claims on each component's threat reference: whether the threat is still exposed, and which controls the model says are in place. Sinterly reads both, and reports where those claims are not borne out.

What you see	What it means
Model contradicts itself	The model records the threat as exposed while also declaring a control in place for it. One of those two statements is out of date, and no outside information is needed to see the problem.
Control declared, not evidenced	The model says a control is implemented, and no code finding is linked as addressing the threat. Nothing corroborates the claim.
Declared exposed, nothing addresses it	The model says the threat is exposed, declares no control, and no code evidence is linked either.

The rule that keeps this useful. Sinterly only ever reports what your model actually asserts. A threat that claims nothing produces nothing, however tempting the silence looks. The obvious version of this feature, flagging every threat with no linked code, would fire on every threat of a freshly uploaded model and produce forty findings that say nothing. The report tells you how many threats state nothing checkable, so an empty result is explainable rather than mistaken for a clean model.

What threat models do not do

Design findings never fail a CI build. A threat is not something a build can fix, and the gate deliberately ignores them. See The CI gate.