Scoped credentials
Explicit scopes, no roles, mandatory expiry capped at a year, secret shown once and stored as a digest. Revocation is a state so the record survives it.
Security and trust
Designed to be checked, including by someone who does not trust us
A compliance record whose integrity rests on the vendor's word is worth the vendor's word. The audit log here can be recomputed independently, the approval scopes no machine can hold are refused by the API, and the limits are written down.
The audit log is the product
Every mutation and every read is appended to a log whose entries are linked by digest: each one stores the hash of its predecessor, so altering or removing a historic row breaks the link. That includes a change made directly in the database, which is the case no application-level check can see.
It counts as evidence because the verification is yours to run. The API returns every field the digest covers, the genesis value, and the log in forward order for exactly this purpose. You do not need our word for it, and the interface says so in those words.
Human-only actions
Approving a suppression, disposing of an asset and accounting for a chain break are refused on any API key, by anyone. Machines record and propose.
A scanner that proves itself
Gated on finding planted vulnerabilities before a clean result is treated as evidence, and the interface says when that has not been established.
Fails closed
Disposal without an approval, an approval without a recorded decision, or a dependency that cannot answer all produce a refusal, never a silent success.
What we do not claim
This section exists because its absence elsewhere is what makes a trust page worthless.
- No external audit. The platform is reviewed adversarially by an internal team working against it. No external body has certified it.
- No uptime commitment outside an enterprise agreement.
- No accessibility audit by a third party. The accessibility statement says exactly what has and has not been tested.
Reporting something
Security reports go to security@rodmena.co.uk, and /.well-known/security.txt is published per RFC 9116. Anything else reaches support@rodmena.co.uk. Include the request, the response and the request id: every response carries one, and it ties your report to the exact entry in the audit log.
Security questions
How do I report a vulnerability?
Write to security@rodmena.co.uk, or read /.well-known/security.txt, which follows RFC 9116. Include the exact request, the response, the request id from the response headers, and what you expected. Reports are re-run before they are agreed or disagreed with, and you will be told which.
Can I verify the audit log without trusting you?
Yes. Every entry stores the digest of its predecessor, and the API publishes the canonical payload — the exact fields and their order — along with the whole log in genesis-first order. You can recompute the chain on your own machine and reach your own verdict. Any break is reported with its cause and the content it anchors to.
What happens when the chain is broken?
It stays broken, permanently, and is annotated instead. Repairing it would mean rewriting the log, which is exactly the act the chain exists to detect. A break is either tampering or a concurrency fork in our own append path, and the two are told apart and labelled, so one never masquerades as the other.
How are API credentials handled?
Keys carry explicit scopes and no roles, so widening a role can never widen a key already issued. Expiry is mandatory and capped at a year. The secret is shown once and stored only as a SHA-256 digest, so a lost key is revoked and reissued; there is no recovery path. Revocation is a state, never a delete, because an auditor asks what a key could do during an incident window.
What can a machine never do?
Approve a VEX position, dispose of an asset, or account for a break in the audit chain. Those scopes are refused on an API key by anyone, including an administrator. A 403 on one of them from a key is the design working, not a permissions bug.
How is my data kept separate from other customers?
provenance is a shared instance, and your register is separated from every other customer’s in the database rather than by application code: every table holding customer data carries a workspace column and a restrictive policy, so a query that forgets to filter returns nothing instead of returning somebody else’s rows. What is shared, plainly: one database, one application, and one sending domain for alert email — which is why an alert address has to confirm itself before we will send to it. There is no operator back door into your workspace: support access is not a mode somebody switches on. Every credential that can reach your register through the API is on a list you control — people in your members list, machine credentials in your API keys list with their scopes and expiry — so you can see who and what holds access, and withdraw any of it. The separation is also checkable from your side: switch workspaces and the register, the counts and the audit chain all change together, because each workspace has its own chain with its own first entry.
Read the evidence side
What the register can prove for a given control, and what it cannot.