Skip to content
toevan
Sign inBook an audit pilot
Open menuClose menu
Book an audit pilot

The system of record for code-level controls

Every code change, sealed as audit evidence.

Computed from the change itself, not claimed by a pipeline.

Book an audit pilotSee a sample report
  • EU processing · DPA
  • openssl · opt-in Rekor
  1. Checks what every change doesEvaluates the code itself, so no pipeline step can claim a pass, and blocks the merge with the rule, file and line.
  2. Records how it got inFrom v1.4.0: reviews, approvals, merges and production deployments, from GitHub’s own record, not a script your team maintains.
  3. Seals each verdict as evidenceSigned and chained, so your auditor verifies it offline without trusting us.

Works with

  • GitHub
  • Kosli
  • Sigstore
  • Slack
  • Jira
  • Linear

Evidence for

  • SOC 2
  • ISO/IEC 27001
  • PCI DSS v4.0
  • FedRAMP Moderate
  • HIPAA
  • GDPR
  • DORA
Evidence trailpayments-apimain

  1. e58c44aAdd refund webhook

    BlockedHardcoded secret in refund.ts, line 42

    prev 9f2c41aseal 4f2a9c1

  2. 3d10c97Read Stripe key from environment

    PassedResolves the block on e58c44a

    prev 4f2a9c1seal c81e07d

  3. 17aa93dLog settlement events

    ExceptionApproved by the security lead, expires 14 Nov

    prev c81e07dseal 6b39f20

toevan audit verify --path evidence-clone --pub-key toevan.pub
  • Chain intact across 4,812 records
  • Every signature verifies under the published key
  • Verified offline, with no Toevan account

Rules ask the model to behave. Toevan verifies it did.

AI assistants now write a large share of the code regulated teams merge, faster than any review process was designed for. A CLAUDE.md or .cursorrules file is a request. A merge gate is a control, and the record it writes is evidence, computed from the change itself rather than attested by the pipeline that ran it.

Across Fortune 50 enterprises, AI-generated code was adding more than 10,000 new security findings a month by June 2025, ten times the December 2024 level.Source: Apiiro, “4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks” (2025)

One gate, one record, every view an audit needs.

Toevan runs on every pull request and on main after each merge, and from v1.4.0 follows each change from commit to production: every merge, every change to your review rules, every production deployment. What it decides, it records, and what it records, your team and your auditors can see.

Coming in v1.4.0

Records how every change got in.

From v1.4.0, Toevan captures each merge, approval and change to your review rules from GitHub as it happens, and links each production deployment to the commit it shipped. Nothing slips between snapshots.

  • Independent approval on the final commit, required checks and the rules in force at merge
  • Review rules switched off, admin bypasses and direct pushes, captured as events
  • Protected branches and their rules, with every change sealed
  • A Process page that shows every merge and control change in one place
  • Every commit on main matched to the record that put it there, or flagged with the reason

Plannedv1.4.1: production branches you designate, such as a release branch, get the same population as main. Later: fixes on release branches matched by content.

Blocks the change and says exactly why.

Every pull request is checked as a GitHub check against the blueprints you adopt. A violation stops the merge with the rule, the exact file and line, and what it takes to pass. Deep Check covers what a pre-merge check can’t verify on its own.

  • 28 deterministic constraint types across compliance, security and architecture
  • Comments on the line, and posts its verdict as a review
  • Exceptions requested from the pull request, with a reason and an expiry
  • Suggested fixes, checked by build and blast-radius validation

Seals every decision as evidence.

Every gate run writes a signed, append-only record pinned to the commit and the rule-set version in force, and from v1.4.0 so does every merge and rule change. The chain verifies offline, and exports are ready for your auditor.

  • Hash-chained and signed, with built-in, opt-in anchoring in Sigstore’s public Rekor log (Enterprise can also use its own)
  • CSV and PDF exports per framework, repository and period
  • Retention of at least three years, with a copy in your own repository

Shows control status the way an audit asks for it.

Track every repository against the frameworks you’re audited for, see waivers before they expire, and give external auditors a read-only role for the evidence and reports.

  • A status badge for each repository’s README, with a link to the record
  • Change management with reviewer and approver evidence, from v1.4.0
  • Views for engineers, internal audit and external auditors

Your auditor can check it without trusting us.

Every sealed verdict is an in-toto statement with the SLSA verification summary predicate, in a DSSE envelope signed with ECDSA P-256. Stock tools check a record with no Toevan account; replaying the whole chain uses the Toevan verifier, available from Toevan on request. Inside the app, Verify now re-checks it for you, and signed verdicts can also be pushed into your Kosli flows.

  1. Clone the evidence, fetch the keys

    The evidence is on a toevan/evidence branch in your own repository, next to the code it describes: hash-linked and forward-only. Every key Toevan has signed with, current and retired, is published at a public address, with no sign-in.

  2. Check any record with openssl

    openssl checks one record with no Toevan software: the signature, and that the record file is the one the statement names. From v1.4.0 the reports and the evidence branch print these commands.

    openssl dgst -sha256 -verify toevan.pub -signature sig.der pae.bin

  3. Or check the signature with cosign

    From v1.4.0, Toevan documents a cosign v2 line that checks the signature and the statement type, not the record binding.

    cosign verify-blob-attestation --key toevan.pub --type https://slsa.dev/verification_summary/v1 --signature <envelope> --check-claims=false --insecure-ignore-tlog <envelope>

  4. Replay the whole chain

    One command replays the chain offline and checks every signature and every Rekor proof; if any record was removed or changed, the chain breaks. The Toevan verifier is available from Toevan on request.

    toevan audit verify --path evidence-clone --pub-key toevan.pub

  5. Match the report

    Each report carries a content digest: the SHA-256 of the manifest attached to the PDF. From v1.4.0, recount every commit that reached main with git and the report’s population CSV.

  6. Opt-in: confirm the public anchor

    Anchoring in Sigstore’s public Rekor transparency log is built in and opt-in per organisation; only record hashes are published. Inclusion proofs show each hash was logged when it was signed. Enterprise organisations can also anchor in their own Rekor.

Offline verification
$ toevan audit verify --path evidence-clone --pub-key toevan.pubreplaying hash chain: 4,812 records✓ chain intact✓ 4,812 attestation signatures verify under the published key

What one record contains

One change, as your auditor sees it when sampling: how it got in and what it does. Each fact says how it was obtained, so your auditor knows how far to rely on it. Code results are sealed on every pull request today, change records with process evidence and production deployments arrive in v1.4.0, and copies to release branches are planned. People appear as digests of their GitHub accounts.

rec_5b81d4e

northwind/payments-api · PR #1921

One merged change, signed and chained to the record before it.

Change records: coming in v1.4.0Example data

The change

Coming in v1.4.0
Pull request
Reported + sealed
payments-api #1921 · Add tenant check to refund handler
Author · merged by
Reported + sealed
4be1…09c2 · 9d07…e3a4 · 13 Oct 2026, 10:41 UTC into main
Merge commit
Reported + sealed
5b81d4e
Deployed to production
Reported + sealed
13 Oct 2026, 11:20 UTC · production (GitHub’s flag) · rec_9e41b07

Process evidence

Coming in v1.4.0
Approvals
Reported + sealed
9d07…e3a4, c58f…71d0 · both on final commit e81b2d0
Independent of author
Recomputed
Yes, by GitHub account id
Required checks
Reported + sealed
ci/test ✓ · ci/lint ✓ · toevan/gate ✓
Rules in force
Reported + sealed
main-protection: 2 approvals, required checks, signed commits
Commit signature
Reported + sealed
Verified by GitHub

Code evidence

Live today
Design rules
Recomputed
4 / 4 passing
Secure coding
Recomputed
7 / 8 passing · secret-detection-high under waiver rec_b30e7c5
Coverage · engine
Recomputed
98.1% (gate 95%) · toevan-engine 0.9.4

Path to production

Planned
Copied to release
Recomputed
Matched to the reviewed original by content

Seal

Signature
ECDSA P-256 · DSSE envelope · keyid 8c1f…e0a2
Previous record
rec_b7e21f0
Public anchor
Sigstore’s public Rekor log · built in, opt-in per organisation

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.

Complete on its own. Connected when you need it.

Toevan needs only your GitHub repositories to gate every change, seal the evidence and give auditors what they ask for, and from v1.4.0 to record each change from commit to production. Keep Semgrep, Snyk or CodeQL for depth, and if you run Kosli or a GRC platform, the same evidence goes there too.

Toevan

System of record for code-level controls

On its own

  • Pull request gate
  • Evidence sealed per change
  • Exceptions with expiry
  • Process evidence, v1.4.0
  • README status badge
  • Audit dashboards
Runs on your GitHub repositoriesConnected

Where the evidence can go

  • Your auditor

    Verifies any record offline, without a Toevan account

    No account

  • Kosli

    Signed attestations in your flows and trails

    Connected

  • Sigstore Rekor

    Built-in, opt-in anchoring of record hashes in the public log; Enterprise can also use its own instance

    Opt-in

  • Vanta, Drata or your register

    Reports attached per control and period

    Attach reports

  • Slack, Jira, Linear and webhooks

    Blocked pull requests and exceptions in Slack and webhooks; tasks from Jira and Linear

    Connected
  • Connected today
  • Opt-in: built in, per organisation
  • Works alongside: you attach Toevan’s reports
  • Verified offline with open tools

Built for the audit, and honest about its scope.

Every control software can evidence, mapped per framework: what Toevan evidences today, what process evidence adds in v1.4.0, and what is planned. The policy, people and physical controls no code tool can evidence are listed too, so a clean result is never read as more than it is.

Evidence for every engineering audit area

  • Change managementComing in v1.4.0
  • Secure developmentLive today
  • Vulnerability and dependency managementLive today
  • Access to code and separation of dutiesComing in v1.4.0
  • Evidence integrity and retentionLive today
Live
Coming in v1.4.0
Supporting
Planned
Your organisation
FrameworkControl mapLiveComing in v1.4.0PlannedControls code can evidenceSupporting
SOC 2Trust Services Criteria (2017)717151
+45 policy, people and physical controls (61 in all). No code tool evidences them; every report lists them.
ISO/IEC 270012022, Annex A11510262
+65 policy, people and physical controls (93 in all). No code tool evidences them; every report lists them.
PCI DSSv4.010115261
+36 policy, people and physical controls (63 in all). No code tool evidences them; every report lists them.
FedRAMP ModerateRev 5, NIST SP 800-53B14221374
+136 policy, people and physical controls (177 in all). No code tool evidences them; every report lists them.
HIPAA45 CFR Part 16480084
+30 policy, people and physical controls (42 in all). No code tool evidences them; every report lists them.
GDPRRegulation (EU) 2016/67930032
+35 policy, people and physical controls (40 in all). No code tool evidences them; every report lists them.
DORARegulation (EU) 2022/255420461
+20 policy, people and physical controls (27 in all). No code tool evidences them; every report lists them.

Toevan gives evidence for controls; it never certifies them or claims a framework is covered. Whether the evidence is sufficient is your auditor’s judgement.

Open the control maps

Your organisation’s process

What software can’t evidence stays with you and your other tools. Every report lists it, so a clean result is never read as more than it is.

  • organisational policy122
  • an operational process113
  • physical security48
  • contracts and vendors25
  • people and HR23
  • regulatory procedure23
  • an external assessment13

367 controls across the catalog

On the roadmap

Planned. Not in the product yet.

  • DORA RTS on ICT risk managementPlannedDelegated Regulation (EU) 2024/1774Art. 17 ICT change management with process evidence; Art. 16 development and maintenance with code evidence.
  • NIST SSDFPlannedSP 800-218 v1.1Secure development practices, from blueprints, reviews and dependency checks.
  • SLSAPlannedv1 specification (OpenSSF)Source track from protected branches and two-party review; build provenance planned.
  • OWASP Top 10Planned2021Rules mapped to the categories that can be checked in code.
  • EU Cyber Resilience ActPlannedRegulation (EU) 2024/2847Components, SBOM export and vulnerability handling.

What your auditor receives

Your auditor

Tests the evidence instead of taking it on trust.

Files to keep, a read-only view for the audit, and the instructions to check all of it themselves.

Three ways to check it

  1. In their browser, with no tools and no repository access
  2. Watching your engineer run the checks on samples they pick
  3. On their own machine, with git, openssl and the Toevan verifier on request
Open the sample reportRead the auditor FAQ
Live today

A report per framework

For any period and repository: a PDF for the file, plus a CSV of the records for testing.

  • PDF
  • CSV
Live today

The full evidence trail

Every code result and waiver, each pinned to its commit and the rule-set version in force, and from v1.4.0 every merge, approval and rule change.

  1. 4f2a9c1
  2. c81e07d
  3. 6b39f20
Coming in v1.4.0

Instructions that need no account

Each record checks offline with openssl, or cosign v2, against the published keys.

$ openssl dgst -sha256 -verify toevan.pub \
    -signature sig.der pae.bin
Verified OK
Coming in v1.4.0

Control changes as they happen

Review rules switched off, admin bypasses and direct pushes, sealed when they happen, so a gap between snapshots can’t go unseen.

19 Sep 14:02Review requirement switched offGap opened

Live today

Read-only access for auditors

An Auditor role that reads the evidence trail, the exports and the reports, and can re-verify the ledger. It sees no repositories and no code.

  • Read only
  • Evidence trail
  • Exports
  • Reports

Start free. Talk to us when the audit is real.

Every plan seals the same evidence and verifies the same way. Plans differ in scope, reports, workflows and where Toevan runs.

  • Free

    For a first repository and a first look at the gate.

    • Repositories: up to 2 in an organization, 1 in a personal account
    • Seats: up to 3 in an organization
    • Sealed evidence trail with export
    • Pull request gate and architecture canvas
    • Official blueprint marketplace
    • AI fixes: 10 a month
    Start free

  • Team

    Recommended

    Priced per governed repository and billed yearly, for organizations with five to a hundred repositories.

    • Repositories: 5 to 100, priced per governed repository, billed yearly
    • Seats: unlimited
    • Frameworks: every framework
    • Deep Check, under fair use
    • Per-repository roles
    • AI fixes: included, under fair use
    • Compliance reports in CSV and PDF
    • SSO (SAML and OIDC), coming soon

    Start with a pilot: one repository and one framework, through one audit cycle.

  • Enterprise

    More than a hundred repositories, or custom terms.

    • Repositories: more than 100
    • Self-hosted or private-VPC deployment, on request
    • Evidence retention: contractual
    • Priority support
    • Volume terms

There are no list prices yet. Team is priced per governed repository and billed yearly, and we agree it with you.

Questions we hear first

Straight answers on scope, determinism and where your code goes.

Something we haven’t answered?

Scope and fit

3 questions
Do we have to replace Vanta, Kosli or our scanners?

No. Toevan works on its own for the code layer, and alongside the tools you have. Keep your scanners for depth; Toevan’s own checks give every change a baseline and decide the merge against your rules. Signed verdicts flow into Kosli as attestations, and Toevan’s reports attach to controls in Vanta, Drata or your own register.

What Toevan adds is a sealed record computed from the change itself: what every change does, and from v1.4.0 how it got from commit to production, signed when it happened and verifiable without us.

Does a green report mean we’re compliant?

No, and every report says so. Toevan gives evidence for the controls that live in code, and from v1.4.0 in your change process. It never certifies a control or expresses an opinion on whether controls are designed or operating effectively. Access reviews, incident response, resilience testing, third-party risk and governance stay with your process, and every report lists exactly what it doesn’t cover.

Do you only support GitHub?

GitHub today, through a GitHub App with check runs and pull request annotations. From v1.4.0 it also reads merges, reviews, rule changes and production deployments as they happen. GitLab and Bitbucket are on the roadmap. If one of them is your blocker, tell us and it moves up.

How it runs

3 questions
Is the enforcement really deterministic?

Yes. Blueprint constraints are evaluated against the dependency graph with no model in the loop: same input, same verdict, every run. AI is used to suggest fixes and explain violations, never to decide whether code complies.

Does our code leave our boundary?

Analysis, blueprint evaluation, the pull request gate and evidence signing run on Toevan’s own EU infrastructure, and your source code is not sent outside it. Dependency checks send package names and versions, except those Toevan identifies as private, to public services such as OSV.dev. Optional AI features can send code-derived context to an EU provider or to your own provider key. Rekor anchoring, built in and opt-in per organisation, publishes record hashes only. Self-hosting is available on request. The full statement is on the Security page.

What happens when the gate is wrong?

You request an exception with a justification, scope and duration. The right owner reviews it, it expires on schedule, and the exception itself becomes evidence.

Bring one repository and your next audit.

We’re working with a small group of design partners in the second half of 2026: regulated teams shipping AI-assisted code, from Series B to enterprise. The first audit cycle is the proof.

Book an audit pilotSee a sample report
  • One repository, one framework
  • Evidence from the first pull request
  • Verifiable without a Toevan account