Was Sie tun müssen, um SLSA-Level zu erreichen – ein sehr praktischer Leitfaden

Hintergrund

SLSA (Supply-Chain Levels for Software Artifacts) ist ein Sicherheitsrahmenwerk, das darauf abzielt, Manipulationen zu verhindern, die Integrität zu verbessern und Pakete und Infrastruktur zu sichern. Das Kernkonzept von SLSA besteht darin, dass einem Softwareartefakt nur dann vertraut werden kann, wenn es drei Anforderungen erfüllt:

1. Das Artefakt sollte über ein Provenienzdokument verfügen, das seine Herkunft und seinen Herstellungsprozess beschreibt (L1).
2. Das Provenienzdokument sollte vertrauenswürdig sein und nachgelagert verifiziert werden (L2).
3. Das Build-System sollte vertrauenswürdig sein (L3).

Das SLSA-Framework definiert Stufen, die darstellen, wie sicher die Software-Lieferkette ist. Diese Stufen entsprechen dem Grad der Umsetzung dieser Anforderungen (oben als L1-L3 bezeichnet).

Schreiber valint slsa Mit dem Befehl können Provenienzdokumente erstellt werden. Im Folgenden beschreiben wir, wie Sie mit diesem Tool SLSA-Level erreichen.

Hinweis: Wir beziehen uns hier auf das SLSA V1.0-Framework.

SLSA L1

Die Anforderungen für SLSA L1 umfassen:

• Softwarehersteller folgen einem konsistenten Build-Prozess.
• Die Build-Plattform generiert automatisch Herkunftsdaten, die beschreiben, wie das Artefakt erstellt wurde.
• Softwarehersteller verteilen Herkunftsdaten an Verbraucher.

Checkliste zum Erreichen von SLSA L1:

• Erstellen Sie Ihre Software mit einem CI-System. Verwenden Sie vorzugsweise ein Build-Skript, das quellgesteuert ist.
• aktivieren Sie die valint slsa Befehl als Teil Ihres Build-Skripts, um ein Provenienzdokument zu erstellen. Beachten Sie, dass die valint slsa  Mit dem Befehl können Sie dem Provenienzdokument zusätzliche Informationen hinzufügen – Sie können den Inhalt des Provenienzdokuments an Ihre Bedürfnisse anpassen.

SLSA L2

Die Anforderungen für SLSA L2 umfassen:

• Die SLSA L1-Anforderungen.
• Der Build läuft auf einer gehosteten Build-Plattform, die die Herkunft selbst generiert und signiert.
• Die nachgelagerte Überprüfung der Herkunft umfasst die Validierung der Authentizität der Herkunft.

Checkliste zum Erreichen von SLSA L2:

• Die SLSA L1-Checkliste.
• Verwenden Sie einen gehosteten Build-Dienst (anstatt den Build auf dem Entwicklercomputer auszuführen).
• Erstellen Sie ein signiertes Provenienzdokument (anstelle eines nicht signierten, was für SLSA L1 ausreicht). Dies kann durch Ausführen erreicht werden valint slsa ... -o attest. Schreiber valint Das Tool verfügt über zahlreiche Signierfunktionen. Für ein Unternehmen empfehlen wir die Verwendung von X.509-PKI-Schlüsseln und -Zertifikaten. 
• Überprüfen Sie die Echtheit des Provenienzdokuments nachgelagert mit dem valint verifyBefehl. Die Verifizierung kann eine Unterschrift und die unterzeichnende Identität sowie andere Verifizierungsregeln umfassen, die den Inhalt des SLSA-Provenienzdokuments sicherstellen. Einige Beispiele finden Sie bei Scribe's Richtlinienkatalog.

Hinweis: Die Überprüfung sollte durch den Verbraucher der erstellten Software erfolgen; Für die interne Compliance kann die Verifizierung als Teil einer Testpipeline erfolgen.

SLSA L3

SLSA L3-Anforderungen

Die Anforderungen für SLSA L3 umfassen:

• Die SLSA L2-Anforderungen.
• Die Build-Plattform implementiert strenge Kontrollen, um:
  • Verhindern Sie, dass sich Läufe gegenseitig beeinflussen, auch innerhalb desselben Projekts.
  • Verhindern Sie, dass Geheimnisse, die zum Signieren der Herkunft verwendet werden, über die benutzerdefinierten Build-Schritte zugänglich sind.

Um der Build-Plattform zu vertrauen, muss man außerdem vertrauen Überprüfen Sie die Build-Plattform. Der Build-Plattform sollte im Sinne des Provenienzdokuments vertraut werden unfälschbar und der Build wird sein isoliert. Aus einer solchen Überprüfung ergeben sich folgende Anforderungen:

• Überprüfen Sie, dass Die Nutzung der Plattform bricht nicht ab die Unfälschbarkeit und Isolation Anforderungen.
  • Die Überprüfung der Isolation kann beispielsweise durch die Auswertung der Cache-Nutzung in der Pipeline erfolgen.
  • Um die Fälschbarkeit des Provenienzdokuments sicherzustellen, empfehlen wir, es in einer dedizierten Build-Pipeline zu generieren und zu signieren.
• Überprüfen Sie die Vertrauenswürdigkeit der Build-Plattform.
  •  Bei SaaS-CIs sollte eine Überprüfung beim Anbieter der Build-Plattform erfolgen. In Fällen, in denen der Softwarehersteller für die Bereitstellung des Build-Systems verantwortlich ist, wird eine Kombination aus Selbstbescheinigung des Anbieters und der Durchführung einer Analyse der Bereitstellungsaspekte empfohlen.
  • Wenn Sie beispielsweise ein selbstgehostetes CI bereitstellen, sollte die Herstellerbescheinigung angeben, wie Builds voneinander isoliert sind, und die Bereitstellungsanalyse sollte die Zugriffsberechtigungen und die Protokollüberwachung des CI-Systems überprüfen.

Diese Anforderungen stellen eine Herausforderung dar, da ihre Erfüllung CI-plattformabhängig ist, nicht vollständig automatisiert werden kann und eine professionelle Sicherheitsanalyse der Build-Systeme und Pipelines erfordert. Aus diesem Grund schlägt das SLSA-Framework ausdrücklich vor, dass Organisationen schrittweise von der SLSA L2- zur SLSA L3-Compliance übergehen.

Wenn Sie diesen Artikel bis hierher gelesen haben und zu dem Schluss gekommen sind, dass SLSA L3 das Richtige für Sie ist, krempeln Sie die Ärmel hoch – hier ist unsere Empfehlung für eine Checkliste:

Checkliste zum Erreichen von SLSA L3:

• Die SLSA L2-Checkliste.
• Bewerten Sie das CI-System. Ziel ist die Beantwortung folgender Fragen:
  • Unter welchen Bedingungen kann eine nicht autorisierte Entität das Build-System umgehen?
  • Unter welchen Bedingungen können sich Builds gegenseitig beeinflussen?

Sobald die Antwort beantwortet ist, verwalten Sie die verbleibenden Risiken.

• Isolieren Sie die Generierung des Provenienzdokuments:
  • Verteilen Sie die Erstellung des Provenienzdokuments auf eine andere Pipeline, vorzugsweise auf einen separaten Build-Service.
    • Geben Sie dieser Pipeline nur die Geheimnisse preis, die zum Signieren des Provenienzdokuments verwendet werden.
    • Erstellen oder überprüfen Sie den Inhalt des Provenienzdokuments in dieser Pipeline. Im Falle einer Verifizierung überprüfen Sie alle möglichen Felder eines in der Pipeline generierten Provenienzdokuments mit Daten, die direkt von der Build-Plattform oder von anderen vertrauenswürdigen Quellen erfasst wurden.
• Isolieren und überprüfen Sie die Isolation der Build-Pipeline von anderen Pipeline-Ausführungen:
  • Überprüfen Sie die Verwendung von Caches und freigegebenen Volumes.
  • Stellen Sie sicher, dass mit anderen Pipelines geteilte Geheimnisse nicht dazu führen können, dass sich Pipelines gegenseitig beeinflussen.
  • Stellen Sie sicher, dass Pipeline-Ausführungen sich nicht gegenseitig beeinflussen können
    • Verhindern Sie beispielsweise, dass Installationen, die über eine Pipeline durchgeführt werden, Auswirkungen auf andere Pipelineläufe haben. Dies kann durch die Verwendung kurzlebiger Build-Runner (z. B. einen Container, der für jeden Build erstellt wird) oder durch die Überprüfung erfolgen, dass Build-Runner jedes Mal von einem vorgegebenen Status aus starten.

Um SLSA L3 mit Scribe-Tools zu erreichen, empfehlen wir Folgendes:

• Instrumentieren Sie die Build-Pipeline zum Generieren aller Bescheinigungen, die zum Auffüllen des Provenienzdokuments erforderlich sind. Sie können beispielsweise entscheiden, dass Sie eine Liste der während des Builds installierten Abhängigkeiten wünschen. Diese Liste kann von a generiert werden valint bom dir:Befehl. Erstellen Sie außerdem eine Provenienzbescheinigung in der Pipeline mithilfe von valint slsa Befehl.
• Erstellen Sie eine separate Pipeline zur Generierung vertrauenswürdiger Herkunft, die Folgendes ausführt:
  • Generieren Sie ein vertrauenswürdiges Provenienzdokument basierend auf dem in der Build-Pipeline erstellten Dokument.
    • Sammeln Sie Daten vom Build-Service und verwenden Sie diese zur Überprüfung und Aktualisierung des Provenienzdokuments.
    • Überprüfen Sie den Inhalt der in der Build-Pipeline erstellten Attestierungen. Überprüfen Sie beispielsweise den Inhalt des Build-Runners, indem Sie einen SBOM-Nachweis aus der Build-Pipeline mit einem SBOM-Nachweis vergleichen, der separat abgetastet wurde.
    • Verwenden Sie die aus der Build-Pipeline gesammelten Atteste, um das Provenienzdokument zu aktualisieren.
    • Die Aktualisierung des Provenienzdokuments kann mit erfolgen valint slsa Befehl.
  • Stellen Sie sicher, dass der Build isoliert wurde, indem Sie die vom Build-Service gesammelten Daten auswerten. Überprüfen Sie beispielsweise die Verwendung von Caches und Geheimnissen.

Um eine solche Datenerfassung und -auswertung durchzuführen, stellt Scribe Tools zur Verfügung, die Attestierungen zum Build-Lauf erstellen und die erforderlichen Überprüfungen durchführen.

---

In Ordnung. Es scheint, dass Sie bereit sind, loszulegen. Wenn Sie Hilfe benötigen, wenden Sie sich natürlich an uns. lassen Sie es uns wissen. Wir sind für Sie da und beraten Sie gerne oder helfen aktiv.

Zusammenhängende Artikel

ML-Was? Das ML-Bom-Konzept und seine Verwendung verstehen

Die Branche hat die Idee einer SBOM noch nicht vollständig verstanden, und wir hören bereits einen neuen Begriff – ML-BOM – Machine Learning Bill of Material. Bevor Panik ausbricht, wollen wir verstehen, warum eine solche Stückliste erstellt werden sollte, welche Herausforderungen bei der Generierung einer ML-Stückliste bestehen und wie eine solche ML-Stückliste aussehen kann. […]

Wie sicher sind Sie mit dem, was wirklich in Ihrer CI/CD-Pipeline passiert? Die Elemente, die Sie sichern sollten, und wie

CI/CD-Pipelines sind bekanntermaßen undurchsichtig, was genau darin geschieht. Selbst wenn Sie derjenige sind, der die YAML-Konfigurationsdatei (die Pipeline-Anweisungsliste) geschrieben hat, wie können Sie dann sicher sein, dass alles genau wie beschrieben abläuft? Schlimmer noch, die meisten Pipelines sind völlig vergänglich, sodass selbst wenn etwas Schlimmes passiert, keine […]

Umgang mit den SBOM-Richtlinien der NSA: Wichtige Schritte für eine effektive Sicherheit der Software-Lieferkette

In der heutigen digitalen Landschaft ist Softwaresicherheit von größter Bedeutung. Die National Security Agency (NSA) hat in Zusammenarbeit mit der Cybersecurity and Infrastructure Security Agency (CISA) umfassende Richtlinien für das Software Bill of Materials (SBOM)-Management erstellt. Diese Richtlinien sind für Organisationen von entscheidender Bedeutung, die ihre Cybersicherheitslage stärken und Risiken in ihrer Software-Lieferkette mindern möchten. Warum […]