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:
- Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken
- Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten
- Teil 3: SBOM-Formate im Vergleich – CycloneDX versus SPDX
- Teil 4: Was ist eine gute SBOM – Das Versuchssetting
- Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich
- Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?
- Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks
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.
Wie geht es weiter?
Im nächsten Teil verraten wir euch Tipps und Tricks für den Start in die SBOM-Welt.
Danach erwarten euch noch zwei abschließende Teile:
- Was ist von den Konzepten hinter SBOM zu halten?
- Zusammenfassung der Reihe
Alle Teile ansehen:
Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX
Teil 4: Was ist eine gute SBOM? – Das Versuchssetting
Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks
Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess
1 Kommentar
Pingback: SBOM-Formate im Vergleich - The Cattle Crew Blog