Die Software Supply Chain ist heute so komplex wie globale Logistikketten. Anwendungen setzen sich aus Hunderten oder Tausenden Dritt- und Open-Source-Komponenten zusammen, was mit beträchtlichen Sicherheitsrisiken verbunden ist. Ein Werkzeug, das in diesem Kontext zentrale Bedeutung erlangt hat, ist die Software Bill of Materials (SBOM). Doch was ist das genau, warum brauchen Unternehmen sie, und welche Kriterien muss ein SBOM-Tool erfüllen?

Für Fragen rund um Sicherheit ist fehlende Transparenz eines der zentralen Probleme. Gerade in modernen Softwarelandschaften fällt es vielen Verantwortlichen zunehmend schwer, den Überblick über Komponenten der Anwendungen zu behalten.

Build-Prozesse, transitive Abhängigkeiten und zur Laufzeit geladene Libraries sorgen dafür, dass klassische Abhängigkeitslisten oder Konfigurationsdateien nur einen Teil der Realität abbilden. Genau hier entsteht eine gefährliche Lücke zwischen Annahme und tatsächlicher Angriffsfläche.

Doch die steigende Anzahl an Abhängigkeiten wie auch indirekte und dynamische Komponenten müssen nicht unentdeckt bleiben. Eine Software Bill of Materials (SBOM) hat sich zum Mittel der Wahl entwickelt, um den nötigen Überblick zu wahren. Denn als strukturierte Aufstellung aller Softwarebestandteile – inklusive Bibliotheken, Versionen und Abhängigkeiten –, schafft sie Transparenz darüber, was tatsächlich in einer Software enthalten ist.

SBOM-Tools helfen, diese Grundlage für Security, Compliance und Incident Response zu schaffen. In der Praxis zeigt sich aber, dass nicht jede SBOM automatisch die gewünschte Transparenz liefert. Viele Lösungen orientieren sich primär am Quellcode und an Konfigurationsdateien – und bilden damit eher den geplanten als den tatsächlich ausgelieferten Softwarezustand ab. Gerade in komplexen Build- und Laufzeitumgebungen entstehen so blinde Flecken, die Security-Verantwortliche in falscher Sicherheit wiegen können.

Wer ein SBOM-Tool sucht, sollte daher nicht nur fragen, ob eine SBOM erzeugt wird, sondern wie und auf welcher Grundlage. Die folgenden Fragen helfen dabei, moderne, effiziente von veralteten, klassischen Lösungen zu unterscheiden. Lassen sie sich mit „Ja“ beantworten, spricht dies für ein SBOM-Tool, das optimale Sicherheit gewährleisten kann.

1. Vollständigkeit der Artefakte

• Wird die tatsächlich ausgelieferte Software analysiert, also das vollständige Softwarepaket bzw. Container-Image?
• Werden neben direkten auch indirekte Abhängigkeiten erfasst?
• Werden dynamisch eingebundener Komponenten berücksichtigt?
• Werden auch weitere Artefakte wie Microcode, binäre Firmware- oder KI-Blobs berücksichtigt?
• Erkennt das Tool statisch gelinkte Bibliotheken?

2. Aktueller, realer Softwarestand

• Erfolgt die Identifikation komponentenbasiert (zum Beispiel via Hash-/Fingerprint-Verfahren) und nicht nur deklarativ?
• Kann das Tool auch verschleierte oder umbenannte Bibliotheken erkennen?
• Werden die finalen Binaries betrachtet und analysiert?
• Geht die Lösung über die reine Ableitung aus Build- oder Konfigurationsdateien hinaus?

3. Automatisierter Schwachstellenabgleich

• Erfolgt ein automatisierter Abgleich mit aktuellen CVE-Datenquellen?
• Werden bekannte Exploits berücksichtigt?
• Wird zwischen theoretischer Betroffenheit und tatsächlicher Exposition unterschieden?
• Erfolgt eine klare Zuordnung von Schwachstellen zu konkreten Komponenten?

4. Verständliche Aufbereitung der Ergebnisse

• Werden strukturierte Reports statt Rohdaten generiert?
• Unterstützt das Tool eine risikobasierte Priorisierung gefundener Schwachstellen, zum Beispiel nach Schweregrad, Exploitabilität oder Reichweite?
• Unterstützten Security-Reportings bei der Entscheidungsfindung?

5. Unterstützung von Compliance-Anforderungen

• Sind Audit-Trails und revisionssichere Reports verfügbar?
• Sind Ergebnisse nachvollziehbar (beispielsweise Reports, nicht nur SBOM-Generierung)?

6. Einfache Integration in bestehende Prozesse

• Lässt sich das Tool ohne tiefgreifende Änderungen in bestehende CI/CD-Prozesse integrieren?
• Unterstützt das Tool Policy-Gates, die die Auslieferung bei definierten Risiken abbricht?

Der Application Supply Guard beispielsweise ist ein SBOM-Tool der nächsten Generation, das eine einfache Nutzung ermöglicht. Nach der Registrierung können Verantwortliche die zu analysierenden Daten hochladen. In kurzer Zeit erhalten sie dann nicht nur die SBOM-Analyse, sondern auch einen Security-Report, der alle bekannten Schwachstellen, die in aktuellen CVE-Datenbanken aufgelistet sind, einbezieht und eine umfassende Risikobewertung ausgibt.

SBOMs sind mehr als ein Compliance-Instrument – sie sind der Grundstein für ein transparentes, messbares und proaktives Software-Supply-Chain-Security-Management. Ohne sie bleiben Risiken unsichtbar und unkontrollierbar. Modernen SBOM-Tools kommt dabei eine Schlüsselrolle zu, um Unternehmen sicherer und widerstandsfähiger zu machen.