SCAWerkzeuge.
Software Composition Analysis erkennt Open-Source- und Drittkomponenten, deren Versionen, Lizenzen und bekannte Schwachstellen. SCA schafft die Grundlage für eine belastbare SBOM, beantwortet aber nicht allein, ob eine Schwachstelle im eigenen Produkt ausnutzbar ist.
Abhängigkeiten kennen.
SCA bindet sich an Repositories, Paketmanager und Builds. Entscheidend ist eine nachvollziehbare Komponentenliste pro Release und ein Prozess, der Befunde an Produkt, Release und verantwortliches Team zurückführt.
Eine SBOM ist die Stückliste; SCA ist die Analyse- und Steuerungsfähigkeit darum herum. VEX kann den Betroffenheitsstatus einer bekannten Schwachstelle ausdrücken. Beides ersetzt keine technische Prüfung und keinen Fix.
Plattformen im Vergleich.
| Plattform | Geeignet für | Stärke | Vor Auswahl prüfen |
|---|---|---|---|
| Snyk Open Source | Entwicklernahe Cloud-native Teams | Abhängigkeiten im Entwicklerworkflow | Repository-, Container- und Lizenzumfang |
| Mend SCA | Open-Source-Governance im Enterprise | Komponenten, Lizenzen und Policies | Automatisierte Updates und Freigaberegeln |
| Black Duck | Software Supply Chain und Compliance | Open-Source- und Lizenzanalyse | Policy-Modell und Integrationen |
| GitHub Dependabot | GitHub-zentrierte Repositories | Dependency Alerts und Update-Workflow | Reichweite ausserhalb von GitHub |
| JFrog Xray | Artifact- und Build-zentrierte Teams | Analyse entlang der Artefaktkette | Repository- und Paketmanager-Abdeckung |
| Sonatype Lifecycle | Policy-gesteuerte Softwarelieferung | Komponenten- und Supply-Chain-Policies | Entwickler- und Build-Integration |
| Checkmarx SCA | Integrierte AppSec-Plattform | SCA neben SAST und weiteren Scannern | Einheitliche Triage und Datentiefe |
| Veracode SCA | SaaS-AppSec-Programme | Komponentenrisiken im Plattformkontext | SBOM-, Lizenz- und Releaseprozess |
Bei CRA-relevanten Produkten zählt nicht nur die Existenz einer Komponentenliste. Betroffenheit, Korrektur, Veröffentlichung von Sicherheitsinformationen und Supportzeitraum müssen pro Produkt und Release steuerbar bleiben.
Policy zuerst,
dann Gate.
- Lizenz-Policy mit dem Rechtsdienst festlegen: erlaubte, prüfpflichtige und verbotene Lizenzen, getrennt nach intern genutzter und ausgelieferter Software.
- SCA neben dem Quellcode auch auf Build-Artefakte und Container-Images anwenden, damit transitive und nachträglich eingebundene Komponenten sichtbar werden.
- Das Security-Gate stufen: neue Komponenten mit bekannter kritischer Schwachstelle blockieren, den Bestand mit Frist korrigieren.
- Bewertungen mit VEX-Status dokumentieren (nicht betroffen, betroffen, behoben, in Prüfung), damit Kunden und Prüfer sie nachvollziehen können.
- Anteil ausgelieferter Releases mit archivierter, maschinenlesbarer SBOM
- Zeit von Veröffentlichung einer kritischen Schwachstelle bis zur Betroffenheitsaussage je Produkt
- Anzahl Komponenten mit verbotener oder ungeklärter Lizenz in ausgelieferten Releases
Produktteams beheben Funde und dokumentieren die Betroffenheit; die AppSec-Funktion betreibt Werkzeug und Policies. Lizenzfragen entscheidet der Rechtsdienst, Meldungen nach aussen verantwortet die Product-Security-Funktion.
ISO/IEC 27001:2022 Annex A 8.8 (Management technischer Schwachstellen) und 5.32 (Geistige Eigentumsrechte) für Lizenzpflichten; DORA Art. 25 nennt Open-Source-Analysen ausdrücklich als Testart.
Der CRA verlangt in Anhang I Teil II (anwendbar ab 11. Dezember 2027) eine SBOM in einem gängigen maschinenlesbaren Format, mindestens mit den obersten Abhängigkeiten; seit 11. September 2026 gilt die Meldepflicht nach Art. 14 für aktiv ausgenutzte Schwachstellen mit Frühwarnung innert 24 Stunden.
Nicht nur Pakete aus Paketmanagern zählen. Kopierter Quellcode und eingebettete Binärbibliotheken fehlen in manifestbasierten Analysen und brauchen eine eigene Erkennung.
Ein Release verfolgen.
- Komponentenliste aus einem echten Build erzeugen und exportieren.
- Neue CVE einer verwendeten Bibliothek einem Release zuordnen.
- Betroffenheit, Ausnahme oder Korrektur mit Owner dokumentieren.
- Lizenz- und Security-Policy im Build kontrolliert durchsetzen.
SCA verbindet SAST, Container Security, SBOM/VEX und das Vulnerability Management. Die Produktperspektive unterscheidet sich vom reinen IT-Betrieb.
Security Tool Navigator · Gebiet 07
Im Gebiet Application und Product Security einordnen.
Diese Werkzeugklasse gehört zum Gebiet Application und Product Security. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.