Lieferkettenintegrität
Auf einen Blick
Abschnitt betitelt „Auf einen Blick“Die Lieferketten-Kontrollen von NextPDF greifen an zwei Punkten: CI-Gates, die bei jedem abhängigkeitsändernden Pull Request und jedem Versions-Tag laufen, und der Release-Workflow, der Provenance-Erzeugung, Keyless-Signierung und SBOM-Ausgabe konfiguriert.
| Kontrolle | Typ |
|---|---|
SBOM des Builds im Format CycloneDX 1.7 | CI-Gate, hart |
| in-toto-Statement, das die Build-Eingaben festschreibt | CI-Gate, hart |
| SHA-256-Abgleich der Abhängigkeits-Fingerprints gegen eine gepinnte Baseline | CI-Gate, hart |
| OpenVEX-Konsistenzprüfung gegen die Abhängigkeits-Advisory-Richtlinie | CI-Gate, hart |
| Fixture-übergreifende Determinismusprüfung | CI-Prüfung, Best-Effort |
Gepinnte Provenance-Erzeugung über slsa-github-generator | Workflow-Konfiguration — Release-Workflow |
Keyless-Signierung mit Sigstore cosign und Transparenzprotokollierung in Rekor | Workflow-Konfiguration — Release-Workflow |
SBOM-Ausgabe in CycloneDX 1.7 und SPDX 2.3 | Workflow-Konfiguration — Release-Workflow |
Nächtliche php-fuzzer-Matrix über die Parser- und Writer-Pfade | Zeitgesteuerte CI |
CI-Gates
Abschnitt betitelt „CI-Gates“Jeder Pull Request, der Abhängigkeiten berührt, und jedes Versions-Tag durchläuft:
| Prüfung | Funktion | Gate |
|---|---|---|
| Inventar | Erzeugt ein SBOM des Builds im Format CycloneDX 1.7 | Hart |
| Build-Eingaben-Protokoll | Erzeugt ein in-toto-Statement, das die Build-Eingaben festschreibt | Hart |
| Abhängigkeitsintegrität | Gleicht SHA-256-Byte-Fingerprints gegen eine gepinnte Baseline ab | Hart |
| VEX-Konsistenz | Verlangt, dass jeder Eintrag der Abhängigkeits-Advisory-Richtlinie ein passendes Statement im OpenVEX-Dokument v0.2.0 des Repositorys hat | Hart |
| Reproduzierbarkeit | Führt eine Determinismusprüfung über die Fixtures aus | Best-Effort |
Das Gate zur Abhängigkeitsintegrität gleicht SHA-256-Byte-Fingerprints des Abhängigkeitsbaums gegen eine im Repository gepinnte Baseline ab, unabhängig von Paket-Metadaten.
Konfiguration des Release-Workflows
Abschnitt betitelt „Konfiguration des Release-Workflows“Provenance — Workflow-Konfiguration
Abschnitt betitelt „Provenance — Workflow-Konfiguration“Der Release-Workflow pinnt den kanonischen wiederverwendbaren Workflow
slsa-github-generator, der so konfiguriert ist, dass er in-toto-Provenance
in einem isolierten, kurzlebigen Builder erzeugt, und konfiguriert
slsa-verifier für die Inline-Prüfung der Generator-Ausgabe.
Signierung und Transparenz — Workflow-Konfiguration
Abschnitt betitelt „Signierung und Transparenz — Workflow-Konfiguration“Der Release-Workflow konfiguriert Keyless-Signierung mit Sigstore cosign
für das Artefakt-Bundle, mit Transparenzprotokollierung in Rekor. Bei der
Keyless-Signierung wird ein kurzlebiges Zertifikat aus der OIDC-Identität des
Workflows (https://token.actions.githubusercontent.com) abgeleitet; dieser
Release-Signierpfad ist damit ohne langlebigen Artefakt-Signierschlüssel
konfiguriert.
SBOM — Workflow-Konfiguration
Abschnitt betitelt „SBOM — Workflow-Konfiguration“Der Release-Workflow konfiguriert die Ausgabe zweier SBOMs — ein Dokument im
Format CycloneDX 1.7 und ein Dokument im Format SPDX 2.3.
Fuzzing
Abschnitt betitelt „Fuzzing“Eine nächtliche php-fuzzer-Matrix testet zusammen mit einem
AST-/Strukturbaum-Harness die Parser- und Writer-Pfade.