SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 9: Ein Fazit

Was ist nun unser Fazit? „Vielfältig“, wäre hier die kurze, knappe Antwort. Wir versuchen daher unsere Erkenntnisse so zu clustern, dass sie die wahrscheinlich häufigsten Fragen des Lesers beantworten. Sollten noch etwas offen bleiben, schickt uns eure Fragen, schreibt einen Kommentar … wir freuen uns über jedes Feedback!

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

Was halten wir von den Konzepten hinter der SBOM?

Die grundsätzliche Idee hat uns überzeugt. Als technikaffine Menschen lieben wir strukturierte, formal definierte und automatisch erzeug- und bearbeitbare Dateiformate. Diese lassen sich leicht in CI-Builds integrieren und weiterverarbeiten. Es lassen sich einfach entsprechende Blaupausen definieren, die dann mit wenig Aufwand in viele Projekte integriert werden können. Die Hoffnung ist, hier ein wichtiges Thema, das uns in der Praxis einen hohen Mehrwert bringt, ohne viel Aufwand umzusetzen.

Der Mehrwert für die Security in der Softwareentwicklung ist offensichtlich. Gleiches gilt für die Anwendung der Software: Nutzer:innen profitieren von der höheren Transparenz und können eigene Prozesse aufsetzen.

Herausfordernd sind das Tooling und die tatsächliche Bewertbarkeit potenzieller CVEs bei der Softwarenutzung. Über einen CVE zeitnah informiert zu sein, bedeutet noch lange nicht, diesen bewerten oder die richtigen Reaktionen initiieren zu können. Leider besitzt die Basis hierfür, also der CVE selbst,oft nicht die nötige Qualität. Die Analyse eines CVEs bleibt daher weiterhin aufwändig und erfordert ein gewisses Expertenwissen. Wir müssen damit rechnen, dass es bei einer flächigen Einführung, wie zum Beispiel über den Cyber Resilience Act, zu „Einschwingeffekten“ und „Übersprungshandlungen“ kommen wird.

Auch die Auswirkungen eines Cyber Resilience Acts auf die Open Source Community sind schwer zu bewerten. Es ist zu befürchten, dass sich eine breitere Transparenz sowie eine mögliche Haftbarkeit eher negativ auf die Bewertung des Einsatzes von Open-Source-Produkten auswirken wird. Dies macht zwar die wahren Kosten von sicherer Software sichtbarer, jedoch ohne dabei eine offensichtliche Alternative aufzuzeigen.

Nehme ich nun CycloneDX oder SPDX?

In der Praxis und für das Ziel unserer Analyse sind beide Formate gleichwertig und gleichen sich auch bei Unterschieden immer wieder an. In der CycloneDX Welt scheint es mehr Werkzeuge zu geben, was aber nicht sofort bedeutet, dass diese auch besser sind.

Für SPDX spricht wiederum die ISO-Zertifizierung, die Unternehmen mehr Sicherheit geben kann. So setzten Microsoft und IBM scheinbar auf SPDX. Über die Nutzung von entsprechenden Client-Bibliotheken ist es allerdings auch möglich, beide Standards in einem Werkzeug zu nutzen. Am Markt beobachten wir aktuell keine offensichtliche Entscheidung für das eine oder andere Format.

Den Schluss, den wir daraus ziehen können ist, dass die Entscheidung am Ende eher über die Werkzeuge und die geplante Prozesskette geführt werden sollte. Darüber hinaus sind Konvertierungen grundsätzlich möglich. Diese sollten aber minimal gehalten und erst im finalen Prozessschritt realisiert werden.

Gibt es das eine, beste Werkzeug?

Keines der Werkzeuge war perfekt. Alle Werkzeuge, die wir untersucht haben, wiesen an der ein oder anderen Stelle Mängel auf. An den meisten Werkzeugen wird weiterhin auch noch fleißig geschrieben, verbessert und optimiert. So zeigen Tickets, dass Werkzeuge auch noch Probleme mit der Einhaltung von Spezifikationen haben.

Ein weiterer Punkt, den wir bemängeln, ist die Dokumentation. Hier wird teilweise zu wenig erklärt, wie die Werkzeuge konkret vorgehen. Besonders aufgefallen ist uns dies bei der Auswertung von Java beziehungsweise Maven Projekten. Sind nun die *.jars im Zielverzeichnis relevant oder die POM? Oder gar beides? Wie genau wird die Maven POM analysiert?

Aus dem gleichem Grund kritisieren wir auch die Ausgaben zur Laufzeit. Wenn während des Scans weitere SBOMs gefunden und ausgewertet werden, weil wir bei der Analyse zwischen den einzelnen Tests nicht sauber aufgeräumt haben, ist dies etwas, das aus unserer Sicht zumindest protokolliert werden sollte. Gleiches gilt für die Auflistung der konkreten Dateien, die zu einer Analyse herangezogen werden. Insbesondere bei der Auswertung von pom.xml oder während des Builds erzeugter *.jar Dateien.

Gerne hätten wir auch mehr Schalter oder mehr strukturierte Ausgaben, um das Werkzeug besser in den CI Build zu integrieren. Speziell definierte Return Codes o. ä. wären hier hilfreich.

Gibt ein es das eine große Projekt?

Viele Projekte erschienen uns klein, selbst die großen Projekte mit vielen Sternen hatten eine überschaubare Anzahl von Contributors und durchaus längere Listen von Issues. Diese müssten für eine noch bessere Bewertung genauer analysiert werden.

Unzufrieden sind wir auch mit dem monolithischen Ansatz einiger Applikationen. Aus unserer Sicht ist das Scannen zur Erzeugung der SBOM klar von der Auswertung der SBOM zu trennen. Trivy kann beispielsweise beides. Speziell im Lizenzbereich könnten wir uns vorstellen, die Gesamtfunktionalität auf mehrere, kleine Werkzeuge aufzuteilen, die für sich SBOM erstellen, anreichern, auslesen oder modifizieren. Möglicher Weise stehen dem marktwirtschaftliche Interessen entgegen aber auch das Bedürfnis, ein zentrales Werkzeug für alles zu haben.

Mögliche kommerzielle Gesamtlösungen, die man alternativ im Kontext SBOM Management evaluieren könnte, wären z. B.:

Anchore (Anchore ist auch der Hersteller von Syft und Grype)
Snyk.io
Mend.io
Checkpoint
JFrog
Codenotary
Rezilion
VigilantOps

Diese Liste ist sicherlich nicht vollständig.

Unter dem Strich wäre der aktuelle Stand und die genannten Mängel für uns aber kein Grund, SBOMs nicht jetzt zu nutzen. Wichtig wäre es aber, bei Fehlern Tickets zu erstellen und darin die eigenen Anforderungen klar zu äußern.

Wie gut ist das Ergebnis?

Bei der SBOM-Erstellung für Maven oder NPM-Projekte wird die Qualität maßgeblich davon beeinflusst, inwieweit das Buildsystem oder die Ergebnisse des Build korrekt ausgewertet werden. Ist dies nicht der Fall, sinkt die Qualität schnell. Beim Scannen von Docker-Containern sehen wir Unterschiede in den unterstützten Distributionen sowie bei der Erkennung von Artefakten außerhalb des Paketsystems der Distribution.

Bei der Erkennung von CVEs haben wir den Eindruck, dass die Werkzeuge bei gleicher Informationsbasis, in diesem Fall der SBOM, zu sehr ähnlichen oder gar zu gleichen Ergebnissen kommen. Hier ist aktuell scheinbar die Wahl des Werkzeugs für die SBOM-Generierung oder die verwendete Datenbank entscheidender als das Werkzeug, mit dem die CVEs gesucht wird.

Unterschiede und größere Anzahl von „False Positives“ entstehen dann, wenn die SBOM keine Versionen oder redundante Einträge mit unterschiedlicher Qualität beinhaltet.

Die Relevanz der Nutzung von CPE ist uns unklar. Wir konnten keine offensichtlichen Unterschiede in den Ergebnissen bei Verwendung oder Nicht-Verwendung sehen.

Welches Werkzeug nehme ich dann?

Wenig überraschend können wir nicht den einen Weg skizzieren. Zu viele Faktoren spielen hinein, die wichtig sein könnten und die Wahl maßgeblich beeinflussen. Wir sehen aber folgende Abwägungskriterien:

Präferenz: Tools, die nah an der semantischen Quelle arbeiten und so z. B. Informationen direkt aus dem Build-System ziehen. Dies führt tendenziell zu einer höheren Qualität – aber vermutlich auch zu der Nutzung mehrerer Werkzeuge.

Präferenz: Minimierung der Werkzeuganzahl. Grundsätzlich möglich, kann abhängig von den zu unterstützenden Stacks aber zu Qualitätsverlusten führen. Wir empfehlen, hier nicht zu dogmatisch zu sein.

Präferenz: Standard. Hier dominieren dann ggf. Werkzeuge, die SPDX als Format unterstützen. Auch dies kann zu Qualitätsverlusten führen. Die Relevanz eines ISO- Standards ist für uns schwer einzuschätzen und vermutlich stark abhängig vom konkreten Projekt-Kontext.

Präferenz: Qualität: Man nimmt die Kombination von Werkzeugen, die zu der besten SBOM und den besten Reports führt.

Präferenz: Ergebnis CVEs. Abhängig davon, ob wir den SBOM-basierenden Prozessen folgen und die entsprechenden Möglichkeiten ausreizen oder nur schnell und einfach einen CVE-Report haben wollen, kann sich die Werkzeugauswahl unterscheiden.

Wie sehen wir den Markt?

Wir sehen, dass es historisch eine Reihe von Werkzeugen gibt, die sich funktional mit der Werkzeugpalette im Kontext SBOM überschneiden. So gibt es Tools zum Asset Management und zur Lizenzanalyse, die auch Scanner nutzen und entsprechende Reports erzeugen.

Des Weiteren sehen wir einen Open-Source-Markt, der auf Basis von CycloneDX und SPDX entsprechende Werkzeuge erstellt. Hinter Teilen dieser Werkzeuge stehen allerdings kommerzielle Firmen. Dadurch können die bekannten Risiken entstehen, wie das Verschieben von relevanter Funktionalität in eine kommerzielle Version oder eine Relizensierung des aktuell freien Produkts. Eine entsprechende Risikoabwägung sollte daher in üblicher Weise durchgeführt werden, der Umgang des Herstellers mit dem Werkzeug beobachtet werden.

Eine Alternative können Portal oder SaaS-Lösungen sein, die z. B. auf Basis von Repository Scans zahlreiche Dienstleistung, intuitive Oberflächen und auch Workflow-Unterstützung anbieten. Da wir diese Werkzeuge hier nicht analysiert haben, können wir zu den Features aber auch zu den Lizenzkosten nichts sagen. Grundsätzlich tun sich hier wie auch in anderen Bereichen zwei verschiedene Wege auf.

Der kleinteilige, scheinbar wirtschaftlich günstige Weg mit mehr Eigenleistung im Bereich der zugehörigen Prozesse
Das „All in One“-Tool, das alle Aspekte abdeckt und klare Prozesse vorgibt, dafür aber möglicher Weise mehr Kosten erzeugt.

Wie gehe ich denn nun vor?

Insgesamt würden wir empfehlen, klein anzufangen und erst einmal pragmatisch und mit konkreten Zielen (CVEs, Automatisierung der Erstellung und Analyse) mit einer Integration für ein einzelnes Projekt oder Produkt zu beginnen. Hierfür sind die evaluierten Werkzeuge völlig ausreichend.

Ziel sollte sein, ein Gefühl für die Qualität sowie die gewünschten Prozesse zu bekommen – ohne gleich den Anspruch zu haben, die Prozesse technisch vollständig zu lösen. Ebenso würden wir bei der Tool-Auswahl pragmatisch vorgehen und nicht versuchen, alles mit einem Werkzeug zu lösen.

Wichtig: Sich hierbei detailliert mit den konkreten Inhalten der SBOM, deren Ursprung und deren gewünschten Qualität auseinandersetzen!

Speziell im Bereich Docker Images oder VM o.ä. empfehlen wir, Verantwortlichkeiten klar zu definieren: Wer erstellt die SBOM für die eigentliche Software? Wer erstellt eine SBOM für das Docker-Image? Wer prüft auf CVEs und reagiert mit welchen Maßnahmen?

Für die Lizenzauswertung wäre zu klären, ob auf eine SBOM-basierende Analyse gesetzt wird oder ob weiterhin mit einem separaten Prozess und ggf. auch Liefergegenstand gearbeitet werden soll. Speziell ist hier zu klären, inwieweit eine ggf. vorhandene klassische Low-Level-Lizenzanalyse von einer Lizenzbewertung auf Basis einer SBOM zu trennen ist.

Erst nachdem Erfahrungen – dann auch später in mehreren Projekten – gesammelt wurden, würden wir die nächsten Schritte empfehlen und überlegen, wie weiter skaliert und zentralisiert werden kann. Dies vor allem auch in Bezug auf die Professionalisierung der Werkzeugauswahl.