Research / TRACE

TRACE.

A threat modelling methodology for teams that run across clouds, SaaS, contractors, and public networks. The kind of setup where the old idea of a security perimeter no longer describes anything real.

GitHub repository Methodology specification

The core model

Five objects, one structured model

TRACE turns mixed source material into one structured model: assets, roles, invariants, trust boundaries, value flows, authority paths, and failure paths. It runs on evidence. Every threat we raise traces back to a source, a model object, an assumption, a boundary, or an attack path.

T

Threat actors

Actors with capability, incentive, or authority to affect the target.

External attackers, insiders, vendors, contractors, administrators, compromised users.

R

Roles

Privileged or operational positions inside the target.

Founders, signers, maintainers, deployers, administrators, operators, responders.

A

Assets

Value, control, data, authority, or continuity that must be protected.

Funds, keys, credentials, production control, customer data, governance power, brand trust.

C

Critical invariants

Properties that must remain true.

Segregation of duties, approval integrity, bounded authority, deployment integrity, recovery ability.

E

Edges

Places where trust, value, data, or control crosses domains.

Trust boundaries, signer paths, API boundaries, CI/CD to deployment, identity provider to cloud.

The three pillars

One method, three layers

The method is the same in each pillar. What changes is the input and where the emphasis sits. Real risk almost always crosses layers, so a threat model that covers only one of them gives a false sense of security.

Design stage

TRACE for Protocols

White papers, specifications, mechanisms, governance rules, economic models, and code. Outputs include an invariant map, governance and privileged-role risk analysis, a STRIDE threat catalogue, and attack trees. This is the layer our audits cover.

Architecture stage

TRACE for Systems

Cloud accounts, IAM, identity providers, CI/CD flows, deployment paths, and dependency chains. Each edge becomes a zero trust question: who is crossing this boundary, and what happens if the source is already compromised? A compromised CI job becomes a malicious release.

Operational stage

TRACE for Organisations

Workshops, interviews, access reviews, custody and signing procedures, incident response. Outputs include a human and process risk register and a 30/60/90-day operational hardening roadmap.

Standard workflow

Deliberately sequential

Each phase produces a reviewable artifact that becomes input to the next. AI accelerates extraction, coverage, and draft analysis; expert human judgement owns assumptions, ranking, plausibility, collusion analysis, and recommendations.

0

Scope and source inventory

Define the target, the pillar emphasis, and the evidence available.

1

Ingest sources

White papers, specs, architecture docs, interviews, access reviews, code.

2

Construct the TRACE model

Actors, roles, assets, invariants, and edges, each object traceable to evidence.

3

STRIDE threat identification and ranking

Systematic threat enumeration per component and flow, ranked by plausibility and impact.

4

Build attack trees

Decompose the top-ranked threats into concrete, testable attack paths.

5

Inspect collusion and coordination surfaces

Quorums, delegations, and multi-actor failure modes that single-threat analysis misses.

6

Produce roadmap and report

A prioritised mitigation roadmap grounded in the model, not generic best practice.

Open under CC BY 4.0

The methodology, articles, diagrams, and presentation materials are licensed under the Creative Commons Attribution 4.0 International License. Reuse and adapt it with attribution: “TRACE threat modeling methodology, developed by Oak Security, licensed under CC BY 4.0.”

Get a TRACE assessment Use the framework

Subscribe to our newsletter

Security research, audit insights, and ecosystem analysis — straight to your inbox.