- Verify it offlineEvery signed record verifies offline with standard openssl, without Toevan software or an 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
Three ways to check, one of them offline with standard openssl.
Choose the route that fits your role. Only the third needs any tools: it verifies offline with standard openssl, without Toevan software or an account.
1
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, if Rekor anchoring is on
2
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
3
Run it yourself
IT audit specialists
git, openssl and temporary read access; for the whole chain, the Toevan verifier (on request, not yet public)
Check any record offline against the published key with stock tools. To replay the whole chain, Toevan provides the toevan command on request; it is not yet public.
- Signature and record, offline, with openssl
- Evidence branch tips against the report
- Independence from the account ids in each record
The check as your client’s evidence branch README prints it, after a clone and the key download. They need openssl (OpenSSL 3 or later, or the LibreSSL that macOS ships) and the shell utilities sed, wc, tr, cut, cat and printf, in any POSIX shell. Nothing from Toevan is needed.
- the key's fingerprint: compare it with the key id at api.toevan.com/v1/public/evidence/keys
- the signature, over the exact bytes that were signed (DSSE v1)
- the record file is the one the signed statement names
- what the statement says it is about; compare it with the record you picked
$ git clone --branch toevan/evidence <your-client's-repo> evidence && cd evidence
$ curl -o toevan.pub https://api.toevan.com/v1/public/evidence/keys/<key_id>.pem
$ ENV=attestations/<head_sha>/<record_id>.dsse.json
$ REC=records/<head_sha>/<record_id>.json
$ PUB=toevan.pub
$ openssl pkey -pubin -in "$PUB" -outform DER | openssl dgst -sha256
SHA2-256(stdin)= <key id>
$ T=$(sed -E 's/.*"payloadType":"([^"]*)".*/\1/' "$ENV")
$ sed -E 's/.*"payload":"([^"]*)".*/\1/' "$ENV" | openssl base64 -d -A > statement.json
$ sed -E 's/.*"sig":"([^"]*)".*/\1/' "$ENV" | openssl base64 -d -A > sig.der
$ { printf 'DSSEv1 %s %s %s ' "${#T}" "$T" "$(wc -c < statement.json | tr -d ' ')"; cat statement.json; } > pae.bin
$ openssl dgst -sha256 -verify "$PUB" -signature sig.der pae.bin
Verified OK
$ H=$(sed -E 's/.*"record_hash":"sha256:([0-9a-f]{64})".*/\1/' statement.json)
$ if [ "$(openssl dgst -sha256 -r "$REC" | cut -d' ' -f1)" = "$H" ]; then echo "record matches the statement"; else echo "RECORD DOES NOT MATCH THE STATEMENT"; fi
record matches the statement
$ printf 'record %s\n' "$(sed -nE 's/.*"record_id":"([^"]*)".*/\1/p' statement.json)"
record <the record id you picked>
$ printf 'subject %s\n' "$(sed -nE 's/.*"subject":\[\{"digest":\{"([^"]*)":"([^"]*)"\},"name":"([^"]*)"\}\].*/\3 \1:\2/p' statement.json)"
subject git+https://github.com/<owner>/<repository> gitCommit:<the commit you picked>
The envelope file is one line of JSON, as Toevan writes it; if it was re-formatted, put it back on one line first. Check the key against the key id Toevan publishes at api.toevan.com/v1/public/evidence/keys and prints in every report.
Provenance
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 GitHub’s deployment and release records and linked by commit or digest. Check the original record in GitHub.
- Not captured
- No reliable source was available. Toevan does not infer it. Obtain it from the organisation by other means.
What you receive
Four files, each with its hash.
Each file’s SHA-256 is listed, so you can confirm what you were given.
- Change evidence report
sha256:3f9a…c21ePDF - Records
sha256:[csv hash]CSV · merged changes, control changes, samples - Toevan public key
sha256:[key hash]toevan.pub · keyid 8c1f…e0a2 - Toevan command
sha256:[binary hash]toevan audit verify · provided by Toevan on request, not yet public
The key id is the one Toevan publishes at api.toevan.com/v1/public/evidence/keys and prints in every report.
Questions auditors ask
If a client hands you Toevan evidence, these usually come first.
Write to uspilots@toevan.com
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. Since 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 carry their own predicates. 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 since v1.4.0 as each pull request merges into the default branch, 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 are taken from GitHub’s deployment and release records and linked by commit or digest; check the original record in GitHub. 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. 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 and not yet public, 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. 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 gate verdicts can also be pushed into the client’s Kosli trails.
How do I test completeness, not just accuracy?
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, which is planned.
How are fixes copied to release branches handled?
Planned. 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, kept at least three years (5, 7 or 10 on Enterprise), 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. Each signed record checks with standard openssl against the published key, with the commands on the evidence branch, with no Toevan software. Checking past records does not depend on Toevan continuing to operate the service. Replaying the whole chain needs the Toevan verifier, which is available from Toevan on request and not yet public.
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.
- On a call, with your own tools
- Read-only access, nothing changes
- Verifiable without a Toevan account