02 — The Practice: seven threat models, and one that was checked

Version v0.33.63 · 7 September 2026 Source SGraph-AI__App__Send/team/roles/appsec/ (58 documents) and team/humans/dinis_cruz/briefs/

Why this section is the site

The research in 01__ argues that threat modelling should be objective, repeatable and continuously checked. This section is the evidence that the founder's own estate does it — on a live product, naming its own unmitigated weaknesses. Publish the method in full; apply the disclosure rule in 04__ to the findings.

The seven

Exhibit A — the validation pair (6 → 7)

This is the site's signature page. One day apart: a threat model, then a pass that validated every finding "against the actual backend code", grounded in a stated code version and reality document. Its summary table has four verdicts, and the honesty of the "N/A" row is the point — two findings were proposals with no code behind them yet, and the validation says so rather than quietly claiming them:

The confirmed-real findings were located precisely (three route methods, by line number) and the reasoning is a general principle worth publishing on its own: a parameter that bypasses the estate's Safe_Str__Id type validation is a finding even though downstream lookup validates the value, because input sanitisation belongs at the route entry point. That is a rule an agent can apply elsewhere — which is exactly what this site network is for.

How to publish it: two columns, claim beside verdict, with the "N/A" rows kept in. A validation table that showed only vindicated predictions would be marketing. The value is in the mixed result.

Exhibit B — the eleven layers (the ThreatModCon vault, already live)

sgit.ai/demos/vaults/threatmodcon-2025/ — presented at ThreatModCon 2025, Barcelona. 51 nodes, 179 threats, 3 critical findings across eleven readable layers:

Customer → Business → Application → Component → Package → Class
        → Method → Source Code → Environment → Runtime → Compute

Its own framing is the best sentence in the corpus on why linked models matter:

"One model answers what could go wrong here. Eleven linked models answer what does this line of code put at risk."

Two demonstrations ride on top of it. Multi-persona reframing: one SQL injection in a payment gateway, told four ways for Board, CISO, CTO and Developer — the practical form of the Linking Threat Models with Semantic Business Graphs paper. Five Wardley walkthroughs: the progression from "everything is critical" to risk-based prioritisation.

The vault also carries an engineering story worth telling on /eleven-layers/: it was adapted for offline vault operation — d3, three.js and tween.js inlined at pinned versions, data read through sg.vfs.readText() on vault-relative paths, with network fallback that reports failure rather than hiding it. And a data-integrity note that models the discipline the whole network runs on: two upstream JSON files had formatting errors, and both were repaired "using only bracket adjustments and repositioning — no field edits or invented content."

Exhibit C — the method (2), publishable in full

The per-file framework, from a brief that opens with unusual candour about why it was commissioned: the team had shipped fast, "some access tokens have already been leaked in posts (not yet abused, but only because usage is low and assets aren't high-value yet). This won't stay true as the platform grows." The goal stated is not remediation but coverage — "to make informed, risk-based decisions about what to address and when."

The approach is bottom-up, and the reasoning is fractal: File → Method → Class → Module → Path/Journey → Endpoint → Full Attack Surface. Against every source file sits a .security.json in a parallel tree, with a schema the site can publish as a reusable artefact: attack_surface (endpoints, auth, input validation, rate limiting), vulnerabilities (id, severity, attack vector, impact, status, mitigation, and — the interesting field — risk_decision, which records an explicit accept-for-now with its reasoning), secrets_exposure, dependencies (including trust_boundary_crossings), and redundant_code.

That risk_decision field is the schema-level expression of the estate's whole posture: a finding is not binary, and the decision to defer is itself data with an owner and a rationale.

Exhibit D — STRIDE, applied honestly (1)

The flagship threat model runs all six STRIDE categories as tables of threat × likelihood × impact × mitigation status — and the status column is populated with NOT MITIGATED as often as MITIGATED, each cross-referenced to a numbered vulnerability. It reaches a conclusion most vendor threat models never print: for the server-breach case the impact is recorded as None, mitigated by design through the zero-knowledge architecture, and Section 6 is a dedicated zero-knowledge verification rather than an assertion.

It also has a Section 9: Assumptions and Open Questions — the house rule (publish tensions unresolved) appearing in security work eight months before this pack.

Exhibit E — the two-modes pattern (3)

The agentic-workflow threat model contains a transferable idea the site should extract as its own page. The document's most important section is a refusal to average two things together:

"The two modes look similar from the outside (both produce a download link) but have radically different security properties."

Mode A (symmetric, key in the URL fragment): "The key IS in the URL. Anyone who has the full URL can decrypt. Security = secrecy of the URL." Mode B (PKI): "The key is NOT in the URL… Security = possession of the recipient's private key."

Its risk matrix scores eight threats across both modes with likelihood, impact and residual risk after mitigations — and the recommendations are prioritised P0–P3 with an owner named for each (DevOps, Dev, Designer, DPO, Sherpa). Two of them are notable for a threat model to produce: "Publish the honest entity list in user documentation" (a transparency action, owned by the DPO) and "Document Anthropic log retention policy in DPO register" (a supply-chain-of-AI action). The threat scenarios include prompt injection via file content, scored Medium likelihood / High impact for agentic use — this pack's clearest evidence that the estate threat-models AI systems, not just web ones.

What the practice teaches that the papers cannot

The research says threat models should be living, checkable artefacts. The practice shows what that costs and what it produces: a model written in a day, a validation that partly contradicts it the next, findings that stay open with a recorded risk decision, and named owners for each recommendation. The site should publish the mixed results, not the wins. That is both the more useful memory for an agent and the only honest way to hold the mandatory-disclosure position in 01__.

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).