Threat models as mandatory disclosures
The boldest of the seven papers, published here as the standalone policy position it is rather than buried in a research index.
The market for lemons
Digital products suffer a classic information asymmetry: vendors know far more about their product's security than buyers do, so inferior security offerings can thrive and outcompete higher-quality ones — buyers have no reliable way to tell them apart from the outside.
The proposed correction
Make threat-model publication a regulatory requirement, the way financial statements and food-ingredient labels are mandated. A published threat model becomes a reliable signal of security quality, and concrete evidence of the threats a company has considered and mitigated — substantiating security claims that today are often vague or unverified. The full paper summary →
The reflexive test — and why /practice/ exists
A site arguing that threat models should be mandatory disclosures is judged by whether it discloses its own. It does — /practice/ is that disclosure, and this page and that one are written to be read together: the policy position argued here, and the method it holds itself to over there.
The rule this site publishes under
Publish the method always. Publish findings only once they are closed, or once they are harmless by design.
| Category | Publish? | Reasoning |
|---|---|---|
The method — bottom-up file-by-file, the parallel security tree, the .security.json schema, the STRIDE table format, the two-modes pattern, the validation format | Yes, in full | Methods are the transferable asset and expose nothing |
| Findings that are fixed, with the fix and its version | Yes | This is the disclosure the papers argue for; the version proves closure |
| Findings mitigated by design (e.g. server breach → impact None under zero-knowledge) | Yes | Publishing an architecture's strength is not exposure — but only where a verification section backs it, as the STRIDE page shows |
| Findings still open on a live system | No — hold | Publish the count and the class, dated, not the location |
| File-and-line locations of any unfixed finding | Never | Precision is the value internally and the danger externally |
| Third-party findings (a vendor's log-retention policy, a partner's own logging) | No | Not this estate's to disclose; describe the question asked, not the answer found |
| The leaked-token history | Yes, as history | Already public elsewhere in the network; the honest post-mortem is an asset — provided the tokens are dead |
The dating rule does the heavy lifting. A finding published as "open as of 17 March 2026" and later shown as "closed in v0.x.y" is exactly the mandatory-disclosure model working. A finding published as open with no date and no closure is an unmaintained invitation.
Redaction is a versioned act, not a deletion
When a source document is published in redacted form, the site says so on the page: which categories were held, and why. Every redacted page carries, or will carry once the closure pass below is complete, a stated count of findings held and their classes — the count generated, never estimated.
Before launch: a closure pass — the one open blocker
The findings in the corpus are from February and March 2026; this site's commissioning pack is dated September 2026. Nothing may be published as "open" without re-checking it against current code first. Two failure modes to avoid, in both directions: publishing a fixed vulnerability as open defames the product, and publishing a still-open one as fixed is precisely the behaviour this page argues against. That re-check has not run yet — it is comms question Q1, tracked openly on /admin/comms.html, and it is what currently keeps /validated/ to a summary table rather than a fuller findings list.
Disclosure for this site itself
A site publishing threat models must be reachable by anyone who finds a flaw in it. This site ships /.well-known/security.txt from its first release — a threat-modeling site without a disclosure channel would be the discipline's own joke.
Licensing
Site text, schemas, tables and analysis: CC BY 4.0. The white papers are the founder's own and carry their existing co-authorship attribution. STRIDE, MITRE ATT&CK, CAPEC, CWE/CVE, OWASP Top 10 and ASVS: referenced by name and linked; never reproduced. STRIDE is a Microsoft-originated taxonomy — the six category names are terms of art, but this site publishes its own tables under those headings, never a copied framework text.