Threat models as vault-native graph data
Threat models are graph data, not prose — that is the whole argument, and this page has to avoid contradicting it by being a pile of markdown. Each published model gets a JSON twin: nodes (Asset, Threat, Vulnerability, Mitigation, Actor, Incident), edges (targets, mitigates, is-instance-of, crosses-trust-boundary), and a per-finding status.
The platform's pitch to an AppSec team is not "we have better threat modelling than X"; it is "we have a clean home for all your security artifacts, with tools that work directly on top of them."
Eight frictions, and the vault answer
An AppSec engineer juggles eight to fifteen tools, each with its own data home. The tool choice is usually fine. The data home is the friction — and each of these maps directly onto a threat model's own lifecycle.
| The question | The vault answer |
|---|---|
| Where does the threat model live? | In a vault — versioned, owned, exportable |
| How do I share it with auditors? | Read-only vault link, time-limited |
| How do I bring in new data? | Vault content appends; tools read from the vault |
| How do I run offline / air-gapped? | Vault collections are portable; tools run on local SG/Compute |
| How do I correlate findings across tools? | All tools write the same vault structure; findings cross-reference |
| How do I version-control security artifacts? | The vault commit history is the version control |
| How do I prove what was reviewed when? | Vault commits are cryptographically signed; auditors verify |
| How do I share without losing control? | Vault sharing with revocation |
Several of these are the mandatory-disclosure paper's requirements arriving as product features: a signed, dated, revocable, auditor-verifiable artefact is precisely the "reliable signal" that paper says the market lacks.
The artefact schema
A threat-modelling vault holds: system descriptions, threat lists (STRIDE-categorised), attack trees, DREAD scores, mitigations, Gherkin test cases, and evidence. Two of those carry this page's real point:
Gherkin test cases
A mitigation expressed as an executable scenario is a threat model CI can check — not a claim re-read at the next audit, but a check that runs on every change.
Evidence
What turns a claim into a disclosure: the thing that lets a reader verify the model rather than trust it.
The tool pattern, and the step this site holds itself to
The productisation template: find a strong open-source tool, host it on shared infrastructure, add a UI and vault integration, contribute back. The first named target is StrideGPT — actively developed, LLM-integrated, supporting STRIDE plus the OWASP LLM Top 10 and MAESTRO-inspired pattern detection, with two intended modes: pure client-side for air-gapped use, and ephemeral-compute-backed for teams.
Eight further mini-tools sit on the same substrate — SBOM analysis, dependency scanning, secrets detection, OWASP Top 10 assessment, compliance evidence, policy management, pentest artefacts, vulnerability disclosure management. Only the threat-modelling one belongs on this site; the rest are a pointer. "Contribute back" is a commitment this site makes visible rather than re-argues — open-source.sgit.ai holds the founder's position on open source itself.
What is real today versus what is argued
The gap between the 2025 papers' vision and today's implementation is this site's main honesty risk, so it is drawn as an explicit table rather than left implicit.
| Real, now | Argued, not built |
|---|---|
| The ThreatModCon vault: 11 linked models, 51 nodes, 179 threats, live and offline-capable | The continuous pipeline that keeps models current as code changes |
| Vault primitives: versioning, signing, revocable read-only sharing, sub-vaults, append lanes | Automated CVE-to-component linking that instantly flags a new threat |
| MGraph-DB as a memory-first graph store | The multi-ontology overlay (STRIDE × ATT&CK × OWASP) running as a live query over a production model |
| Seven written threat models, one validated against code | Gherkin-executable mitigations checked in CI |
| StrideGPT identified as the first integration target | The integration itself |
An agent reading this site should be able to tell, for any capability named on it, whether it can use it today or is being told a direction. That is not a courtesy — it is the same falsifiability standard /validated/ applies to a single finding, applied here to the platform's own claims.
Where this site stops and a sibling starts
| Topic | Owner | This site's part |
|---|---|---|
| Wardley maps as a technique | wardley-maps.sgit.ai | Only the five threat-prioritisation walkthroughs, as an application |
| G³, MGraph-DB, graph theory | graphs.sgit.ai | Only threat-model-shaped graphs; link out for the substrate |
| ISO 27001, EU AI Act, GDPR | standards.sgit.ai | Only framework-overlay-as-graph-edge; standards text stays there |
| Risk registers, acceptance | risks.sgit.ai | Only the risk_decision field as it appears in the security schema |
| Vault mechanics, keys | pki.sgit.ai / sgit.ai | Only what a threat model needs to say about them |
The rule that keeps this clean: this site owns the act of modelling threats. If material is about the thing being modelled rather than the modelling, it belongs to a sibling. The full network map →