Dieser Artikel wurde gemeinsam mit Viktor Kartashov und Daniel Nebenzahl verfasst.
Der Lackmustest des Prüfers: Können Sie Ihre Builds beweisen?
„Können Sie definitiv beweisen, dass jedes von Ihnen versendete Container-Image genau so erstellt wurde, wie Sie es behaupten?“
Die meisten Prüfer erwarten eine schnelle und zuverlässige Antwort – und nicht wochenlanges, hektisches YAML-Refactoring. Das SLSA-Framework (Supply-chain Levels for Software Artifacts) bietet die Grundlage für diesen Nachweis: eine strukturierte, manipulationssichere Herkunft.
Aber hier liegt das Problem: Traditionell entwickelt sich die Einbindung eines Herkunftsgenerators in jeden CI-Workflow schnell zu einem Maulwurfspiel:
- Dutzende von Repositories? Das bedeutet, dass unzählige PRs überprüft und zusammengeführt werden müssen.
- Pipeline-Änderungen? Ständige, manuelle Wartung.
- Historische Bauten? Es gibt keine einfache Möglichkeit, Beweise für frühere Veröffentlichungen wiederherzustellen.
Scribe Security beseitigt diese Reibung mit SLSA on Scale. Angetrieben durch unsere höhere Ebene Plattformen-CLI, es sammelt auf intelligente Weise Ihre vorhandenen CI-Protokolle, erkennt automatisch jeden Image-Build und gibt eine umfassende vollständige Herkunft aus (unsigniert für SLSA Level 1 oder signiert für SLSA Level 2) – alles mit einem einzigen Befehl, der keine vorherige Einrichtung erfordert.
Plattformen CLI: Der No-Touch-Paradigmenwechsel in der Herkunftssicherung
Traditioneller Ansatz | Scribe-Plattformen-CLI |
Betten Sie in jeden CI-Job einen Generatorschritt ein | Keine Pipeline-Bearbeitungen — analysiert Protokolle nachdem der Build abgeschlossen ist |
Schwierige Auffüllung alter Gebäude | Erstellt rückwirkend eine Herkunft aus vergangenen Workflow-Läufen |
Linearer Aufwand pro Repo | Ein Befehl skaliert auf 10 → 1,000+ Repositories |
Wie die Magie entsteht: Vertrauen automatisieren
Die CLI von Scribe Platforms führt im Hintergrund einen raffinierten Tanz auf, um eine automatisierte SLSA-Herkunft bereitzustellen, und das alles, ohne Ihre vorhandenen Builds zu beeinträchtigen:
- Es erntet Protokolle: Scribe stellt eine Verbindung zu Ihrem CI/CD-System her (derzeit GitHub Actions, Unterstützung für GitLab und Jenkins folgt in Kürze), um Build-Protokolle abzurufen.
- Es erkennt jeden Build: Ohne spezielle Einrichtung in Ihren Pipelines identifiziert Scribe intelligent Docker-, Podman- oder Buildah-Befehle, um jede Image-Erstellung genau zu bestimmen.
- Es extrahiert wichtige Metadaten: Kritische Details wie Bild-Tags, kryptografische Digests, Runner-IDs, Build-Argumente und Zeitstempel werden direkt aus diesen Protokollen abgerufen.
- Es generiert verknüpfte SBOMs: Für eine vollständige Rückverfolgbarkeit erstellt Scribe automatisch beide Quelle Software-Stücklisten (SBOMs) und Image SBOMs, die sie direkt mit der Build-Herkunft verknüpfen.
- It Crafts SLSA Provenienz: Mit diesen umfangreichen Daten erstellt Scribe dann für jedes Bild eine vollständig konforme SLSA-Herkunftserklärung.
- Es signiert (optional) für Level 2: Durch einfaches Hinzufügen eines Flags integriert sich Scribe in Ihre Signaturfunktion (X509, Pub-Priv, Sigstore oder Ihr bevorzugtes KMS), um die Herkunft kryptografisch zu signieren und sie auf SLSA-Level 2 anzuheben.
- Es validiert und meldet: Entscheidend ist, dass Scribe automatisch vordefinierte SLSA.l1 or SLSA.l2 Initiativen anhand der Beweise. Dadurch wird die Integrität bestätigt und ein umfassender SARIF-Bericht erstellt, der auch für die Einhaltung der Stufe 2 unterzeichnet wird.
Alle generierten Artefakte können lokal verbleiben oder zur langfristigen, manipulationssicheren Speicherung sicher auf Scribe Hub hochgeladen werden.
Über die Generierung hinaus: Compliance-Nachweis mit Policy-as-Code
Die Generierung der Herkunft ist grundlegend, doch der Nachweis ihrer Konformität ist das, was Prüfer wirklich zufriedenstellt. Unmittelbar nachdem Scribe die SLSA-Herkunft generiert hat, führt es automatisch Initiativen auf Grundlage dieses Nachweises aus.
Diese Initiativen fungieren als automatisierte Prüfer und überprüfen beispielsweise:
- Ist die Herkunft wohlgeformt und vollständig?
- Sind alle erforderlichen Felder vorhanden und korrekt?
- Sind die verknüpften SBOMs gültig und zugänglich?
- Wurde die Herkunft von den erwarteten Identitäten kryptografisch signiert?
Das Ergebnis? Ein umfassender SARIF-Bericht mit detaillierten Angaben zu Ihrem Compliance-Status. Für Stufe 2 wird dieser Bericht selbst ebenfalls unterzeichnet und bietet jedem Prüfer eine glasklare, maschinenlesbare und überprüfbare Antwort.
Ein kurzes Beispiel: Erreichen der SLSA-Herkunft mit Scribe-Security 🚀
Die Platforms CLI von Scribe-Security optimiert die Generierung der SLSA-Herkunft für Ihre Builds und bietet einen einheitlichen Befehl, um sowohl Level 1 (unsigniert) als auch Level 2 (signiert) zu gewährleisten. Das entscheidende Unterscheidungsmerkmal ist das Argument –valint.sign.
Um die SLSA-Herkunft für alle tagbasierten Builds in Ihrem Scribe-Security/Valint-Repository auf GitHub zu erhalten, führen Sie den folgenden Befehl aus:
Bash
Plattformen entdecken \ --valint.sign \ # Für SLSA Level 2 (signiert) einschließen, für SLSA Level 1 (unsigniert) weglassen github \ --token EXAMPLE_GH_TOKEN \ --scope.organization example-org \ --scope.repository example-repo \ --repository.mapping *::example_slsa::v1 \ --commit.skip \ --slsa-enable \ --slsa.tags-only
Dann tritt Scribe in Aktion: Es scannt aktuelle GitHub-Workflows, erkennt auf intelligente Weise Ihre Image-Builds, sammelt alle erforderlichen Daten und schreibt eine umfassende SLSA-Herkunft mit verknüpften SBOMs.
--valint.sign: Ihr Schalter für SLSA Level 1 oder 2 🔑 Das Flag --valint.sign fungiert als einfacher Umschalter: --valint.sign für SLSA Level 1 (Unsigniert) weglassen: Scribe generiert eine grundlegende, unsignierte Herkunft für die grundlegende Rückverfolgbarkeit. --valint.sign für SLSA Level 2 (Signiert) einschließen: Scribe signiert Herkunftsdateien und den SARIF-Konformitätsbericht kryptografisch und bietet so ein höheres Maß an überprüfbarer Sicherheit.
Dieser einheitliche Befehl, der über ein einzelnes Flag gesteuert wird, vereinfacht das Erreichen einer robusten SLSA-Konformität im großen Maßstab, ohne Ihre vorhandenen CI/CD-Pipelines zu ändern.
Open-Source-SLSA-Provenienzgenerierung
Die Generierung von SLSA-Provenienzen ist nicht auf private Repositorien beschränkt. Viele Open-Source-Projekte haben öffentliche CI/CD-Protokolle, wodurch es möglich wird, die Herkunft ihrer Builds zu generieren. Während diese Herkunftsdatensätze zunächst weniger umfangreiche Informationen enthalten (wie Repository- und Organisationsgeheimnisse), werden zukünftige Verbesserungen, möglicherweise durch die Quelle SBOM, könnte dies beheben.
So können Sie beispielsweise problemlos SLSA Level 1-Herkunftsinformationen für die go-gitea/gitea Projekt mit dem Entdecken Sie die Plattform Befehl:
Plattformen entdecken GitHub \ --token EXAMPLE_GH_TOKEN \ # Jedes Token funktioniert, da das Ziel öffentlich ist --scope.organization go-gitea \ --scope.repository gitea \ --repository.mapping *gitea*::gitea_demo::v1 \ --scope.workflow.past_days 30 \ # Workflows zur Überprüfung innerhalb der letzten 30 Tage festlegen --slsa-enable \ --scope.workflow.name "*release-tag*" \ # Analyse auf Release-Workflows konzentrieren --exclude.types member commit secret \ # Große Datensätze und nicht authentifizierte APIs ausschließen --slsa.tags-only # Analyse auf getaggte Workflow-Läufe konzentrieren
Nach der Ausführung dieses Befehls wird ein Protokoll mit der SLSA-Anforderung und eine Tabelle mit einer Zusammenfassung der erkannten Image-Builds und ihrer zugehörigen Herkunft angezeigt:
Wie Sie sehen, war zum Zeitpunkt des Schreibens die neueste Version von „gitea/gitea“ **v1.24.2**. Die beiden Bilder, für die SLSA-Provenienz und die zugehörigen Nachweise veröffentlicht wurden, sind „gitea/gitea:1.24.2“ und „gitea/gitea:1.24.2-rootless“. Die SLSA-Provenienz kann beispielsweise im Folgenden referenziert werden. Link,
Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.