Beispiel eines Änderungsnachweis-Berichts

1Zusammenfassung

Was erfasst wurde

Toevan hat die Merges in den Standard-Branch, die Änderungen an Review-Regeln, die Umgehungen und die direkten Pushes in beiden Repositories so erfasst, wie GitHub sie gemeldet hat, und jeden beim Eintreten versiegelt. Im Zeitraum wurden 146 pull requests gemergt und 2 Commits direkt gepusht. Gemeldet + versiegelt

Punkte zur Beachtung

1. Zwei direkte Pushes auf payments-api/release/v1 am 19. Sep., innerhalb eines Fensters von 29 Minuten, in dem die Review-Pflicht ausgeschaltet war.Prozess
2. Drei Pull Requests wurden ohne Freigabe durch eine andere Person als den Autor gemergt: zwei in ledger-service, bevor dessen Review-Regel existierte, einer per Admin-Umgehung im Fenster vom 19. Sep.Prozess
3. Die Regel secret-detection-high schlägt im Produktionscode fehl (1 Befund), gedeckt durch eine genehmigte Ausnahmegenehmigung bis 20. Dez.Code, Ausnahmegenehmigungen

2Umfang, Herkunft und Control-Zuordnung

Wie jeder Fakt erhoben wurde

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 den Deployment- und Release-Einträgen von GitHub übernommen und per Commit oder Digest verknüpft.

Den Originaleintrag in GitHub prüfen.

Nicht erfasst

Es gab keine verlässliche Quelle. Toevan schließt nichts daraus.

Auf anderem Weg bei der Organisation einholen.

Nachweise und die Controls, auf die sie sich beziehen

Von diesem Bericht nicht abgedeckt

• Zugriffsprüfungen, Eintritts- und AustrittsprozesseOrganisatorisch
• Laufzeitüberwachung, Incident ResponseOrganisatorisch
• IKT-Drittparteirisiko, physische SicherheitOrganisatorisch
• Deployments und Artefakte außerhalb von GitHub und ob ein deploytes Artefakt noch läuftOrganisatorisch
• Merges in andere Branches als den Standard-BranchNicht in dieser Version
• Änderungen außerhalb von GitHub, etwa direkt in Datenbank oder KonsoleOrganisatorisch

3Prozessnachweis

Wie die 146 im Zeitraum gemergten Pull Requests geprüft und gemergt wurden, im Moment jedes Merges aus GitHub erfasst.

Abweichungen: ohne unabhängige Freigabe gemergt

Änderungen an den Controls selbst

Direkte Pushes ohne Pull Request

Control-Änderungen und direkte Pushes werden als Ereignisse erfasst, wenn sie eintreten, daher bleibt keine Lücke zwischen Momentaufnahmen unbemerkt. Personen erscheinen als Digests ihrer GitHub-Konten; die Unabhängigkeit wird aus den Konto-IDs berechnet. Gemeldet + versiegelt

4Code-Nachweis

Was der Code bewirkt, geprüft durch Lesen des Codes selbst auf der exakten gemergten Version. Als fehlschlagend markierte Regeln gelten für Produktionscode; Dokumentation und Test-Fixtures liegen außerhalb des Umfangs (siehe Ausnahmegenehmigungen).

Wie weit die Analyse reichte

Die Abdeckung ist der Anteil der Produktions-Quelldateien des Repositories, die der Code-Index beim indizierten Commit geparst hat. Unter dem Gate wird ein Lauf markiert, nicht als bestanden erfasst. Engine- und Regelsatz-Versionen stehen in jedem Eintrag, sodass sich jedes Ergebnis erneut ausführen lässt. Neu berechnet

5Ausnahmegenehmigungen und Umfangsänderungen

Jede Entscheidung, die änderte, was geprüft wurde, oder eine bekannte Abweichung akzeptierte.

Im Zeitraum ist keine Ausnahmegenehmigung abgelaufen oder widerrufen worden. Antragsteller und Genehmiger sind bei jedem Eintrag verschiedene Konten. Ausnahmegenehmigungen sind Toevan-Einträge, die nicht im Ledger versiegelt sind. Toevan-Eintrag, nicht versiegelt

Im Zeitraum verwendete Regelsatz-Versionen

6Änderungseinträge

Eine Änderung vollständig, so wie der Auditor sie bei der Stichprobe sieht. Alle Einträge stehen im CSV-Export, und jeder signierte Envelope liegt auf dem Evidence-Branch im Repository der Organisation.

Weitere Einträge (Beispiel)

7So prüfen Sie diesen Bericht

Jeder Weg lässt Sie die Nachweise selbst prüfen. Wählen Sie den Weg, der zu Ihrer Rolle passt. Nur der dritte braucht Werkzeuge.

1. In der App der Organisation

   Lesezugriff für Auditoren, kein Repository-Zugriff

   • Die Organisation lädt Sie mit der Auditor-Rolle ein: Lesezugriff auf die Nachweisliste, die Exporte und die Berichte.
   • „Jetzt prüfen“ prüft in der App das gesamte Ledger, die Signaturen und etwaige Belege des Transparenz-Logs erneut.
   • Mehr öffnen Sie nicht: Repositories, Code und Befunde werden verweigert.

2. Der Organisation beim Prüfen zusehen

   Bildschirmfreigabe oder vor Ort

   • Sie wählen die Stichproben während der Sitzung; ein Engineer führt die Prüfungen aus, während Sie zusehen.
   • Prüfung jedes gezogenen Eintrags: Kette, Signatur, unverändert.
   • Konten von Autor und Freigebendem je Stichprobe, auf dem Bildschirm verglichen.

3. Selbst ausführen

   IT-Audit-Spezialisten mit befristetem Lesezugriff

   • Nutzen Sie git und openssl. Für die ganze Kette nutzen Sie den Befehl toevan, den Toevan auf Anfrage bereitstellt und der noch nicht öffentlich ist. Ein Toevan-Konto ist nicht nötig.
   • Prüfen Sie, ob die Branch-Spitzen einer Kopie mit den im Bericht erfassten Spitzen übereinstimmen.
   • Führen Sie die Befehle im Anhang aus und vergleichen Sie mit dem Bericht.

8Geplante ErgänzungenGeplant

Spätere Ebenen der Nachweiskette. Sie sind geplant, und nichts in diesem Bericht hängt von ihnen ab. Jede nennt, wie ihre Fakten erhoben werden.

• Festgelegte Produktions-Branches

  Branches, die die Organisation als Produktion festlegt, etwa ein Release-Branch, jede Festlegung erklärt und mit jeder späteren Änderung versiegelt. Jeder erhält dieselbe Grundgesamtheit wie der Standard-Branch: jeder Commit direkt aus Git aufgelistet und einem Eintrag zugeordnet oder markiert.

  Erklärt + versiegeltNeu berechnet

• Kopierte Fixes per Inhalt zugeordnet

  Ein auf main geprüfter und auf einen Release-Branch kopierter Fix erhält eine neue Commit-ID. Toevan ordnet ihn per Inhalt (git patch-id) dem geprüften Original zu und markiert Kopien mit geändertem Inhalt.

  Neu berechnet

Anhang · Befehle für technische Prüfer

Die Befehle, die ein Engineer für Sie ausführt oder die Sie selbst ausführen.

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