Nachweise, die Sie testen können, statt ihnen zu glauben.

Eine signierte Aussage über ein einzelnes Ereignis. Heute ist das eine Code-Prüfung auf einem Pull Request oder auf main. Ab v1.4.0 gehören auch ein Merge, eine geänderte Review-Regel oder ein direkter Push dazu. Ein Änderungseintrag nennt den Pull Request, wer ihn verfasst, freigegeben und gemergt hat, die geltenden Checks und Regeln und die Code-Ergebnisse, jeder Fakt mit Label, wie er erhoben wurde. Personen erscheinen als Digests ihrer GitHub-Konten.

Technisch ist es ein in-toto-Statement mit dem SLSA-Verification-Summary-Prädikat in einem DSSE-Envelope, signiert mit ECDSA P-256; die Prädikate weiterer Eintragsarten kommen mit v1.4.0. Die Verankerung im öffentlichen Rekor-Transparenz-Log von Sigstore ist eingebaut, als Opt-in je Organisation; veröffentlicht werden nur Eintrags-Hashes. Enterprise-Organisationen können auch in ihrem eigenen Rekor verankern.

Wenn das Ereignis eintritt: heute bei jeder Code-Prüfung, ab v1.4.0 bei jedem Merge eines Pull Requests, jeder Änderung einer Review-Regel oder jedem Push, der das Review umgeht. Einträge werden nicht nachträglich aus Logs oder Tickets zusammengesetzt, daher bleibt keine Lücke zwischen Momentaufnahmen unbemerkt.

Neu berechnete Fakten hat Toevan aus Code oder Git-Historie berechnet, und Sie können sie nachvollziehen. Gemeldet + versiegelte Fakten kamen von GitHub und wurden beim Ereignis signiert, Sie verlassen sich darauf, soweit Sie GitHub vertrauen. Erklärt + versiegelte Fakten, etwa eine Änderung dessen, was geprüft wird, hat die Organisation samt Historie erklärt. Ausnahmegenehmigungen sind Toevan-Einträge, die heute nicht im Ledger versiegelt sind, und der Bericht sagt das. Übernommene Fakten stammen künftig aus dem signierten Eintrag eines anderen Systems, etwa aus Build-Provenienz; das ist geplant. Nicht erfasst heißt: Es gab keine verlässliche Quelle, und Toevan schließt nichts daraus.

Ja. Regeln werden gegen den Code-Graphen des Repositories ausgewertet, ohne Machine-Learning-Modell in der Entscheidung. Derselbe Commit, dieselbe Engine-Version und dieselbe Regelsatz-Version ergeben immer dasselbe Ergebnis, sodass Sie eine gezogene Auswertung erneut laufen lassen und ein identisches Ergebnis erwarten können.

In der App prüft „Jetzt prüfen“ die Hash-Kette, jede Signatur und die gespeicherten Belege erneut. Das läuft in Toevan.

Mit gängigen Werkzeugen und ohne Toevan-Konto prüft openssl einen Eintrag gegen die öffentliche Liste aller Schlüssel, mit denen Toevan signiert hat, aktuell und ausgemustert: die Signatur und dass die Eintragsdatei die ist, die das Statement nennt. Ab v1.4.0 drucken die Berichte und der Evidence-Branch die Befehle, und Toevan dokumentiert eine cosign-v2-Zeile, die die Signatur und den Statement-Typ prüft, nicht die Bindung an den Eintrag.

Mit dem Toevan-Verifier, auf Anfrage bei Toevan erhältlich, spielt ein Befehl die ganze Kette offline nach und prüft jede Signatur und jeden Rekor-Beleg.

Mit git lesen Sie die Nachweise auf einem per Hash verketteten, nur vorwärts geschriebenen Branch toevan/evidence im eigenen Repository des Kunden, und jeder Bericht trägt einen Inhalts-Digest, den SHA-256 des Manifests, das dem PDF beiliegt. Ab v1.4.0 können Sie außerdem die Grundgesamtheit der Änderungen mit git und der CSV-Datei des Berichts nachzählen.

Die Verankerung im öffentlichen Rekor-Transparenz-Log von Sigstore ist eingebaut, als Opt-in je Organisation; veröffentlicht werden nur Eintrags-Hashes. Signierte Urteile lassen sich auch in die Kosli-Flows des Kunden übertragen.

Ab v1.4.0 listet der Änderungsnachweis-Bericht jeden Commit, der im Zeitraum den Standard-Branch erreicht hat, direkt aus der Git-Historie und ordnet jeden dem Eintrag des gemergten Pull Requests oder Pushes zu, der ihn dorthin gebracht hat. Ein Commit, den kein Eintrag erklärt, wird mit Grund markiert, nie erschlossen. Sie können die Grundgesamtheit mit git anhand der CSV-Datei der Grundgesamtheit selbst nachvollziehen. Jedes Deployment, das GitHub als Produktion kennzeichnet, wird mit dem ausgelieferten Commit verknüpft. Produktions-Branches, die die Organisation festlegt, etwa ein Release-Branch, erhalten dieselbe Grundgesamtheit mit v1.4.1, das geplant ist.

Geplant und nicht Teil von v1.4.0. Ein kopierter Fix erhält eine neue Commit-ID, daher geht sein Review nicht automatisch mit. Toevan wird ihn per Inhalt mit git patch-id dem geprüften Original zuordnen und eine Kopie mit geändertem Inhalt als eigenes Review behandeln.

Die Verankerung im öffentlichen Rekor-Transparenz-Log von Sigstore ist eingebaut, als Opt-in je Organisation; veröffentlicht werden nur Eintrags-Hashes. Ein Eintrag zeigt nur, dass ein Eintrag mit einem bestimmten Hash zu einer bestimmten Zeit existierte: keinen Code, keine Dateinamen, keine Befunde. Enterprise-Organisationen können auch in ihrem eigenen Rekor verankern.

Er bedeutet nicht, dass der Kunde das Framework einhält, und Toevan äußert keine Meinung dazu, ob Controls angemessen gestaltet sind oder wirksam arbeiten. Zugriffsprüfungen, Laufzeitüberwachung, Incident Response, Drittparteirisiko, physische Sicherheit und Änderungen außerhalb der Versionskontrolle brauchen Ihre üblichen Verfahren. Jeder Bericht listet sie auf.

Heute GitHub. GitLab und Bitbucket stehen auf der Roadmap. Änderungen außerhalb der Versionskontrolle, etwa direkt in Datenbank oder Konsole, liegen außerhalb der Nachweise.

In Toevans Append-only-Speicher mit einer Aufbewahrung von mindestens drei Jahren und als Kopie auf einem Branch im eigenen Repository des Kunden. Berichte lassen sich als PDF und CSV je Framework, Zeitraum und Repository exportieren.

Die Kopie im Repository des Kunden bleibt, wo sie ist. Die Kette lässt sich mit dem Befehl toevan nachspielen, und ab v1.4.0 lässt sich jeder signierte Eintrag zudem allein mit openssl gegen den veröffentlichten Schlüssel prüfen, mit den Befehlen auf dem Evidence-Branch. Die Prüfung vergangener Einträge hängt nicht davon ab, dass Toevan den Dienst weiter betreibt.