Sample change evidence report

1Summary

What was captured

Toevan captured the merges into the default branch, the changes to review rules, the bypasses and the direct pushes in both repositories as GitHub reported them, and sealed each one as it happened. In the period, 146 pull requests were merged and 2 commits were pushed directly. Reported + sealed

Items for attention

1. Two direct pushes to payments-api/release/v1 on 19 Sep, inside a 29-minute window when the review requirement was switched off.Process
2. Three pull requests merged without approval by someone other than the author: two in ledger-service before its review rule existed, one by admin bypass during the 19 Sep window.Process
3. Rule secret-detection-high fails in production code (1 finding), covered by an approved waiver until 20 Dec.Code, Waivers

2Scope, provenance and control mapping

How each fact was obtained

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.

Evidence and the controls it relates to

Not covered by this report

• Access reviews, joiner and leaver processesOrganisational
• Runtime monitoring, incident responseOrganisational
• ICT third-party risk, physical securityOrganisational
• Deployments and artifacts outside GitHub, and whether a deployed artifact still runsOrganisational
• Merges into branches other than the default branchNot in this version
• Changes made outside GitHub, such as direct database or console changesOrganisational

3Process evidence

How the 146 pull requests merged in the period were reviewed and merged, captured from GitHub at the moment of each merge.

Deviations: merged without independent approval

Changes to the controls themselves

Direct pushes without a pull request

Control changes and direct pushes are captured as events when they happen, so a gap between snapshots can’t go unseen. People are shown as digests of their GitHub accounts; independence is computed from the account ids. Reported + sealed

4Code evidence

What the code does, checked by reading the code itself on the exact merged version. Rules marked failing apply to production code; documentation and test fixtures are out of scope (see Waivers).

How far the analysis reached

Coverage is the share of the repository’s production source files that the code index parsed at the indexed commit. Below the gate, a run is flagged rather than recorded as passing. Engine and rule-set versions are recorded in every record, so any result can be re-run. Recomputed

5Waivers and scope changes

Every decision that changed what was checked, or accepted a known deviation.

No waivers expired or were revoked in the period. Requester and approver are different accounts for every entry. Waivers are Toevan records that are not sealed in the ledger. Toevan record, not sealed

Rule-set versions used in the period

6Change records

One change in full, as the auditor sees it when sampling. All records are in the CSV export, and each signed envelope is on the evidence branch in the organisation’s repository.

Further records (sample)

7How to check this report

Each route lets you test the evidence yourself. Choose the route that fits your role. Only the third needs any tools.

1. In the organisation’s app

   Read-only auditor access, no repository access

   • The organisation invites you with the Auditor role: read-only access to the evidence list, the exports and the reports.
   • Verify now re-checks the whole ledger, the signatures and any transparency log proofs in the app.
   • You open nothing else: repositories, code and findings are refused.

2. Watch the organisation run it

   Screen share or on site

   • You choose the samples at the time of the session; an engineer runs the checks while you watch.
   • Verification of each record you sampled: chain, signature, unchanged.
   • Author and approver accounts for each sample, compared on screen.

3. Run it yourself

   IT audit specialists with temporary read access

   • Use git and openssl. For the whole chain, use the toevan command, which Toevan provides on request and is not yet public. No Toevan account is needed.
   • Check that a copy’s branch tips match the tips recorded in the report.
   • Run the commands in the appendix and compare against the report.

8Planned additionsPlanned

Later layers of the evidence chain. They are planned and nothing in this report depends on them. Each says how its facts will be obtained.

• Designated production branches

  Branches the organisation designates as production, such as a release branch, each designation declared and sealed with every later change. Each gets the same population as the default branch: every commit listed straight from git and matched to a record or flagged.

  Declared + sealedRecomputed

• Copied fixes matched by content

  A fix reviewed on main and copied to a release branch gets a new commit ID. Toevan will match it to the reviewed original by content (git patch-id), and flag copies whose content changed.

  Recomputed

Appendix · Commands for technical reviewers

The commands an engineer runs for you, or you run yourself.

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
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
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
printf 'record %s\n' "$(sed -nE 's/.*"record_id":"([^"]*)".*/\1/p' statement.json)"
printf 'subject %s\n' "$(sed -nE 's/.*"subject":\[\{"digest":\{"([^"]*)":"([^"]*)"\},"name":"([^"]*)"\}\].*/\3 \1:\2/p' statement.json)"

SHA2-256(stdin)= <key id>
Verified OK
record matches the statement
record <the record id you picked>
subject git+https://github.com/<owner>/<repository> gitCommit:<the commit you picked>

$ toevan audit verify --path evidence-clone --pub-key toevan.pub
✓ chain intact · 4,152 records
✓ signatures verify under the published key