Ihre SBOM auf Google Cloud absichern

Seit einigen Jahren steht die Sicherheit der Software-Supply-Chain bei Regierungen und Unternehmen gleichermaßen im Fokus. Nach Log4Shell Ende 2021 rückte die National Cybersecurity Strategy der Biden-Regierung die Sicherheit der Open-Source-Supply-Chain in den Mittelpunkt. 

Die National Security Agency (NSA) hat kürzlich neue Leitlinien veröffentlicht, um Open-Source-Software-Supply-Chains abzusichern. Das neue Dokument enthält Empfehlungen zum Umgang mit Open-Source-Software (OSS) und zur Pflege einer Software-Stückliste (SBOM). 

Die Sicherheit der Software-Supply-Chain wird aus gutem Grund immer wichtiger. Die Anzahl der Softwarepakete, die von Supply-Chain-Angriffen betroffen waren, stieg von rund 700 im Jahr 2019 auf mehr als 185.000 im Jahr 2022. 

Während Entwicklungsteams überlegen, wie sie auf die neuen Leitlinien der NSA reagieren sollen – insbesondere in Cloud-Umgebungen wie Google Cloud –, müssen sie Partner finden, die sie auf diesem Weg unterstützen und diese Best Practices in ein iteratives DevSecOps-Modell integrieren.  

Die Empfehlungen der NSA im Überblick 

Das neue Empfehlungspapier mit dem Titel Securing the Software Supply Chain: Recommended Practices for Managing Open Source Software and Software Bill of Materials behandelt vier zentrale Sicherheitsthemen:

1. Verwaltung von Open-Source-Software

2. Erstellen und Pflegen sicherer Open-Source-Repositories

3. Wartung von Open-Source-Software und Krisenmanagement

4. Erstellung und Validierung von SBOMs

Sehen wir uns einige der Empfehlungen für Entwicklerinnen und Entwickler an, die in diesem Dokument aufgeführt sind. 

Verwaltung von Open-Source-Software

Laut diesem Dokument tragen Entwicklerinnen und Entwickler den größten Teil der Verantwortung für die Verwaltung von Open-Source-Software. Sie müssen die passenden OSS-Optionen auswählen, Lizenz- und Schwachstellenprobleme prüfen, die Software in ihren Entwicklungslebenszyklus integrieren und eine SBOM erstellen.

Für den Einsatz von Open-Source-Software im Entwicklungsprozess empfiehlt die NSA mehrere Vorgehensweisen, darunter:

• Auswahl: OSS sorgfältig bewerten, um die sichersten Optionen auszuwählen

• Risikobewertung: Alle Risiken der jeweiligen ausgewählten OSS vollständig verstehen

• Lizenzierung: Die durch die jeweiligen Lizenzen vorgegebenen Verpflichtungen und Einschränkungen einhalten

• Exportkontrolle: Die geltenden Exportbestimmungen einhalten

• Wartung: Ein internes, sicheres Repository pflegen

• Umgang mit Schwachstellen: Einen festgelegten Prozess einrichten, um neue Schwachstellen zu finden und zu beheben

• Sichere Softwarebereitstellung: Vor der Auslieferung den Inhalt des fertigen Produkts mithilfe einer binären Kompositionsanalyse nochmals überprüfen  

Erstellen und Pflegen sicherer Open-Source-Repositories

Die NSA widmet in ihrer aktuellen Veröffentlichung einen Abschnitt Empfehlungen für die Einrichtung eines internen, sicheren Repositorys.

Die beiden Empfehlungen zur Pflege dieses Repositorys lauten:

• Einen Prozess zur Einführung von OSS etablieren, der zur Größe und den verfügbaren Ressourcen Ihrer Organisation passt.

• Vor und nach der Einführung Schwachstellen- und Risikobewertungen durchführen und anhand der Ergebnisse entscheiden, welche Komponenten verwendet und welche zurückgesetzt oder auf sicherere Versionen aktualisiert werden müssen. 

Wartung von Open-Source-Software und Krisenmanagement

Open-Source-Software, die zuvor als sicher eingestuft und für ein internes Repository freigegeben wurde, kann weiterhin Zero-Day-Schwachstellen aufweisen. Unternehmen sollten auch überlegen, wie sie diese neuen Risiken in der ausgewählten OSS finden und beheben können. 

Unternehmen können mit den folgenden empfohlenen Vorgehensweisen einen Notfallplan zum Finden und Beheben neuer Open-Source-Schwachstellen und -Bedrohungen erstellen:

• Zuverlässige Informationen nutzen, um aufkommende Bedrohungen zu erkennen. 

• Eine SBOM verwenden, um anfällige Komponenten in Bibliotheken zu finden.

• Einem Prozess zur Behebung von Schwachstellen folgen, zum Beispiel die Komponente auf eine korrigierte Version aktualisieren oder auf eine nicht betroffene Version zurücksetzen.

• Einen Krisenmanagementplan vorbereiten, um auf schwerwiegende Softwareprobleme zu reagieren und Stakeholder zeitnah zu informieren.

Erstellung und Validierung von SBOMs

Das Dokument unterstreicht auch die Bedeutung von SBOMs – sie zu erstellen, zu aktualisieren und den richtigen Personen und Tools zugänglich zu machen. 

Die NSA nennt einige Merkmale einer erfolgreichen SBOM:

• Angaben zu Komponenten, Versionen, Lizenzen und Abhängigkeiten

• Integration in die Pipeline mit Sicherheitstechniken wie Software Composition Analysis (SCA)

• Automatisierte Extraktionstools, die das Ermitteln und Aktualisieren von Komponenten im gesamten SDLC erleichtern

• Qualitätssicherung und Validierung, damit die SBOM-Daten das richtige Format haben und Entwicklerinnen und Entwickler sie in Tools und Automatisierungen integrieren können

So setzen Google-Cloud-Nutzerinnen und -Nutzer diese Empfehlungen mit Snyk um

Diese Prozesse klingen vielleicht nach zusätzlichem Aufwand für Ihre Entwicklungsteams – das müssen sie aber nicht sein. Mit dem Open-Source-Sicherheitsmanagement von Snyk können Sie mühelos Schwachstellen in bestehenden Open-Source-Komponenten finden und beheben, Pull Requests vor dem Zusammenführen auf unsichere Komponenten prüfen und angereicherte SBOMs erstellen. Dank Snyk Open Source, unserem SCA-Tool, behoben 99 % der von Log4J betroffenen Snyk-Kunden die Log4Shell-Schwachstelle innerhalb von drei Tagen. Mit der entwicklerorientierten Sicherheitsplattform von Snyk können Sie die Sicherheitsrichtlinien des Bundes einfacher einhalten, indem Sie:

• Schwachstellen in Abhängigkeiten während des Programmierens direkt in Ihrer IDE oder CLI finden.

• Ihre Projekte direkt aus dem Repository vor dem Zusammenführen testen und täglich auf neue Schwachstellen überwachen.

• Einen automatisierten Snyk-Test in Ihre CI/CD-Pipeline integrieren, damit keine neuen Schwachstellen den Build-Prozess durchlaufen.

• Ihre Produktionsumgebung testen, um sicherzustellen, dass sie keinen bestehenden Schwachstellen ausgesetzt ist.

• Für jedes Open-Source-Paket SBOMs mit angereicherten Informationen von Snyk erstellen, darunter Lizenzdetails, externe Links, Informationen zu Maintainerinnen und Maintainer und vieles mehr.

Darüber hinaus arbeitet Snyk mit Google Cloud zusammen, um die Sicherheit von Software-Supply-Chains zu gewährleisten. Dazu integriert sich Snyk in die Google-Dienste, die Sie zum Erstellen und Ausführen Ihrer Apps nutzen, darunter:

• Google CloudBuild. Snyk scannt alle Pakete in Ihren Projekten und bietet automatisierte Empfehlungen zur Behebung. 

• Google Artifact Registry (GAR). Snyk scannt Ihre Container auf Schwachstellen und prüft Ihre Basis-Images.

• Google Kubernetes Engine (GKE). Mit Snyk können Sie laufende Workloads importieren und scannen, um Schwachstellen in Images und Konfigurationen zu identifizieren. 

Dank dieser Integrationen können Teams, die moderne, containerisierte Apps auf Google Cloud entwickeln, ihre SBOMs validieren und ihre Software-Supply-Chain absichern, ohne ihre gewohnten Umgebungen verlassen zu müssen. 

Kunden können außerdem ihre bestehenden Abrechnungsmechanismen bei Google nutzen, um Snyk-Software direkt im Google Cloud Marketplace zu erwerben. 

Erfahren Sie, wie Snyk dem Team von Kroger bei der Absicherung seiner Supply-Chain geholfen hat.