- Verify it without usEvery record checks offline against a published key, with no Toevan account.
- See how each fact was obtainedRecomputed, reported, declared, consumed or not captured, on every fact.
- Know what isn’t coveredEvery report lists the controls that stay with the organisation.
Three ways to check the evidence
Choose the route that fits your role. The first runs inside Toevan; the third runs on your own machine.
In the organisation’s app
Any auditor invited by the organisation
An Auditor role, no repository access
Read-only access to the evidence list, the exports and the reports, with Verify now to re-check the ledger, the signatures and any log proofs.
- Signature valid for each record
- Unchanged since it was signed
- Time logged in Rekor, where the organisation opted in
Watch the organisation run it
Standard client-generated report testing
A screen share or a visit
You pick the samples at the time of the session; an engineer runs the checks while you watch.
- Verification of the records you sampled
- Author and approver accounts for each sample
- The code result for a commit you choose
Run it yourself
IT audit specialists
git, openssl, the Toevan verifier (on request) and temporary read access; cosign v2 from v1.4.0
Replay the chain and verify every record against the published key, offline.
- Chain, signatures and Rekor proofs, offline
- Evidence branch tips against the report
- Independence from the account ids in each record
How each fact was obtained
Every fact in a record and a report carries one of six labels, so your auditor knows how far to rely on it.
- Recomputed
- Toevan computed it from the code or git history itself.
- Re-perform it from the same inputs and get the same result.
- Reported + sealed
- GitHub reported it; Toevan captured it at the event and signed it.
- Rely on it as far as you rely on GitHub. Any later change is detectable.
- Declared + sealed
- The organisation declared it, such as a change to what is checked; Toevan signed the declaration and its history.
- See who declared what, when, and every later change.
- Toevan record, not sealed
- Held in Toevan’s database but not sealed in the ledger, such as a waiver today. Nothing protects it by a signature.
- Treat it as Toevan’s statement, and ask the organisation for the approval behind it.
- Consumed
- Taken from another system’s signed record, such as build provenance, and linked by commit or digest. Planned.
- Check the original record independently.
- Not captured
- No reliable source was available. Toevan does not infer it.
- Obtain it from the organisation by other means.
What you receive
Each file’s SHA-256 is listed, so you can confirm what you were given.
- Change evidence reportPDF
sha256:3f9a…c21e - RecordsCSV · merged changes, control changes, samples
sha256:[csv hash] - Toevan public keytoevan.pub · keyid 8c1f…e0a2
sha256:[key hash] - Toevan commandtoevan audit verify · provided by Toevan on request
sha256:[binary hash]
Each file’s SHA-256 is listed so you can confirm what you received. The public keys are also published at api.toevan.com, independently of the report.
Questions auditors ask
If a client hands you Toevan evidence, these usually come first.
The records
4 questionsWhat is a Toevan evidence record?
A signed statement of one event. Today that is a code check on a pull request or on main. From v1.4.0 it is also a change merged, a review rule changed or a direct push. A change record names the pull request, who authored, approved and merged it, the checks and rules in force and the code results, with each fact labelled with how it was obtained. People appear as digests of their GitHub accounts.
Technically it is an in-toto statement with the SLSA verification summary predicate, sealed in a DSSE envelope and signed with ECDSA P-256; other record kinds’ predicates arrive with v1.4.0. Anchoring in Sigstore’s public Rekor transparency log is built in and opt-in per organisation; only record hashes are published. Enterprise organisations can also anchor in their own Rekor.
When is a record written, and by whom?
When the event happens: as each code check runs today, and from v1.4.0 as each pull request merges, as a review rule changes or a push bypasses review. Records are not assembled afterwards from logs or tickets, so a gap between snapshots can’t go unseen.
What do the labels on each fact mean?
Recomputed facts were computed by Toevan from code or git history, and you can re-perform them. Reported + sealed facts came from GitHub and were signed at the event, so you rely on them as far as you rely on GitHub. Declared + sealed facts, such as a change to what is checked, were declared by the organisation with their history. Waivers are Toevan records that are not sealed in the ledger today, and the report says so. Consumed facts will come from another system’s signed record, such as build provenance; it is planned. Not captured means there was no reliable source, and Toevan does not infer it.
Is the code result deterministic?
Yes. Rules are evaluated against the repository’s code graph with no machine-learning model in the decision. The same commit, engine version and rule-set version always produce the same result, so you can re-run a sampled evaluation and expect an identical one.
Verification
4 questionsWhich tools check the evidence?
In the app, Verify now re-checks the hash chain, every signature and the stored proofs. It runs inside Toevan.
With stock tools and no Toevan account, openssl checks one record against the public list of every key Toevan has signed with, current and retired: the signature, and that the record file is the one the statement names. From v1.4.0 the reports and the evidence branch print the commands, and Toevan documents a cosign v2 line that checks the signature and the statement type, not the record binding.
With the Toevan verifier, available from Toevan on request, one command replays the whole chain and checks every signature and Rekor proof offline.
With git, you read the evidence on a hash-linked, forward-only toevan/evidence branch in the client’s own repository, and each report carries a content digest, the SHA-256 of the manifest attached to the PDF. From v1.4.0 you can also recount the change population with git and the report’s CSV.
Anchoring in Sigstore’s public Rekor transparency log is built in and opt-in per organisation; only record hashes are published. Signed verdicts can also be pushed into the client’s Kosli flows.
How do I test completeness, not just accuracy?
From v1.4.0, the change evidence report lists every commit that reached the default branch in the period, straight from git history, and matches each one to the record of the merged pull request or push that put it there. A commit no record explains is flagged with the reason, never inferred. You can re-perform the population yourself with git from the population CSV. Each deployment GitHub marks as production is linked to the commit it shipped. Production branches the organisation designates, such as a release branch, get the same population in v1.4.1, which is planned.
How are fixes copied to release branches handled?
Planned, and not part of v1.4.0. A copied fix gets a new commit ID, so its review doesn’t carry over automatically. Toevan will match it to the reviewed original by content with git patch-id, and treat a copy whose content changed as needing its own review.
What does the public transparency log reveal?
Anchoring in Sigstore’s public Rekor transparency log is built in and opt-in per organisation; only record hashes are published. An entry shows only that a record with a given hash existed at a given time: no code, file names or findings. Enterprise organisations can also anchor in their own Rekor.
Scope and retention
4 questionsWhat does a clean report not mean?
It does not mean the client complies with the framework, and Toevan expresses no opinion on whether controls are designed or operating effectively. Access reviews, runtime monitoring, incident response, third-party risk, physical security and changes made outside version control need your usual procedures. Every report lists them.
Which version control systems are covered?
GitHub today. GitLab and Bitbucket are on the roadmap. Changes made outside version control, such as direct database or console changes, are outside the evidence.
Where does the evidence live, and for how long?
In Toevan’s append-only store with retention of at least three years, and as a copy on a branch in the client’s own repository. Reports export as PDF and CSV per framework, period and repository.
What if the client stops using Toevan?
The copy in the client’s repository stays where it is. The chain replays with the toevan command and, from v1.4.0, each signed record also checks with openssl alone against the published key, with the commands on the evidence branch. Verifying past records does not depend on Toevan continuing to operate the service.
Walk through a client’s evidence with us.
If you audit a Toevan customer, we’ll take you through verification on a call, using your own tools.