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

Das 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

Das 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

Das 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

SBOM-Unterzeichnung: Lösung eines sich ständig ändernden Rätsels

In den letzten Jahren wurde viel über die SBOM – Software Bill Of Materials – geschrieben. Bei all dieser Offenlegung haben die Leute das Gefühl, dass sie gut genug wissen, was es zu erklären gilt – es handelt sich um eine Liste von Softwarebestandteilen, es ist wichtig für Transparenz und Sicherheit und es hilft dabei, vorübergehende Abhängigkeiten aufzudecken. Alle […]

Bewerten Sie Ihren Sicherheitsstatus für die Quellcodeverwaltung mit GitGat

GitGat ist eine Reihe eigenständiger OPA-Richtlinien (Open Policy Agent), die in Rego geschrieben sind. GitGat wertet die Sicherheitseinstellungen Ihres SCM-Kontos aus und liefert Ihnen einen Statusbericht und umsetzbare Empfehlungen.

Was hat sich im Cybersecurity Framework 2.0 des NIST geändert und warum sollte Sie das interessieren?

Anfang August veröffentlichte das US-amerikanische National Institute of Standards and Technology (NIST) einen Entwurf 2.0 seines wegweisenden Cybersecurity Framework, das erstmals 2014 veröffentlicht wurde. In den letzten 10 Jahren hat sich viel verändert, nicht zuletzt das steigende Niveau Cybersicherheitsbedrohungen, die im Originaldokument dargelegt wurden, um kritischen […]