Zum Inhalt springen
toevan
AnmeldenAudit-Pilot buchen
Menü öffnenMenü schließen
Audit-Pilot buchen

Das System of Record für Controls auf Code-Ebene

Jede Code-Änderung, versiegelt als Audit-Nachweis.

Aus der Änderung selbst berechnet, nicht von einer Pipeline behauptet.

Audit-Pilot buchenBeispielbericht ansehen
  • EU-Verarbeitung · AVV
  • openssl · Rekor-Opt-in
  1. Prüft, was jede Änderung bewirktPrüft den Code selbst, damit kein Pipeline-Schritt einen Erfolg behaupten kann, und blockiert den Merge mit Regel, Datei und Zeile.
  2. Erfasst, wie sie hineinkamAb v1.4.0: Reviews, Freigaben, Merges und Produktions-Deployments, aus GitHubs eigener Aufzeichnung, nicht aus einem Skript Ihres Teams.
  3. Versiegelt jedes Urteil als NachweisSigniert und verkettet, damit Ihr Auditor es offline prüft, ohne uns zu vertrauen.

Arbeitet mit

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

Evidenz für

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

  1. e58c44aAdd refund webhook

    BlockiertHartkodiertes Secret in refund.ts, Zeile 42

    vorher 9f2c41aSiegel 4f2a9c1

  2. 3d10c97Read Stripe key from environment

    BestandenHebt die Blockade auf e58c44a auf

    vorher 4f2a9c1Siegel c81e07d

  3. 17aa93dLog settlement events

    AusnahmeVom Security Lead genehmigt, läuft am 14. Nov. ab

    vorher c81e07dSiegel 6b39f20

toevan audit verify --path evidence-clone --pub-key toevan.pub
  • Kette intakt über 4.812 Einträge
  • Jede Signatur stimmt mit dem veröffentlichten Schlüssel überein
  • Offline geprüft, ohne Toevan-Konto

Regeln bitten das Modell, sich zu benehmen. Toevan prüft, ob es das getan hat.

KI-Assistenten schreiben heute einen großen Teil des Codes, den regulierte Teams mergen, schneller, als irgendein Review-Prozess ausgelegt ist. Eine CLAUDE.md oder .cursorrules ist eine Bitte. Ein Merge-Gate ist ein Control, und der Eintrag, den es schreibt, ist ein Nachweis, aus der Änderung selbst berechnet statt von der Pipeline attestiert, die sie ausgeführt hat.

In Fortune-50-Unternehmen fügte KI-generierter Code bis Juni 2025 mehr als 10.000 neue Security-Befunde pro Monat hinzu, das Zehnfache des Niveaus von Dezember 2024.Quelle: Apiiro, „4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks“ (2025)

Ein Gate, ein Eintrag, jede Ansicht, die ein Audit braucht.

Toevan läuft bei jedem Pull Request und nach jedem Merge auf main, und ab v1.4.0 begleitet es jede Änderung vom Commit bis in die Produktion: jeden Merge, jede Änderung Ihrer Review-Regeln, jedes Produktions-Deployment. Was es entscheidet, hält es fest, und was es festhält, können Ihr Team und Ihre Auditoren sehen.

Kommt in v1.4.0

Erfasst, wie jede Änderung hineinkam.

Ab v1.4.0 erfasst Toevan jeden Merge, jede Freigabe und jede Änderung Ihrer Review-Regeln beim Eintreten aus GitHub und verknüpft jedes Produktions-Deployment mit dem ausgelieferten Commit. Nichts rutscht zwischen Momentaufnahmen durch.

  • Unabhängige Freigabe auf dem finalen Commit, Pflicht-Checks und die beim Merge geltenden Regeln
  • Ausgeschaltete Review-Regeln, Admin-Umgehungen und direkte Pushes, als Ereignisse erfasst
  • Geschützte Branches und ihre Regeln, jede Änderung versiegelt
  • Eine Prozess-Seite, die jeden Merge und jede Control-Änderung an einem Ort zeigt
  • Jeder Commit auf main dem Eintrag zugeordnet, der ihn dorthin brachte, oder mit Grund markiert

Geplantv1.4.1: Produktions-Branches, die Sie festlegen, etwa ein Release-Branch, erhalten dieselbe Grundgesamtheit wie main. Später: per Inhalt zugeordnete Fixes auf Release-Branches.

Blockiert die Änderung und sagt genau, warum.

Jeder Pull Request wird als GitHub Check gegen die von Ihnen übernommenen Blueprints geprüft. Ein Verstoß stoppt den Merge mit Regel, exakter Datei und Zeile und dem, was zum Bestehen fehlt. Deep Check deckt ab, was eine Prüfung vor dem Merge allein nicht verifizieren kann.

  • 28 deterministische Constraint-Typen für Compliance, Security und Architektur
  • Kommentiert die Zeile und gibt sein Urteil als Review ab
  • Ausnahmen direkt im Pull Request beantragt, mit Begründung und Ablaufdatum
  • Fix-Vorschläge, geprüft durch Build- und Blast-Radius-Validierung

Versiegelt jede Entscheidung als Nachweis.

Jeder Gate-Lauf schreibt einen signierten, nur anhängbaren Eintrag, festgemacht am Commit und an der geltenden Regelsatz-Version, und ab v1.4.0 gilt das auch für jeden Merge und jede Regeländerung. Die Kette lässt sich offline prüfen, und Exporte sind für Ihren Auditor bereit.

  • Per Hash verkettet und signiert, mit eingebauter Verankerung im öffentlichen Rekor-Log von Sigstore als Opt-in (Enterprise auch im eigenen)
  • CSV- und PDF-Exporte je Framework, Repository und Zeitraum
  • Aufbewahrung von mindestens drei Jahren, mit Kopie im eigenen Repository

Zeigt den Control-Status so, wie ein Audit ihn verlangt.

Verfolgen Sie jedes Repository gegen die Frameworks, für die Sie geprüft werden, sehen Sie Ausnahmegenehmigungen vor ihrem Ablauf und geben Sie externen Auditoren eine Nur-Lese-Rolle für Nachweise und Berichte.

  • Ein Status-Badge für die README jedes Repositories, mit Link zum Eintrag
  • Änderungsmanagement mit Nachweisen zu Reviewern und Freigebenden, ab v1.4.0
  • Ansichten für Engineers, interne Revision und externe Auditoren

Ihr Auditor kann es prüfen, ohne uns zu vertrauen.

Jedes versiegelte Urteil ist ein in-toto-Statement mit dem SLSA-Verification-Summary-Prädikat in einem DSSE-Envelope, signiert mit ECDSA P-256. Gängige Werkzeuge prüfen einen Eintrag ohne Toevan-Konto; die ganze Kette spielt der Toevan-Verifier nach, auf Anfrage bei Toevan erhältlich. In der App prüft „Jetzt prüfen“ alles erneut für Sie, und signierte Urteile lassen sich auch in Ihre Kosli-Flows übertragen.

  1. Nachweise klonen, Schlüssel holen

    Die Nachweise liegen auf einem Branch toevan/evidence in Ihrem eigenen Repository, neben dem Code, den sie beschreiben: per Hash verkettet und nur vorwärts geschrieben. Jeder Schlüssel, mit dem Toevan signiert hat, aktuell und ausgemustert, ist unter einer öffentlichen Adresse veröffentlicht, ohne Anmeldung.

  2. Jeden Eintrag mit openssl prüfen

    openssl prüft einen Eintrag ohne Toevan-Software: die Signatur und dass die Eintragsdatei die ist, die das Statement nennt. Ab v1.4.0 drucken die Berichte und der Evidence-Branch diese Befehle.

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

  3. Oder die Signatur mit cosign prüfen

    Ab v1.4.0 dokumentiert Toevan eine cosign-v2-Zeile, die die Signatur und den Statement-Typ prüft, nicht die Bindung an den Eintrag.

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

  4. Die ganze Kette nachspielen

    Ein Befehl spielt die Kette offline nach und prüft jede Signatur und jeden Rekor-Beleg; wurde ein Eintrag entfernt oder geändert, bricht die Kette. Den Toevan-Verifier gibt es auf Anfrage bei Toevan.

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

  5. Den Bericht abgleichen

    Jeder Bericht trägt einen Inhalts-Digest: den SHA-256 des Manifests, das dem PDF beiliegt. Ab v1.4.0 zählen Sie jeden Commit, der main erreicht hat, mit git und der CSV-Datei der Grundgesamtheit des Berichts nach.

  6. Opt-in: öffentlichen Anker bestätigen

    Die Verankerung im öffentlichen Rekor-Transparenz-Log von Sigstore ist eingebaut, als Opt-in je Organisation; veröffentlicht werden nur Eintrags-Hashes. Inclusion Proofs zeigen, dass jeder Hash beim Signieren protokolliert wurde. Enterprise-Organisationen können auch in ihrem eigenen Rekor verankern.

Offline-Prüfung
$ 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

Was ein Eintrag enthält

Eine Änderung, so wie Ihr Auditor sie bei der Stichprobe sieht: wie sie hineinkam und was sie bewirkt. Jeder Fakt nennt, wie er erhoben wurde, damit Ihr Auditor weiß, wie weit er sich darauf stützen kann. Code-Ergebnisse werden heute bei jedem Pull Request versiegelt, Änderungseinträge mit Prozessnachweis und Produktions-Deployments kommen in v1.4.0, und Kopien auf Release-Branches sind geplant. Personen erscheinen als Digests ihrer GitHub-Konten.

rec_5b81d4e

northwind/payments-api · PR #1921

Eine gemergte Änderung, signiert und mit dem Eintrag davor verkettet.

Änderungseinträge: kommen in v1.4.0Beispieldaten

Die Änderung

Kommt in v1.4.0
Pull Request
Gemeldet + versiegelt
payments-api #1921 · Add tenant check to refund handler
Autor · gemergt von
Gemeldet + versiegelt
4be1…09c2 · 9d07…e3a4 · 13. Okt. 2026, 10:41 UTC in main
Merge-Commit
Gemeldet + versiegelt
5b81d4e
In Produktion deployt
Gemeldet + versiegelt
13. Okt. 2026, 11:20 UTC · Produktion (GitHub-Kennzeichnung) · rec_9e41b07

Prozessnachweis

Kommt in v1.4.0
Freigaben
Gemeldet + versiegelt
9d07…e3a4, c58f…71d0 · beide auf dem finalen Commit e81b2d0
Unabhängig vom Autor
Neu berechnet
Ja, nach GitHub-Konto-ID
Pflicht-Checks
Gemeldet + versiegelt
ci/test ✓ · ci/lint ✓ · toevan/gate ✓
Geltende Regeln
Gemeldet + versiegelt
main-protection: 2 Freigaben, Pflicht-Checks, signierte Commits
Commit-Signatur
Gemeldet + versiegelt
Von GitHub geprüft

Code-Nachweis

Heute live
Designregeln
Neu berechnet
4 / 4 bestanden
Sicheres Coding
Neu berechnet
7 / 8 bestanden · secret-detection-high unter Ausnahmegenehmigung rec_b30e7c5
Abdeckung · Engine
Neu berechnet
98,1 % (Gate 95 %) · toevan-engine 0.9.4

Weg in die Produktion

Geplant
In Release kopiert
Neu berechnet
Per Inhalt dem geprüften Original zugeordnet

Siegel

Signatur
ECDSA P-256 · DSSE-Envelope · keyid 8c1f…e0a2
Vorheriger Eintrag
rec_b7e21f0
Öffentlicher Anker
Öffentliches Rekor-Log von Sigstore · eingebaut, Opt-in je Organisation

Wie jeder Fakt erhoben wurde

Jeder Fakt in einem Eintrag und einem Bericht trägt eines von sechs Labels, damit Ihr Auditor weiß, wie weit er sich darauf stützen kann.

Neu berechnet
Toevan hat es selbst aus Code oder Git-Historie berechnet.
Mit denselben Eingaben nachvollziehen und dasselbe Ergebnis erhalten.
Gemeldet + versiegelt
GitHub hat es gemeldet; Toevan hat es beim Ereignis erfasst und signiert.
Verlassen Sie sich darauf, soweit Sie GitHub vertrauen. Jede spätere Änderung ist erkennbar.
Erklärt + versiegelt
Die Organisation hat es erklärt, etwa eine Änderung dessen, was geprüft wird; Toevan hat die Erklärung und ihre Historie signiert.
Sehen Sie, wer was wann erklärt hat, und jede spätere Änderung.
Toevan-Eintrag, nicht versiegelt
In der Datenbank von Toevan gespeichert, aber nicht im Ledger versiegelt, etwa eine Ausnahmegenehmigung heute. Keine Signatur schützt ihn.
Behandeln Sie ihn als Aussage von Toevan und fragen Sie die Organisation nach der Freigabe dahinter.
Übernommen
Aus dem signierten Eintrag eines anderen Systems übernommen, etwa einer Build-Provenienz, und per Commit oder Digest verknüpft. Geplant.
Den Originaleintrag unabhängig prüfen.
Nicht erfasst
Es gab keine verlässliche Quelle. Toevan schließt nichts daraus.
Auf anderem Weg bei der Organisation einholen.

Vollständig für sich. Verbunden, wenn Sie es brauchen.

Toevan braucht nur Ihre GitHub-Repositories, um jede Änderung zu prüfen, Nachweise zu versiegeln und Auditoren zu geben, was sie verlangen, und ab v1.4.0 jede Änderung vom Commit bis in die Produktion zu erfassen. Behalten Sie Semgrep, Snyk oder CodeQL für die Tiefe, und wenn Sie Kosli oder eine GRC-Plattform nutzen, gehen dieselben Nachweise auch dorthin.

Toevan

System of Record für Controls auf Code-Ebene

Für sich allein

  • Pull-Request-Gate
  • Nachweis pro Änderung versiegelt
  • Ausnahmen mit Ablaufdatum
  • Prozessnachweis, v1.4.0
  • README-Status-Badge
  • Audit-Dashboards
Läuft auf Ihren GitHub-RepositoriesVerbunden

Wohin die Nachweise gehen können

  • Ihr Auditor

    Prüft jeden Eintrag offline, ohne Toevan-Konto

    Kein Konto

  • Kosli

    Signierte Attestierungen in Ihren Flows und Trails

    Verbunden

  • Sigstore Rekor

    Eingebaute Verankerung von Eintrags-Hashes im öffentlichen Log, als Opt-in; Enterprise auch in einer eigenen Instanz

    Opt-in

  • Vanta, Drata oder Ihr Register

    Berichte pro Control und Zeitraum angehängt

    Berichte anhängen

  • Slack, Jira, Linear und Webhooks

    Blockierte Pull Requests und Ausnahmen in Slack und Webhooks; Aufgaben aus Jira und Linear

    Verbunden
  • Heute verbunden
  • Opt-in: eingebaut, je Organisation
  • Arbeitet nebenher: Sie hängen Toevans Berichte an
  • Offline mit offenen Werkzeugen geprüft

Gebaut für das Audit, ehrlich beim Umfang.

Jedes Control, das Software belegen kann, je Framework zugeordnet: was Toevan heute belegt, was Prozessnachweise in v1.4.0 ergänzen und was geplant ist. Die Richtlinien-, Personen- und physischen Controls, die kein Code-Werkzeug belegen kann, sind ebenfalls aufgeführt, damit ein sauberes Ergebnis nie als mehr gelesen wird, als es ist.

Nachweise für jeden Engineering-Prüfbereich

  • ÄnderungsmanagementKommt in v1.4.0
  • Sichere EntwicklungHeute live
  • Schwachstellen- und AbhängigkeitsmanagementHeute live
  • Zugriff auf Code und FunktionstrennungKommt in v1.4.0
  • Integrität und Aufbewahrung von NachweisenHeute live
Live
Kommt in v1.4.0
Unterstützend
Geplant
Ihre Organisation
FrameworkControl-MapLiveKommt in v1.4.0GeplantControls, die Code belegen kannUnterstützend
SOC 2Trust Services Criteria (2017)717151
+45 Richtlinien-, Personen- und physische Controls (61 insgesamt). Kein Code-Werkzeug belegt sie; jeder Bericht listet sie auf.
ISO/IEC 270012022, Annex A11510262
+65 Richtlinien-, Personen- und physische Controls (93 insgesamt). Kein Code-Werkzeug belegt sie; jeder Bericht listet sie auf.
PCI DSSv4.010115261
+36 Richtlinien-, Personen- und physische Controls (63 insgesamt). Kein Code-Werkzeug belegt sie; jeder Bericht listet sie auf.
FedRAMP ModerateRev 5, NIST SP 800-53B14221374
+136 Richtlinien-, Personen- und physische Controls (177 insgesamt). Kein Code-Werkzeug belegt sie; jeder Bericht listet sie auf.
HIPAA45 CFR Part 16480084
+30 Richtlinien-, Personen- und physische Controls (42 insgesamt). Kein Code-Werkzeug belegt sie; jeder Bericht listet sie auf.
GDPRVerordnung (EU) 2016/67930032
+35 Richtlinien-, Personen- und physische Controls (40 insgesamt). Kein Code-Werkzeug belegt sie; jeder Bericht listet sie auf.
DORAVerordnung (EU) 2022/255420461
+20 Richtlinien-, Personen- und physische Controls (27 insgesamt). Kein Code-Werkzeug belegt sie; jeder Bericht listet sie auf.

Toevan liefert Nachweise für Controls; es zertifiziert sie nie und behauptet nie, ein Framework sei abgedeckt. Ob die Nachweise genügen, beurteilt Ihr Auditor.

Control-Maps öffnen

Der Prozess Ihrer Organisation

Was Software nicht belegen kann, bleibt bei Ihnen und Ihren anderen Werkzeugen. Jeder Bericht listet es auf, damit ein sauberes Ergebnis nie als mehr gelesen wird, als es ist.

  • die Richtlinien der Organisation122
  • einen betrieblichen Prozess113
  • die physische Sicherheit48
  • Verträge und Lieferanten25
  • Personal und HR23
  • ein regulatorisches Verfahren23
  • eine externe Prüfung13

367 Controls im gesamten Katalog

Auf der Roadmap

Geplant. Noch nicht im Produkt.

  • DORA RTS zum IKT-RisikomanagementGeplantDelegierte Verordnung (EU) 2024/1774Art. 17 IKT-Änderungsmanagement mit Prozessnachweis; Art. 16 Entwicklung und Wartung mit Code-Nachweis.
  • NIST SSDFGeplantSP 800-218 v1.1Sichere Entwicklungspraktiken, aus Blueprints, Reviews und Abhängigkeitsprüfungen.
  • SLSAGeplantv1-Spezifikation (OpenSSF)Source Track aus geschützten Branches und Review durch zwei Personen; Build-Provenienz geplant.
  • OWASP Top 10Geplant2021Regeln, zugeordnet zu den Kategorien, die sich im Code prüfen lassen.
  • EU Cyber Resilience ActGeplantVerordnung (EU) 2024/2847Komponenten, SBOM-Export und Umgang mit Schwachstellen.

Was Ihr Auditor erhält

Ihr Auditor

Testet die Nachweise, statt ihnen zu glauben.

Dateien zum Aufbewahren, eine Nur-Lese-Ansicht für das Audit und die Anleitung, alles selbst zu prüfen.

Drei Wege zu prüfen

  1. Im eigenen Browser, ohne Werkzeuge und ohne Repository-Zugriff
  2. Zusehen, wie Ihr Engineer die Prüfungen an selbst gewählten Stichproben ausführt
  3. Auf dem eigenen Rechner, mit git, openssl und dem Toevan-Verifier auf Anfrage
Beispielbericht öffnenFAQ für Auditoren lesen
Heute live

Ein Bericht pro Framework

Für jeden Zeitraum und jedes Repository: ein PDF für die Akte, dazu eine CSV der Einträge für Tests.

  • PDF
  • CSV
Heute live

Die vollständige Nachweisspur

Jedes Code-Ergebnis und jede Ausnahmegenehmigung, jeweils am Commit und an der geltenden Regelsatz-Version festgemacht, und ab v1.4.0 jeder Merge, jede Freigabe und jede Regeländerung.

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

Anleitung ohne Konto

Jeder Eintrag lässt sich offline mit openssl oder cosign v2 gegen die veröffentlichten Schlüssel prüfen.

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

Control-Änderungen, sobald sie eintreten

Ausgeschaltete Review-Regeln, Admin-Umgehungen und direkte Pushes, beim Eintreten versiegelt, damit keine Lücke zwischen Momentaufnahmen unbemerkt bleibt.

19. Sep. 14:02Review-Pflicht ausgeschaltetLücke geöffnet

Heute live

Nur-Lese-Zugriff für Auditoren

Eine Auditor-Rolle, die Nachweisspur, Exporte und Berichte liest und das Ledger erneut prüfen kann. Sie sieht keine Repositories und keinen Code.

  • Nur lesend
  • Nachweisspur
  • Exporte
  • Berichte

Kostenlos starten. Sprechen Sie mit uns, wenn das Audit ernst wird.

Jeder Plan versiegelt dieselben Nachweise und wird gleich geprüft. Die Pläne unterscheiden sich bei Umfang, Berichten, Workflows und dem Ort, an dem Toevan läuft.

  • Free

    Für ein erstes Repository und einen ersten Blick auf das Gate.

    • Repositories: bis zu 2 in einer Organisation, 1 in einem persönlichen Konto
    • Plätze: bis zu 3 in einer Organisation
    • Versiegelte Nachweisspur mit Export
    • Pull-Request-Gate und Architektur-Canvas
    • Offizieller Blueprint-Marktplatz
    • KI-Fixes: 10 im Monat
    Kostenlos starten

  • Team

    Empfohlen

    Pro verwaltetem Repository bepreist und jährlich abgerechnet, für Organisationen mit fünf bis hundert Repositories.

    • Repositories: 5 bis 100, pro verwaltetem Repository bepreist, jährlich abgerechnet
    • Plätze: unbegrenzt
    • Frameworks: jedes Framework
    • Deep Check, im Rahmen angemessener Nutzung
    • Rollen pro Repository
    • KI-Fixes: enthalten, im Rahmen angemessener Nutzung
    • Compliance-Berichte als CSV und PDF
    • SSO (SAML und OIDC), kommt bald

    Starten Sie mit einem Pilot: ein Repository und ein Framework, durch einen Audit-Zyklus.

  • Enterprise

    Mehr als hundert Repositories oder individuelle Konditionen.

    • Repositories: mehr als 100
    • Self-Hosted- oder Private-VPC-Betrieb, auf Anfrage
    • Aufbewahrung der Nachweise: vertraglich
    • Bevorzugter Support
    • Mengenkonditionen

Listenpreise gibt es noch nicht. Team wird pro verwaltetem Repository bepreist und jährlich abgerechnet, und wir vereinbaren es mit Ihnen.

Die Fragen, die wir zuerst hören

Klare Antworten zu Umfang, Determinismus und dazu, wohin Ihr Code geht.

Etwas offen geblieben?

Umfang und Passung

3 Fragen
Müssen wir Vanta, Kosli oder unsere Scanner ersetzen?

Nein. Toevan arbeitet für die Code-Ebene allein und neben den Werkzeugen, die Sie haben. Behalten Sie Ihre Scanner für die Tiefe; Toevans eigene Prüfungen geben jeder Änderung eine Basis und entscheiden den Merge anhand Ihrer Regeln. Signierte Urteile fließen als Attestierungen in Kosli, und Toevans Berichte lassen sich an Controls in Vanta, Drata oder Ihrem eigenen Register anhängen.

Toevan ergänzt einen versiegelten Eintrag, aus der Änderung selbst berechnet: was jede Änderung bewirkt, und ab v1.4.0 auch ihren Weg vom Commit bis in die Produktion, signiert, als es geschah, und prüfbar ohne uns.

Heißt ein grüner Bericht, dass wir alles erfüllen?

Nein, und jeder Bericht sagt das. Toevan liefert Nachweise für die Controls, die im Code liegen, und ab v1.4.0 in Ihrem Änderungsprozess. Es zertifiziert nie ein Control und äußert keine Meinung dazu, ob Controls angemessen gestaltet sind oder wirksam arbeiten. Zugriffsprüfungen, Incident Response, Resilienztests, Drittparteirisiko und Governance bleiben bei Ihrem Prozess, und jeder Bericht listet genau auf, was er nicht abdeckt.

Unterstützen Sie nur GitHub?

Heute GitHub, über eine GitHub App mit Check Runs und Annotationen am Pull Request. Ab v1.4.0 liest es zusätzlich Merges, Reviews, Regeländerungen und Produktions-Deployments beim Eintreten. GitLab und Bitbucket stehen auf der Roadmap. Wenn eines davon Ihr Hindernis ist, sagen Sie es uns, dann rückt es nach oben.

Wie es läuft

3 Fragen
Ist die Durchsetzung wirklich deterministisch?

Ja. Blueprint-Constraints werden gegen den Abhängigkeitsgraphen ausgewertet, ohne Modell in der Schleife: gleiche Eingabe, gleiches Urteil, bei jedem Lauf. KI schlägt Fixes vor und erklärt Verstöße, sie entscheidet nie, ob Code die Regeln einhält.

Verlässt unser Code unsere Grenze?

Analyse, Blueprint-Auswertung, Pull-Request-Gate und Signierung der Nachweise laufen auf Toevans eigener EU-Infrastruktur, und Ihr Quellcode wird nicht außerhalb davon gesendet. Abhängigkeitsprüfungen senden Paketnamen und Versionen, außer solchen, die Toevan als privat erkennt, an öffentliche Dienste wie OSV.dev. Optionale KI-Funktionen können aus dem Code abgeleiteten Kontext an einen EU-Anbieter oder an Ihren eigenen Anbieter-Schlüssel senden. Die Rekor-Verankerung, eingebaut und als Opt-in je Organisation, veröffentlicht nur Eintrags-Hashes. Self-Hosting ist auf Anfrage möglich. Die vollständige Erklärung steht auf der Seite Sicherheit.

Was passiert, wenn das Gate falsch liegt?

Sie beantragen eine Ausnahme mit Begründung, Umfang und Dauer. Die zuständige Person prüft sie, sie läuft planmäßig ab, und die Ausnahme selbst wird zum Nachweis.

Bringen Sie ein Repository und Ihr nächstes Audit mit.

Wir arbeiten in der zweiten Hälfte 2026 mit einer kleinen Gruppe von Design-Partnern: regulierte Teams, die KI-gestützten Code ausliefern, von Series B bis Enterprise. Der erste Audit-Zyklus ist der Beweis.

Audit-Pilot buchenBeispielbericht ansehen
  • Ein Repository, ein Framework
  • Nachweise ab dem ersten Pull Request
  • Prüfbar ohne Toevan-Konto