Binaries im Blick – 360°-Sicherheit dank SBOM-Tool der nächsten Generation

Die Nachrichten von Angriffen auf die Software-Lieferkette häufen sich – und haben sich längst zum erheblichen Sicherheitsrisiko für Organisationen entwickelt. Mal wird von einem Schadcode im JavaScript-Paketmanager npm berichtet. Beim nächsten Mal hat sich ein unsichtbarer Wurm in Visual Studio Extensions eingeschlichen. Die Szenarien sind vielfältig. Doch die unentdeckten Schwachstellen haben eines gemeinsam: Sie können Unternehmensprozesse lahmlegen, Compliance- und Haftungsrisiken nach sich ziehen und am Ende nicht nur wirtschaftliche Einbußen, sondern auch verlorenes Kundenvertrauen zur Folge haben.

Auch wer sich bereits in Sicherheit wähnt, da er auf eine Lösung zur Erstellung einer Software Bill of Materials, kurz SBOM, setzt, sollte weiterlesen. Denn SBOM-Tool ist nicht gleich SBOM-Tool.

Wieso SBOM?

Aber auf Anfang. Egal ob Source Code, Drittanbieter-Code, Abhängigkeiten, Toolchains oder Open-Sourc-Bibliotheken – eine Software-Lieferkette besteht aus unzähligen Komponenten und weist verschiedene Software-Lebenszyklen auf. Das macht sie meist zu einem intransparenten Konstrukt. Herrscht im Unternehmen diesbezüglich Ungewissheit, können sich Angreifer ungehindert Zugriff verschaffen.

Daher ist eine Software Bill of Materials (SBOM), die Komponenten, Bibliotheken und somit auch alle Abhängigkeiten aufführt, unbedingt zu empfehlen. Teils ist sie sogar das sinnvollste Mittel, um Forderungen von NIS2, DORA oder dem Cyber Resilience Act (CRA) zu erfüllen. Schließlich ist Transparenz über eingesetzte IT-Komponenten (hier die Software), sichere Lieferketten und systematisch erfasste Risiken der Software-Lieferkette dank ihr möglich.

Klassische SBOM-Tools generieren jedoch die Software-Stücklisten nur während des Build-Prozesses – oft basierend auf Konfigurationsdaten statt auf den finalen Binaries. Ein Vorgehen, das Gefahren birgt.

Vier Schwachstellen klassischer SBOM-Tools

Wer schon auf ein bestimmtes SBOM-Tool setzt oder gerade dabei ist, Lösungen zu vergleichen, sollte genau hinsehen. Gerade vier Aspekte gilt es zu vermeiden, um eine effektive Sicherheit erreichen zu können:

Unvollständig: Klassische SBOM-Tools, die lediglich den Quellcode analysieren, lassen viele Abhängigkeiten unberücksichtigt, die erst im Verlauf des Build- oder Compile-Prozesess eingebunden werden. Eingebettete oder transitive Abhängigkeiten, wie Third-Party-Binaries (zum Beispiel .jar, .so, .dll), werden nicht erkannt. Die Folge: Die erzeugte SBOM repräsentiert nicht das tatsächlich ausgelieferte Artefakt und ist unvollständig. Und was man nicht sieht, kann man nicht kontrollieren.
Überholt: Auch Software altert sicherheitstechnisch, da mit der Zeit zunehmend Schwachstellen in ihren Komponenten entdeckt werden. SBOM-Daten sind jedoch nur eine Momentaufnahme der Software-Stückliste. Werden beim Bau bzw. Deployment der Software weitere Komponenten geladen, ist die ausgelieferte SBOM längst veraltet.
Unberücksichtigt: Aus der Analyse des Quellcodes gehen nicht immer direkt alle Sicherheitsrisiken hervor. Viele Assets bleiben daher unter dem Radar, weil kein Quellcode vorliegt. Werden beispielsweise statische API-Keys und Backend-URL beim Bau bzw. Deployment der Software hinzugefügt, bleiben derartige Artefakte meist unbeachtet. Auch Assets, die bereits zum Entwicklungszeitpunkt nur als Binärdaten vorliegen, werden häufig nicht erfasst, beispielsweise Microcode, Firmware-oder KI-Blobs.
Unpriorisiert: Eine SBOM beschreibt ausschließlich die in einer Software enthaltenen Komponenten – vergleichbar mit einer Stückliste. Aussagen über konkrete Sicherheitsrisiken entstehen erst durch den Abgleich mit Schwachstellendatenbanken, zum Beispiel CVE. Insbesondere bei größeren Projekten kann daraus eine umfangreiche Liste potenzieller Findings resultieren. Ohne strukturierte Bewertung besteht die Gefahr, dass kritisch ausnutzbare Schwachstellen in einer Vielzahl weniger relevanter Einträge untergehen. Eine risikobasierte Priorisierung – unter Berücksichtigung von Schweregrad, Exploitabilität, tatsächlicher Exposition und Remediationsaufwand – ist daher zwingend erforderlich, um Maßnahmen zielgerichtet und effizient umzusetzen.

SBOM-Tool weitergedacht

Klingt unbefriedigend? War es auch. Lange Zeit konnten Unternehmen somit Software Supply Chain Security nicht zu 100 Prozent sicherstellen. Eine Herausforderung, der wir uns gerne angenommen haben. Gemeinsam mit unserem Partner ReversingLabs, der schon immer für vollständige Sicherheit der Software-Lieferkette steht, haben wir ein neues SBOM-Tool entwickelt: den Application Supply Guard.

Der Application Supply Guard analysiert die Software in dem Zustand, in dem sie tatsächlich zum Einsatz kommt: auf Ebene des fertigen Binary. Auf dieser Basis wird eine vollständige Software Bill of Materials erstellt, die alle enthaltenen Komponenten abbildet. Jede identifizierte Komponente wird automatisiert mit aktuellen CVE-Datenbanken abgeglichen, um bekannte Schwachstellen und Abhängigkeiten zu erkennen.

Großgeschrieben: NUTZERFREUNDLICHKEIT

Da SBOM-Analysen häufig schwer zu interpretieren sind, setzt der Application Supply Guard auf ein übersichtliches und aussagekräftiges Reporting. Die Ergebnisse werden strukturiert in einem Security-Report, inklusive Schwachstellenbericht, aufbereitet und schaffen eine belastbare Grundlage für gezielte Sicherheitsmaßnahmen. Das Beste: Um dorthin zu gelangen, müssen Verantwortliche nur drei Schritte gehen.

Informationen zu Kontaktdaten und Zahlungsmittel genügen, um sich beim Application Supply Guard zu registrieren.
Ob Binary, Docker-Image oder ZIP – im nächsten Schritt lassen sich bereits die wichtigen Daten hochladen. Die Bearbeitung erfolgt verschlüsselt und alle Informationen werden nach der Analyse vollständig gelöscht.
Neben der SBOM erhalten Nutzer den Security-Report. Denkbare Sicherheitslücken lassen sich somit in schnell und zielgerichtet aufdecken und aus dem Unternehmen verbannen.

SBOM-Analyse – aber sicher!

In komplexen Software-Ökosystemen sind verlässliche, automatisierte SBOM-Reports kein Nice-to-have mehr – sie stellen ein Sicherheits- und Compliance-Muss dar. Der Application Supply Guard schließt hier eine Lücke, die klassische Tools offenlassen, und liefert komplette Transparenz über alle eingesetzten Komponenten und ihre Risiken.

Sie wollen Ihre Software Supply Chain durchleuchten? Es trennen Sie nur noch drei Schritte!

Jetzt Termin vereinbaren