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
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 🔑
Der –valint.sign Die Flagge fungiert als einfacher Umschalter:
- Auslassen –valint.sign für SLSA Level 1 (Unsigned): Scribe generiert grundlegende, nicht signierte Herkunftsangaben für die grundlegende Rückverfolgbarkeit.
- Umfassen –valint.sign für SLSA Level 2 (signiert): 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 Plattformen entdecken Befehl:
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,
Mit unserem Service verwalten wir den Lebenszyklus des Rahmens und der Nachweise, um einen klaren Überblick über Ihre Produkte und Vermögenswerte zu bieten.
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.
Ähnliche Artikel
