SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 8: SBOMs im Softwareentwicklungsprozess

Wie könnten in der SBOM-Welt mögliche Software-Entwicklungsprozesse aussehen? Wo würde ich welches Werkzeug verwenden? Was würde dies für meine CI-Pipeline bedeuten? Und wie wirkt sich das Ganze jeweils z. B. auf Rollen aus wie

Software-Produzierende,
Software-Betreibende,
Software-Nutzende,
Software-Verkaufende
oder Beauftragende des Softwareprodukts

Du bist neu dabei? Hier kannst du einen Blick in die ersten sieben Teile der Blogserie werfen:

SBOM-Prozesse für Software-Produzierende

Hier gehen wir von der Prämisse aus, dass Software-Produzierende bei der Softwareentwicklung grundsätzlich eine CI-Pipeline “Build” durchlaufen, die immer dann ausgeführt wird, wenn sich etwas am Softwarestand ändert. Typische Elemente einer solchen Pipeline sind

der eigentliche Build,
die Ausführung von Tests,
eine Reihe weiterer Prüfungen wie z. B. eine statische Code-Analyse.
Die Pipeline endet in der Regel mit dem Erzeugen eines Deployment-Artefakts
und der Installation auf einer Testumgebung.

Variante 1

In der SBOM-Welt würden nun weitere Schritte hinzukommen:

Das Ergebnis dieses zusätzlichen Schritte wäre

entweder ein Abbruch der Pipeline, wenn es zu Fehlern kommt (z. B. bei neuen CVEs oder problematischen Lizenzen)
oder im positiven Fall hätten wir neben dem eigentlichen Produkt nun zusätzlich die SBOM als Build-Ergebnis. In der Regel werden diese Ergebnisse in einem lokalen Repository des Unternehmens gespeichert.
Zusätzlich könnte an dieser Stelle die SBOM z. B. auch in ein zentrales System wie Dependency Track eingespielt werden, um so eine projekt- und versionsübergreifende Abfrage und Auswertung zu ermöglichen.

Als Werkzeuge kommen diejenigen in Frage, die in der Lage sind, SBOMs auf Basis der vorliegenden Software-Artefakte zu erstellen (siehe Teil 5).

Pipeline „Release“

In einer weiteren Pipeline „Release“ folgen weitere mögliche Schritte. Diese Pipeline wird aufgerufen, sobald es eine offizielle neue Version gibt. Das kommt bei Continuous-Delivery-Ansätzen durchaus häufig vor und kann im Anschluss an die Build Pipeline erfolgen:

Wie die Abbildung zeigt, werden hier die SBOMs mehrerer Teilprodukte in eine SBOM zusammengeführt. Diese SBOM wird mit der Software paketiert und für die Nutzer der Software bereitgestellt. Hier wäre es u. U. angebracht, die Prüfungen auf CVEs aus dem „Build“ noch einmal durchzuführen. Damit ließe sich ggf. im letzten Moment noch ein Release verhindern. Für das Zusammenführen von SBOM gibt es Werkzeuge wie cyclonedx-cli oder sbommerge.

Prüfen auf CVEs

Ein dritter Prozess ist das regelmäßige Prüfen bestehender, relevanter Stände des Produkts auf neue CVEs. Relevante Stände sind dabei z. B. der aktuelle Entwicklungsstand sowie alle veröffentlichen und noch supporteten Releases.

In diesem Prozess wird erneut auf die SBOMs zugegriffen. Diese werden daraufhin auf der Grundlage einer oder mehrerer Vulnerability-Datenbanken ausgewertet. Im Falle neu entdeckter Vulnerabilities, können diese bzgl. ihrer Kritikalität auf Basis z. B. der CVSS-Scores bewertet werden.

Im Anschluss kommt es zu einem Alerting, dem eine zeitnahe manuelle Detailanalyse folgen muss. Der Zugriff auf den eigentlichen Quelltext ist hierbei nicht mehr notwendig. An dieser Stelle haben wir einen CI-basierenden Ansatz skizziert. Grundsätzlich wäre aber auch ein Vorgehen auf Basis z. B. von Dependency Track denkbar, dass obige Schritte selbstständig intern außerhalb eienr CI-Pipeline ausführt. Dies ist auch die Stunde von Vulnerability Scannern wie Grype oder Trivy.

SBOM-Prozesse für weitere Rollen

Wie sehen die Prozesse mit integrierter SBOM-Erzeugung für die anderen Rollen aus? Grundsätzlich kann man sagen: Immer sehr ähnlich. Deshalb beschränken wir uns hier auf eine kurze Zusammenfassung:

Prozess 1: SBOM entgegennehmen und speichern

Die von den Software-Produzierenden gelieferte SBOM ist entgegenzunehmen und mit den SBOMs der anderen Softwareprodukte zentral zu speichern. Relevant an dieser Stelle ist, dass die SBOMs gepflegt werden. So sollten SBOMs zu alten Softwareständen, die nicht mehr eingesetzt werden, zum Beispiel gelöscht werden.

Prozess 2: Regelmäßige Prüfung auf CVEs

In einem zweiten Schritt werden diese SBOMs regelmäßig auf neue CVEs geprüft. Das Vorgehen ist hier analog wie beim Software-Produzenten:

Schritte nach dem Alerting

Nach dem Alerting sehen die Prozessschritte für jede Rolle etwas anders aus:

Software-Betreibende würden im Rahmen der Analyse unabhängig vom Hersteller ggf. nach einer möglichen Mitigation recherchieren, um so das Risiko zu minimieren und die definierten Service-Level zu halten.
Software-Nutzende würden vermutlich auf den Hersteller zugehen.
Personen, die Software verkaufen, würden ihre Kunden entsprechend informieren,
während diejenigen, die die Umsetzung beauftragen, sich eng mit den Software-Produzierenden abstimmen und den Fokus mehr auf das resultierende Projekt- und Risko-Management setzen.

Fazit

Beim Einsatz von SBOMs beobachten wir im Gesamtprozess vor allem drei Vorteile:

Keine Rolle muss auf andere Rollen warten.
Die einzelnen Schritte sind transparent, sodass alle Beteiligten die Risiken sehr gut abschätzen können.
Die Zeit bis zur maßgeblichen Reaktion kann sich erheblich reduzieren.