Von SCA zur SBOM: Ein Praxisleitfaden zur Migration
| Interlynk
Die meisten Teams, die Software Composition Analysis (SCA) einsetzen, betreiben bereits eine SBOM-Pipeline. Sie bewahren das Ergebnis nur nicht auf. Das Tool erstellt ein Inventar Ihrer Abhängigkeiten, gleicht es mit Schwachstellendaten ab und sperrt das Ergebnis in einer Konsole ein, die Sie pro Arbeitsplatz mieten. Das Inventar, das im Zentrum all dessen steht, ist in jeder Hinsicht eine Software Bill of Materials (SBOM, Softwarestückliste) – nur ohne diesen Namen.
Sobald Sie SCA so betrachten, wirkt die Migration zu einem SBOM-first-Workflow nicht mehr wie ein Rip-and-Replace-Projekt, sondern wie die Rückgewinnung eines Artefakts, das Sie ohnehin schon erzeugt haben. Dieser Leitfaden zeigt, was die beiden Ansätze tatsächlich leisten, warum ein offener SBOM-Workflow einen eigenständigen Scanner ersetzen kann, welche Voraussetzungen zuvor erfüllt sein müssen und welchen Migrationspfad Sie ohne Lücke in der Abdeckung beschreiten können.
Was ein SCA-Tool mechanisch leistet
Es hilft, zu trennen, was ein SCA-Produkt tut, von der Art, wie es verpackt ist. Unter dem Dashboard besteht die Arbeit aus drei aufeinanderfolgenden Schritten.
Das Tool erstellt ein Abhängigkeitsinventar. Es durchläuft Ihre Lockfiles und Manifeste, löst den vollständigen transitiven Baum auf und erzeugt eine Liste von Komponenten mit Versionen und Identifikatoren wie purl und CPE. Diese Liste ist per Definition eine Software Bill of Materials. Sie wird lediglich innerhalb einer proprietären Oberfläche dargestellt, anstatt als portierbare Datei zurückgegeben zu werden.
Anschließend gleicht das Tool dieses Inventar mit einer Schwachstellendatenbank und einem Satz von Lizenzrichtlinien ab und erzeugt daraus Befunde.
Schließlich präsentiert es diese Befunde über einen Workflow, für den Sie eine Lizenz erwerben: Dashboards, Gates, Berichte und Zugang pro Arbeitsplatz.
Der erste Schritt ist die SBOM-Erzeugung. Der zweite ist der Schwachstellenabgleich. Der dritte ist die Verpackung. Zu erkennen, dass die ersten beiden Standardoperationen sind und Sie für den dritten einen Aufpreis zahlen, ist die Grundlage des Migrationsarguments.
Was ein SBOM-first-Workflow leistet
Ein SBOM-first-Workflow führt dieselben beiden mechanischen Operationen aus. Der Unterschied besteht darin, dass er sie entkoppelt und das Artefakt ins Zentrum stellt.
Sie erzeugen eine standardisierte SBOM zur Build-Zeit. Die beiden dominierenden Formate sind SPDX, der Standard der Linux Foundation, international anerkannt als ISO/IEC 5962:2021, und CycloneDX, der OWASP-Flaggschiffstandard, ratifiziert als ECMA-424. Beide sind maschinenlesbar, beide sind offen, und beide werden von einem großen Ökosystem an Werkzeugen unterstützt.
Anschließend gleichen Sie diese SBOM fortlaufend mit Schwachstelleninformationen ab und wenden Triage-Daten an, um Befunde zu unterdrücken, die auf Ihr Deployment nicht zutreffen.
Das Ergebnis ist eine portierbare, signierbare Datei, die exakt festhält, was ausgeliefert wurde. Sie können sie Wochen später erneut scannen, sie mit einem Kunden teilen oder sie bei einer Aufsichtsbehörde einreichen. Nichts davon können Sie zuverlässig mit Befunden tun, die in einer Anbieterkonsole eingeschlossen sind.
Der eigentliche Unterschied: Eigentum, nicht Leistungsfähigkeit
Es lohnt sich, präzise zu sein, worin SCA und ein SBOM-Workflow sich tatsächlich unterscheiden – denn es liegt nicht in dem, was sie erkennen können.
Ein eigenständiger Scanner erzeugt Befunde innerhalb einer Oberfläche, die Ihnen nicht gehört und die Sie nicht mitnehmen können. Ein SBOM-Workflow erzeugt ein standardisiertes Artefakt, das vollständig Ihnen gehört und das Sie überall weiterverwenden können. Der Schwachstellenabgleich, die Lizenzprüfungen, die Auflösung der Abhängigkeiten: All das ist in beiden vorhanden. Was sich ändert, ist, ob Sie am Ende mit einem Vermögenswert oder mit einem Abonnement dastehen.
Jeder praktische Vorteil des SBOM-Ansatzes ergibt sich aus diesem einen Unterschied. Portierbarkeit, teamübergreifende Wiederverwendbarkeit, langfristiges erneutes Scannen und die direkte Nutzung in der Compliance hängen alle davon ab, dass Sie das Artefakt selbst besitzen, statt es durch das Produkt eines anderen zu betrachten.
Sie benötigen die Schwachstellendatenbank des Anbieters nicht mehr
Jahrelang war der stärkste Einwand gegen den Abschied von SCA die Datenbasis. Man ging davon aus, dass der kommerzielle Schwachstellen-Feed eines Anbieters spürbar besser sei als alles, was Sie selbst zusammenstellen könnten. Dieser Vorteil ist weitgehend verschwunden.
OSV.dev, Googles offene Schwachstellendatenbank, liefert präzise, versionsgenaue Betroffenheitsbereiche über Ökosysteme hinweg, und ihr Scanner liest SPDX- und CycloneDX-SBOMs direkt ein. Offene Matcher wie Grype verknüpfen die NVD, OSV und ökosystemspezifische Advisories – also dieselben Primärquellen, aus denen auch kommerzielle Tools schöpfen. OWASP Dependency-Track geht noch weiter: Statt einmalig zu scannen, nimmt es SBOMs in einen persistenten Speicher auf und bewertet sie fortlaufend neu, sobald neue CVEs veröffentlicht werden – mit integrierter Priorisierung auf Basis von EPSS.
Diese fortlaufende Neubewertung ist die Fähigkeit, die die meisten Scanner-Nutzer unterschätzen. Ein zeitpunktbezogener Scan meldet, was im Moment seiner Ausführung verwundbar war. Eine überwachte SBOM meldet, was jetzt verwundbar ist – denn für eine Komponente, die zur Build-Zeit sauber war, kann nach dem Release eine kritische Schwachstelle bekannt werden. Ein nur beim Commit ausgelöster Pipeline-Scan verpasst dieses Zeitfenster vollständig; eine fortlaufend überwachte SBOM nicht.
Für False Positives erlaubt Ihnen VEX (Vulnerability Exploitability eXchange), in einer dokumentierten und prüffähigen Form festzuhalten, dass eine markierte Schwachstelle in Ihrem konkreten Kontext nicht erreichbar oder nicht ausnutzbar ist, und sie von Ihrem Werkzeug auf dieser Grundlage unterdrücken zu lassen. Das ist ein belastbarer, überprüfbarer Nachweis statt einer Einstellung, die in einer proprietären Konsole verborgen ist.
Für regulierte Teams ist die SBOM bereits vorgeschrieben
In regulierter Software ist die Argumentation für einen SBOM-first-Workflow nicht nur stichhaltig, sondern nahezu zwangsläufig – denn die SBOM ist bereits ein verpflichtendes Lieferobjekt.
Software für Medizinprodukte ist das deutlichste Beispiel. Nach Section 524B des FD&C Act, in Kraft seit dem 29. März 2023, müssen Hersteller von „cyber devices“ eine maschinenlesbare SBOM, die kommerzielle, Open-Source- und Off-the-Shelf-Komponenten abdeckt, in ihre vormarktlichen Einreichungen aufnehmen. Die finale vormarktliche Cybersicherheits-Leitlinie der FDA, herausgegeben im Juni 2025, macht eine unzureichende SBOM zum Grund für eine Refuse-to-Accept-Entscheidung und verweist auf SPDX und CycloneDX als erwartete Formate.
Im EU-Raum macht der Cyber Resilience Act (CRA) SBOMs ebenfalls zu einer zentralen Anforderung, und in Deutschland behandelt das BSI die Anforderungen an SBOMs in seiner technischen Richtlinie TR-03183.
Allgemeiner gefasst heben CISAs „Minimum Elements for an SBOM“ aus dem Jahr 2025, die auf der NTIA-Baseline von 2021 aufbauen, die Erwartungen durch zusätzliche Felder an – darunter Komponenten-Hash, Lizenz, Toolname und Erzeugungskontext –, die allesamt die maschinelle Verarbeitbarkeit im großen Maßstab unterstützen sollen.
Die Schlussfolgerung ist unmittelbar. Wenn Sie in diesem Bereich tätig sind, erzeugen Sie aus Compliance-Gründen ohnehin bereits eine SBOM, gleichgültig welchen Scanner Sie betreiben. Ihre Schwachstellenerkennung auf dasselbe Artefakt auszurichten, fügt keinen Workflow hinzu, sondern führt zwei zusammen. Die Alternative besteht darin, einen Anbieter dafür zu bezahlen, ein Abhängigkeitsinventar zu erstellen, und dieses Inventar dann in einem anderen Format für die Aufsichtsbehörde erneut aufzubauen – ohne eine gemeinsame Quelle der Wahrheit zwischen beiden. Diese Doppelarbeit ist die Kluft zwischen operativer Lieferkettensicherheit und dem bloßen Abhaken von Compliance-Vorgaben, und genau diese Kosten beseitigt ein SBOM-first-Workflow.
Zwei Voraussetzungen für eine vollständige Ablösung
Ein SBOM-first-Workflow kann eigenständige SCA vollständig ersetzen – aber nur, wenn zwei Voraussetzungen erfüllt sind. Es lohnt sich, sie klar zu benennen, denn ihr Überspringen ist der Weg, auf dem SBOM-Programme scheitern.
Sie benötigen Zugang zum Code oder zum Build. Die genauesten SBOMs werden zur Build-Zeit aus dem Quellcode erzeugt, wo der Resolver den realen transitiven Baum und die exakten ausgelieferten Versionen beobachtet. Ein nachträgliches Scannen einer geschlossenen Drittanbieter-Binärdatei ist möglich, aber verlustbehaftet. Wenn Sie CI so instrumentieren können, dass bei jedem Build eine SBOM ausgegeben wird, erreichen Sie eine Genauigkeit, die das, was ein SCA-Tool extern rekonstruiert, erreicht oder übertrifft. Wo Sie den Build nicht beeinflussen können, ist der SBOM-Ansatz tatsächlich schwieriger, und das sollte in Ihre Planung einfließen.
Sie benötigen einen abgestimmten Workflow zwischen Entwicklung und Compliance. Dies ist der Teil, den kein Werkzeug liefern kann. Das Engineering verantwortet die Erzeugung: SBOMs werden in CI als reguläres Build-Ergebnis erstellt, vergleichbar mit einem Testbericht. Security und Compliance verantworten die Nutzung: das Einlesen der SBOMs, ihre fortlaufende Überwachung, das Anfügen von VEX und die Einspeisung in die regulatorische Einreichung. Wenn diese beiden Hälften nicht verbunden sind, werden SBOMs erzeugt und nie ausgewertet – genau jener Fehlermodus, der dem Format seinen Ruf als reine Pflichtübung eingebracht hat.
Erfüllen Sie beide Voraussetzungen, so gibt es keine Funktion, die ein eigenständiger Scanner erbringt und die Ihre eigene Pipeline nicht ebenso leistet – mit einem portierbaren Artefakt in Ihrem Besitz am Ende. Verfehlen Sie auch nur eine, ist der richtige Schritt, zuerst den Workflow in Ordnung zu bringen und Ihr bestehendes Werkzeug so lange beizubehalten, bis dies geschehen ist.
Der Migrationspfad
Der Übergang erfordert keine harte Umstellung. Betreiben Sie den SBOM-Workflow parallel zu Ihrem bestehenden Scanner, bis er Gleichstand erreicht, und stellen Sie dann das Abonnement ein.
Erzeugen. Geben Sie bei jedem CI-Build eine SPDX- oder CycloneDX-SBOM aus dem Quellcode aus und behandeln Sie sie als vollwertiges Build-Artefakt.
Speichern und überwachen. Nehmen Sie diese SBOMs in eine Plattform zur fortlaufenden Überwachung auf, damit sie bei der Veröffentlichung neuer Schwachstellen gegen OSV, NVD und Advisory-Feeds neu bewertet werden – und nicht nur zum Scan-Zeitpunkt.
Triagieren. Führen Sie VEX für die dokumentierte, prüffähige Unterdrückung nicht ausnutzbarer Befunde ein und nutzen Sie EPSS, um den Behebungsaufwand dort zu priorisieren, wo er zählt.
Compliance anbinden. Leiten Sie dieselben SBOMs in Ihre regulatorischen Einreichungen, sodass ein einziges Artefakt sowohl dem Schwachstellenmanagement als auch der Compliance dient.
Vergleichen und umstellen. Betreiben Sie beide Systeme über ein oder zwei Releases hinweg parallel. Sobald der SBOM-Workflow erfasst, was der Scanner erfasst hat, dabei zugleich fortlaufende Abdeckung und ein Artefakt in Ihrem Besitz liefert, stellen Sie das eigenständige Werkzeug außer Betrieb.
Fazit
Software Composition Analysis war ein sinnvolles Produkt in einer Ära ohne SBOM-Standards. Diese Ära liegt hinter uns. SPDX und CycloneDX sind internationale Standards, die Schwachstellendaten sind offen, die unterstützenden Werkzeuge sind ausgereift, und in regulierter Software ist die SBOM verpflichtend, unabhängig davon, welchen Scanner Sie verwenden.
Sobald Sie eine standardisierte SBOM erzeugen, die Ihnen gehört, ist es – ganz offen gesagt – Bezahlen für Compliance-Theater statt für operative Sicherheit, wenn Sie einen separaten Anbieter dafür bezahlen, dasselbe Inventar hinter einer Konsole erneut aufzubauen. Bei Zugang zum Code und einem abgestimmten Workflow zwischen Entwicklung und Compliance leistet eine SBOM-first-Pipeline alles, was ein eigenständiges SCA-Tool tut – und lässt Sie am Ende mit dem Artefakt in der Hand zurück.
Weiterführende Literatur: SPDX (Linux Foundation, ISO/IEC 5962:2021) · OWASP CycloneDX (ECMA-424) · CISA 2025 Minimum Elements for an SBOM · FDA premarket cybersecurity guidance · OSV.dev · OWASP Dependency-Track