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. Seit 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; weitere Eintragsarten tragen ihre eigenen Prädikate. 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, seit v1.4.0 bei jedem Merge eines Pull Requests in den Standard-Branch, 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 aus den Deployment- und Release-Einträgen von GitHub und sind per Commit oder Digest verknüpft; prüfen Sie den Originaleintrag in GitHub. 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. Die Berichte und der Evidence-Branch drucken 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 und noch nicht öffentlich, 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. Sie können 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 Gate-Urteile lassen sich auch in die Kosli-Trails des Kunden übertragen.

Der Änderungsnachweis-Bericht listet 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, was geplant ist.

Geplant. 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, mindestens drei Jahre aufbewahrt (5, 7 oder 10 bei Enterprise), 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. Jeder signierte Eintrag lässt sich mit Standard-openssl gegen den veröffentlichten Schlüssel prüfen, mit den Befehlen auf dem Evidence-Branch, ohne Toevan-Software. Die Prüfung vergangener Einträge hängt nicht davon ab, dass Toevan den Dienst weiter betreibt. Die ganze Kette nachzuspielen braucht den Toevan-Verifier, auf Anfrage bei Toevan erhältlich und noch nicht öffentlich.