Threat

Origin & evolution

The modern engineering meaning of "threat" was sharpened when Microsoft tried to make security a design-time activity rather than an after-the-fact patch. On 1 April 1999, Loren Kohnfelder and Praerit Garg circulated an internal Microsoft memo, "The Threats to Our Products," which introduced STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. STRIDE gave teams six named categories to interrogate a design against, so a threat became something you could enumerate at the whiteboard.

The vocabulary was later formalised through the public sector. The NIST glossary defines a threat as a circumstance or event with the potential to adversely affect operations and assets "through a system via unauthorized access, destruction, disclosure, modification of information, or denial of service." That definition deliberately separates the threat from the weakness it might exploit, which is held in the parallel vulnerability definition.

Adam Shostack carried the discipline into the mainstream with Threat Modeling: Designing for Security (2014), reframing the practice around four questions: what are we building, what can go wrong, what are we going to do about it, and did we do a good job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference →. STRIDE turns twenty-five with its category set largely intact, which is rare for a security artefact.

How it works in practice

A team ships a document-sharing API. During a STRIDE pass on the design, someone raises Spoofing: an attacker who guesses or replays a bearer token could impersonate a paying customer. That is a threat. It is not yet a vulnerability, because the team has not confirmed the tokens are actually guessable. They check, and find tokens are signed and short-lived, so the realistic weakness is narrower: a token leaked in a server log could be replayed inside its ten-minute window.

Now there is a concrete threat (token replay), a concrete vulnerability (tokens written to logs), and a risk the team can rank against everything else on the board. They add a detective control (alert on a token used from two distant IP addresses inside the window) and a preventive one (redact tokens at the logging layer). The threat drove the analysis; the controls answer it.

Threat vs. its neighbours

• Vulnerability is the weakness in the system; a threat is the actor or event that might exploit it. A vulnerability with no plausible threat is low priority. A threat with no matching vulnerability is, for now, only theoretical. They meet at the point of exploitation.
• Risk quantifies the pairing. It folds in likelihood and impact, so two systems can face the same threat and carry very different risk depending on what they protect and how exposed they are. Threat modelling lists what could go wrong; risk assessment decides what to fund.
• Threat actor names the source: the criminal group, insider, or automated botnet behind a threat. Threat intelligence profiles these actors and their methods, which lets a team weight which threats are live this quarter against which are merely conceivable.

In the graph

In the Unified Product Graph, a threat sits in the security region and connects through three canonical edges. A threat_model_identifies_threatThreat ModelidentifiesThreathierarchy edge ties each threat back to the modelling exercise that surfaced it, so threats are never free-floating fears; they have provenance. A threat_targets_serviceThreattargetsServicecross-domain edge points the threat at the part of the product it endangers, which makes blast radius queryable. A security_control_mitigates_threatSecurity ControlmitigatesThreatcross-domain edge closes the loop by linking the defence to the danger it answers. That structure turns the classic threat-vulnerability-risk distinction into something a tool can walk: a threat with no mitigating control is visibly open, and a control with no threat behind it is a defence in search of a justification.