Was ist Software Composition Analysis (SCA)?

Wie SCA funktioniert

1. Die Komponenten identifizieren. Das Tool liest, worauf es gerichtet ist: Manifeste und Lockfiles in einem Repository, installierte Pakete oder den Inhalt eines Container-Images oder einer Binärdatei. Das Ergebnis ist ein Inventar von Komponenten und Versionen, oft als SBOM exportiert.
2. Mit bekannten Risiken abgleichen. Jede Komponente wird in Schwachstellendatenbanken wie der GitHub Advisory Database, OSV und der NVD nachgeschlagen, und ihre deklarierte Lizenz wird mit Ihrer Policy verglichen.
3. Priorisieren. Befunde werden nach Schweregrad sortiert, und manche Tools ergänzen eine Erreichbarkeitsanalyse, um zu prüfen, ob Ihr Code die verwundbare Funktion überhaupt aufrufen kann.
4. Beheben. Viele Tools schlagen eine korrigierte Version vor oder öffnen einen Pull Request, so wie Dependabot und Renovate. Bei einer verwundbaren transitiven Abhängigkeit liegt die Lösung meist in dem Paket, das sie nachzieht; welches das ist, zeigt ein Abhängigkeitsgraph.

Was SCA findet

• Bekannte Schwachstellen in den von Ihnen genutzten Versionen, mit den Advisories, die sie beschreiben.
• Lizenzrisiken, etwa eine Copyleft-Lizenz in einem proprietären Produkt.
• Veraltete und ungepflegte Pakete, die keine Sicherheitsfixes mehr erhalten werden.
• Bösartige Pakete, bei Tools, die auch das Verhalten von Paketen analysieren, statt nur Advisories abzugleichen.

SCA vs. SAST

SCA und statische Anwendungssicherheitstests (SAST) werden oft zusammen verkauft, betrachten aber unterschiedlichen Code und beantworten unterschiedliche Fragen.

	SCA	SAST
Was es analysiert	Die Open-Source- und Drittanbieter-Komponenten, von denen Sie abhängen	Den Code, den Ihr Team schreibt
Was es findet	Bekannte Schwachstellen, Lizenzprobleme, veraltete Pakete	Fehler in Ihrem Code, etwa Injection oder unsichere Eingabeverarbeitung
Was es liest	Manifeste, Lockfiles, installierte Pakete, Images oder Binärdateien	Quellcode
Was einen neuen Befund auslöst	Eine Änderung an Abhängigkeiten oder ein neues Advisory für eine bereits ausgelieferte Version	Eine Änderung an Ihrem Code
Typisches Ergebnis	Verwundbare Komponenten mit korrigierten Versionen und eine SBOM	Codestellen mit dem Fehler und einem Lösungsvorschlag

Sie brauchen beides. Eine Codebasis ohne SAST-Befunde kann trotzdem eine verwundbare Abhängigkeit ausliefern, und ein sauberer Abhängigkeitsbaum sagt nichts über Ihren eigenen Code aus. Den vollständigen Vergleich finden Sie unter SAST vs. SCA. Ein Unterschied ist für den Betrieb wichtig: Ein SAST-Befund erscheint, wenn sich Ihr Code ändert, ein SCA-Befund dagegen kann an einem Release auftauchen, das Sie vor Monaten ausgeliefert haben, nämlich an dem Tag, an dem ein neues Advisory erscheint.

Wo SCA endet

Jedes SCA-Ergebnis hängt von Schritt eins ab: dem Identifizieren der Komponenten. Eine Komponente, die das Tool nie identifiziert hat, lässt sich nicht abgleichen, priorisieren oder beheben, und sie erscheint auch nicht als Lücke. Die häufigen blinden Flecken:

• Was nicht in den Dateien steht. Die meisten SCA-Tools lesen Manifeste und Lockfiles. Ein fehlendes oder veraltetes Lockfile, aus CI-Caches wiederhergestellte Pakete, Build-Tools, Downloads und Install-Skripte erreichen das Inventar nie. Siehe warum ein Lockfile keine Aufzeichnung des Ausgelieferten ist.
• Tools widersprechen sich. Zwei Scanner, die auf denselben Commit gerichtet sind, liefern unterschiedliche Komponentenlisten, weil jeder eigene Regeln dafür hat, was er liest und wie er es benennt. Siehe was Open-Source-SBOM-Generatoren übersehen.
• Binärdateien. Software, die als vorkompilierte Binärdatei verteilt wird, deklariert wenig oder nichts, was ein Manifest-Leser sehen kann.
• Nur bekannte Schwachstellen. Der Abgleich findet, was veröffentlicht wurde. Zu einem neuen bösartigen Paket oder einem nicht offengelegten Fehler gibt es noch kein Advisory.
• Eine Momentaufnahme. Ein Scan in einem Pull Request beschreibt diesen Moment. Neue Advisories für Versionen, die bereits in Produktion sind, brauchen etwas, das das Ausgelieferte weiter prüft.

Das ist kein Fehler eines einzelnen Produkts. So funktioniert Scannen, ob kommerziell oder Open Source. CRACI hat verwundbare Pakete gefunden, die Snyk und Aikido nicht gemeldet haben, weil die Komponenten nie in dem enthalten waren, was sie gescannt haben.

Den Build aufzeichnen, Ihre SCA behalten

CRACI schließt die Identifikationslücke von der Build-Seite her. Es ist ein GitHub-Actions-Runner, der jedes Paket aufzeichnet, das ein Job lädt, auf jeder Ebene des Baums und einschließlich der aus CI-Caches wiederhergestellten Pakete, und zwar in einer SBOM, die ihre eigene Vollständigkeit angibt. Es bewertet die SBOMs des Ausgelieferten laufend neu, sobald neue Schwachstellen veröffentlicht werden, und die Build-Historie zeigt, welche früheren Builds ein verwundbares Paket enthielten.

CRACI macht bewusst weder SAST noch Erreichbarkeitsanalyse. Teams setzen es neben einem SCA- oder SAST-Tool ein, das Pull Requests und ihren eigenen Code abdeckt. Siehe SCA-Tools im Vergleich, wo CRACI neben Ihren SCA-Tools ansetzt, oder buchen Sie eine Demo, um eine aufgezeichnete SBOM mit Ihrem aktuellen Scan zu vergleichen.

Software Composition Analysis: häufig gestellte Fragen

Was ist SCA in der Cybersicherheit?

Software Composition Analysis (SCA) ist die Praxis, die Open-Source- und Drittanbieter-Komponenten in Ihrer Software zu finden und auf bekannte Schwachstellen, Lizenzprobleme und veraltete Versionen zu prüfen. Sie deckt den Code ab, von dem Sie abhängen, im Unterschied zu dem Code, den Sie schreiben.

Was ist der Unterschied zwischen SCA und SAST?

SAST analysiert den Code, den Ihr Team schreibt, auf Fehler wie Injection-Bugs. SCA analysiert die Komponenten, von denen Sie abhängen, auf bekannte Schwachstellen und Lizenzprobleme. Beide beantworten unterschiedliche Fragen, deshalb setzen die meisten Sicherheitsprogramme beide ein.

Was bedeutet SCA-Scanning?

Ein SCA-Scan liest die Manifeste, Lockfiles, installierten Pakete oder ein Container-Image eines Projekts, ermittelt, welche Komponenten enthalten sind, und gleicht sie mit Schwachstellen- und Lizenzdaten ab. Das Ergebnis ist eine Liste von Befunden, oft mit einer SBOM der identifizierten Komponenten.

Ist eine SBOM dasselbe wie SCA?

Nein. Eine SBOM ist ein Inventar: die Liste der Komponenten in einem Release. SCA ist die Analyse: Komponenten identifizieren und auf Risiken prüfen. Viele SCA-Tools erzeugen dabei eine SBOM, und eine SBOM kann nach dem Release in die Schwachstellenüberwachung einfließen.

Welche Grenzen hat SCA?

Sie analysiert nur die Komponenten, die sie identifizieren kann, meist aus Manifesten und Lockfiles. Aus CI-Caches wiederhergestellte Pakete, Build-Tools, Downloads und Binärdateien ohne Paketmetadaten können übersehen werden. Sie findet bekannte Schwachstellen, keine unbekannten, und ein Scan ist eine Momentaufnahme, sofern das Tool das Ausgelieferte nicht weiter prüft.

Was sind die besten SCA-Tools?

Das hängt davon ab, was Sie über die Grundlagen hinaus brauchen: Erreichbarkeitsanalyse, Erkennung bösartiger Pakete, Lizenz-Policy oder Entwickler-Workflow. Unser Vergleich von 13 SCA-Tools zeigt, was jedes abdeckt und wo es aufhört.