Enforceable cybersecurity

Security you can prove, not assert

Traces Research Foundation builds the framework, the protocol and the open-source tooling that turn security claims into evidence.

Vetted partners
Network — 01 / 03

No single vendor can attest to your whole estate

So the network does it instead. Seekers declare what must be verified. Providers do the work. Attestors confirm it happened. Regulators read the result — from the same evidence, not a summary of it.

Data centre IP peering exchange Peering path
Network — 02 / 03

Four roles, one protocol

Roles are defined by what they may assert, not by who they are. An agent and a human red team occupy the same role if they produce the same evidence.

01
Seeker
Holds the obligation. Declares assets, owners and controls, and asks for them to be verified.
Asserts — intent
02
Provider
Does the work. An ISV, an autonomous agent, or a human red or blue team — discovered over Beckn.
Asserts — findings
03
Attestor
Confirms the work happened as described, and signs it. Cannot alter what it attests to.
Asserts — proof
04
Regulator
Reads. Never writes. Sees the same evidence the engineer sees, rendered for a different question.
Asserts — nothing
Network — 03 / 03

Where trust stops

Crosses the boundary
Control identifiers · scope definitions · signed attestations · outcome states · timestamps and versions · the identity of who ran what
Never crosses it
Secrets and credentials · raw customer data · unredacted exploit detail before the disclosure window closes · the seeker's internal architecture

Open question we have not solved: how an attestor proves independence from the provider it attests to, without a central registry. Draft section 4.3 sets out three candidate approaches.

Framework — 01 / 03

Enforceable means someone can be held to it

Provable means you can show it. Risk does not start at the application — it starts at the cage door. The framework declares obligations at every layer, from facility access to prompt handling.

Draft — open for comment
Framework — 02 / 03

Five steps, each one auditable

Declare and Prove are the two most frameworks omit — and the two that make the difference between advice and obligation.

01
Declare
Write the obligation down in machine-readable form — assets, owners, controls, and the rule each answers to.
Signed policy set
02
Plan
Derive the work: scope, method, and what counts as passing. Never authored beside the declaration.
Scoped test plan
03
Orchestrate
Dispatch it across ISVs, agents and human teams, discovered over the protocol rather than procured ad hoc.
Dispatched engagements
04
Prove
Attest, don't assert. Who ran it, when, against which version, with what outcome — tamper-evident.
Verifiable attestations
05
Report
One truth, many views. Board, regulator, auditor, engineer — no two reports can disagree.
Audience-specific report
Framework — 03 / 03

One control, end to end

Declared
CTRL-114
Privileged access to production must be recorded and reviewable for 400 days.
Owner: Platform · Rule: DORA Art. 9
Planned
Session-integrity test
Attempt replay and truncation against a live session. Pass = both attempts detected and logged.
Depth: adversarial · Quarterly
Orchestrated
2 providers
One autonomous agent for coverage, one human red team for creativity. Both bid over the protocol.
Dispatched 12 Aug
Proved
1 finding
Truncation went undetected. Signed by both providers and one independent attestor.
TRF-2026-0041
Reported
4 views
Board sees one amber control. The engineer sees the failing assertion and the commit that fixed it.
Projects — 01 / 02

Built in the open

Four in active development, two on the way. Every one is inspectable before you trust it. Open any card to read the detail.

Projects — 02 / 02

How they fit together

Declare & Plan
ttraces-enterprise
Policy becomes machine-readable obligation.
Orchestrate
ttraces-provider
Work is discovered and dispatched over Beckn.
Prove
traces-terminal · traces-sm
Access and secrets produce their own evidence.
Report
ttraces-network
The framework renders it for each audience.
Marketplace — 01 / 02

Vetted by us, listed by us

Every partner here was reviewed by the foundation. No self-serve listings, no paid placement.

All ISV Agent Red team Blue team Attestor
Marketplace — 02 / 02

What vetting actually checks

01 — Evidence
Can you produce a signed attestation?
Not a PDF report. A structured, verifiable claim bound to the control it answers. We test this with a sample engagement before listing.
02 — Independence
Who else do you answer to?
Ownership, funding, and any commercial relationship with the parties you would be testing. Disclosed on your listing, not held privately by us.
03 — Conduct
How do you handle a finding?
Your disclosure practice must be compatible with ours. Providers who publish before the window closes are delisted.

Listing is free and carries no commercial relationship with the foundation. We do not take a cut of engagements, and placement is never sold.

Industry — 01 / 02 · Risk & loss assessment

What a failure actually costs

Loss figures are modelled per sector from published incident data and the control gaps we see in engagements. Risk index is relative: it ranks where declared obligations and provable evidence diverge most.

Sector Dominant loss driver Annual loss, est. Risk index Layer
Regulated financeThird-party compromise reaching payment rails$4.9M / firm8605 → 07
HealthPrivileged clinical access with an incomplete audit trail$3.6M / trust7805
Public infrastructureOperator sprawl with no comparable standard of proof$2.1M / operator7101 → 03
Cloud & hostingExchange-level interception and route manipulation$5.4M / provider6403 → 04
AI & agent platformsOver-privileged agents acting on unverified instructionsUnmodelled9207
Industry — 02 / 02 · Case studies

Our case studies

Four engagements, published with the client's consent. The figures are theirs. Each one records what did not work — a case study without a caveat is marketing.

Learn — 01 / 02

Read the work, then use it

Learn — 02 / 02

Live upstream threat intelligence

Airtable · synced 14 min ago

Top open-source projects our stack depends on, ranked by how much of the estate inherits their risk. Maintained as an Airtable base so anyone can add a row.

Upstream project Stars Dependents Inherited risk Threat intelligence Status
openssl/openssl26.4k~9.1M94Two CVEs in the last quarter reached TLS negotiation; layer 04 exposure across every listed providerWatching
sigstore/cosign4.7k~180k81Signing chain is a single point of trust for attestation integrity; key-rotation practice under reviewWatching
open-policy-agent/opa9.9k~410k68Policy evaluation drift between versions can silently weaken a declared controlMonitoring
hashicorp/vault32.1k~620k63Licence change pushed forks into production; provenance of forked builds is unverifiedMonitoring
beckn/protocol-specifications1.2k~2.4k57Spec ambiguity in select/confirm enabled the role-spoofing finding TRF-2026-0038Resolved
grpc/grpc42.8k~3.3M44Transport layer for provider dispatch; no active advisoriesStable
Exploits Directory — 01 / 02

Findings, in full, with citations

Each record has a permanent ID and URL. Cite them. Open any row to read the full disclosure timeline.

Disclosure policy. Every record here was disclosed to the affected party first and published only after the disclosure window closed. Redacted fields are marked. Read the disclosure policy

ID Affected Severity Disclosed Status
TRF-2026-0041traces-terminal — session record truncation undetectedHigh2026-08-14Fixed
TRF-2026-0038Provider discovery — role spoofing during selectMedium2026-07-02Fixed
TRF-2026-0031traces-sm — rotation attestation replay windowMedium2026-05-19Fixed
TRF-2026-0024Attestation format — ambiguous scope on partial passLow2026-04-08Spec change
TRF-2026-0019ttraces-enterprise — control set import trusted unsigned sourceHigh2026-02-27Fixed
Exploits Directory — 02 / 02

How we disclose

01
Report
Findings reach the affected party within 24 hours, with reproduction steps and a proposed severity.
Day 0
02
Window
90 days by default, extended on request where a fix is genuinely in progress. Extensions are recorded on the record.
Day 0 – 90
03
Publish
Full detail, permanent ID, permanent URL. Fields still dangerous to publish are redacted and visibly marked as such.
Day 90+
04
Never
We do not sell findings, do not brief press before the affected party, and do not publish our own projects' findings any more gently.
Policy

Two of the five published records are against our own projects. That is deliberate: a directory that never indicts its author is not a directory.

Report a finding →
Personal cyber safety — 01 / 02

Most harm does not arrive through a firewall

It arrives through a message. This material is written for people, not practitioners — free to read, free to reuse, no account required.

Personal cyber safety — 02 / 02

Fraud or cyberbullying: what to do, in order

Spot it first — five-step fraud identification If two or more match, treat it as fraud
01
It arrives with a deadline
Any message that punishes you for pausing is engineered. Real institutions do not close accounts in ten minutes.
02
The channel is slightly wrong
Your bank on WhatsApp, HR on a personal number, a colleague from a new address. The content may be perfect; the channel is the tell.
03
It asks you to move money or trust
A transfer, a code, a gift card, a login, or approval of something you did not start. Fraud always ends in one of these.
04
It discourages a second opinion
“Do not tell anyone”, “this is confidential”, “I am in a meeting”. Isolation is a requirement for the attack, not a coincidence.
05
Verify on a channel you chose
Hang up and call the number on your card. Not the one in the message.
Discord X
{{ routeLabel }}
← → pages · ↑ ↓ slides
Reading view
Network · Attestation

MPC attestation

An attestation is only worth what its signer is worth. Multi-party computation removes the single signer: several providers jointly compute the claim without any one of them holding the whole input, and the signature is only valid if the threshold agreed.

Why not a single attestor
A lone attestor is a lone point of capture. If it can be pressured, bought, or breached, every claim it signed becomes suspect — retroactively, across every organisation that relied on it.
What is computed jointly
The assertion outcome, not the raw evidence. Each provider contributes a share; the protocol yields a signed pass or fail without any participant learning the others’ inputs or the seeker’s internal topology.
Threshold
Configured per control. High-consequence controls typically require 3-of-5 with at least one participant that had no part in the testing.
Status
Specified in draft section 4.3, which is the section we openly mark unresolved: MPC removes the single signer but does not yet prove the participants are independent of one another.
attest: CTRL-114
scheme: mpc-threshold
threshold: 3 / 5
parties: kestrel, northbound, meridian, sentinel, halden
independence: 1 party excluded from execution
ttraces-cli Ongoing

The framework, from a terminal

One binary that runs all five steps locally: declare a control, derive a plan, dispatch it to providers, collect attestations, and render a report. If it cannot be done from the CLI, it is not really part of the framework.

$ ttraces declare ctrl-114.yaml → signed
$ ttraces plan ctrl-114 --depth adversarial
$ ttraces dispatch --providers 2 --mpc 3/5
$ ttraces attest --watch → 1 finding
$ ttraces report --audience regulator
Install
Single static binary, no daemon. Reads declarations from your repository so the obligation lives beside the code it governs.
Layer coverage
Assertions can target any of the seven layers, from facility access records through to agent instruction traces.
Links
Repo · Docs on GitBook · Walkthrough video
Case study · Regulated finance · EU

Vendor attestations replaced 340 questionnaires

Evidence review
11 weeks → 6 days
Vendors in scope
340
Duration
7 months
The problem
A payments firm carrying DORA third-party duties was managing assurance through a questionnaire sent to each of 340 vendors. Responses were prose, arrived in no fixed format, and could not be compared. Review consumed most of a quarter and produced a spreadsheet nobody trusted.
What we changed
We declared the control set once, in machine-readable form, and required a signed attestation per vendor against those controls rather than a narrative response. Vendors that could already produce structured evidence were finished in a day.
Result
Evidence review fell from eleven weeks to six days, and for the first time two vendor claims meant the same thing, because they cited the same control identifiers.
What did not work
Twenty-two vendors — mostly small suppliers with no security function — still cannot produce an attestation at all. For those, the questionnaire remains, and the firm now knows precisely which relationships are unevidenced instead of assuming all 340 were fine.
Lesson 05 · 4 min Free · no account

Verify on a channel you chose

Almost every fraud survives one thing and dies on another: it survives your suspicion, and it dies the moment you make contact through a route the attacker did not supply. This lesson is that single habit.

1 — Do not reply to verify
Replying to the message, calling the number in it, or clicking the link inside it all keep you inside the attacker’s channel. A convincing reply is not evidence; producing one is the easiest part of the attack.
2 — Choose the route yourself
The number on the back of your bank card. The app you already had installed. The colleague’s desk. A route you can name the origin of, and that existed before this message arrived.
3 — Accept the friction
Waiting on hold for eleven minutes feels like a cost. It is the cheapest control available to you, and the only one that works when the message is perfect — correct logo, correct name, correct last four digits.
4 — If they resist verification, you are done
A genuine institution will wait while you call back. Anyone who argues against verification has told you what they are. End the conversation and start step 02 of the response guide: preserve the evidence.
One sentence to keep: I will call you back on a number I already have. You never need a better answer than that.
Suggested
Answers cite the source document, the framework step, or the exploit record they came from. Nothing is generated without a citation.
{{ pName }} {{ pStatus }}

{{ pKicker }}

{{ pBody }}

{{ sec.h }}
{{ sec.b }}
{{ pLinks }}
Draft — open for comment v0.4 · 41 pages

An enforceable and provable cybersecurity framework

This paper sets out a five-step framework under which a security claim can be traced back to the obligation that required it and forward to the evidence that satisfies it. It is a draft: section 4.3 is unresolved and we say so on the page rather than in a footnote.

1The assurance gap — why compliance and security divergep.3
2Declaring obligations in machine-readable formp.9
3Orchestration across heterogeneous providersp.17
4.3Attestor independence without a central registry — unresolvedp.26
5Reporting from a single evidence basep.31
6Relationship to ISO 27001, NIST CSF and DORAp.36
Download PDF Comment on the draft
TRF-2026-0041 High Fixed

Session record truncation went undetected

Affected
traces-terminal
Control
CTRL-114
Credit
Kestrel Labs
Finding
The session hash chain was verified from the head backwards, so removing the most recent segments produced a chain that still validated. An operator with log-store access could therefore delete the end of a session — typically the part that matters — without detection.
Timeline
2026-05-16Reported by Kestrel Labs during a scheduled engagement
2026-05-17Reproduced and confirmed; severity set to High
2026-06-30Fix released — periodic anchoring plus forward verification
2026-08-14Published in full after the disclosure window closed
Citation
Traces Research Foundation. TRF-2026-0041 — Session record truncation went undetected. ttraces.io/exploits/TRF-2026-0041

{{ ptName }}

{{ ptRoles }} {{ ptRegion }}

{{ ptBody }}

Can assert
{{ ptAssert }}
Declared relationships
{{ ptRel }}
Vetting
{{ ptVet }}

Apply to be listed

Vetting takes about three weeks and starts with your evidence format — send a real attestation from a real engagement, redacted as needed. Listing is free and creates no commercial relationship with the foundation.

Personal domains aren't accepted.
ISV Agent Red team Blue team Attestor

Sign in to the Trust Center

The Trust Center is where obligations, attestations and reports live. Access is granted per organisation — your administrator can add you.

or
Codes rotate every 30 seconds.
Guide · 12 min read

Declaring your first control

The shortest useful path through the framework: one asset, one control, one obligation, signed. If you can do this, everything else is repetition.

1 — Pick something small and real
Not your crown jewels. Pick a system where you already know who owns it and what rule applies, because the hard part of Declare is not the format — it is discovering that nobody agrees on the owner.
2 — Write the obligation, not the intention
“We should review access regularly” is an intention. “Privileged access to production must be recorded and reviewable for 400 days” is an obligation: it names a duration, a scope, and a testable outcome.
control: CTRL-114
asset: production-cluster
owner: platform-team
rule: DORA Art. 9
assert: session_record.complete && retention >= 400d
3 — Sign it, then leave it alone
A declaration that changes whenever a test fails is not an obligation, it is a preference. Sign it, version it, and let the failure stand as a finding.
Next
Plan the test that proves it, or read the traces-sm reference if the control involves secrets.