Der Code, den Ihr Team selbst schreibt, ist in den meisten Projekten die Minderheit. 70 bis 90 Prozent einer typischen Anwendung bestehen aus Open-Source-Abhängigkeiten. Wer diese Abhängigkeiten nicht kennt, kennt seine Angriffsfläche nicht. Genau hier setzt Software Composition Analysis an, kurz SCA.
Was SCA konkret macht
SCA-Werkzeuge inventarisieren alle Bibliotheken und Pakete, die in einem Build landen, und gleichen sie gegen bekannte Schwachstellen-Datenbanken ab. Das Ergebnis ist eine Liste: Welche Komponente in welcher Version steckt wo, und welche davon hat eine bekannte Lücke. Dazu kommen Lizenzinformationen, die spätestens bei kommerzieller Auslieferung relevant werden.
Der Unterschied zu klassischem Vulnerability Scanning: SCA schaut nicht auf laufende Systeme, sondern auf den Quellstand. Die Analyse passiert dort, wo die Abhängigkeit entsteht, im Repository und im Build.
Das Problem sind die transitiven Abhängigkeiten
Die package.json oder pom.xml zeigt vielleicht 30 direkte Abhängigkeiten. Aufgelöst sind es schnell 300 bis 1000, weil jedes Paket eigene Abhängigkeiten mitbringt. Log4Shell hat 2021 gezeigt, was das bedeutet: Viele betroffene Teams wussten schlicht nicht, dass Log4j bei ihnen im Einsatz war, weil es als transitive Abhängigkeit hereinkam.
Ohne Werkzeugunterstützung ist diese Tiefe nicht beherrschbar. Ein Lockfile hilft bei der Reproduzierbarkeit, beantwortet aber nicht die Frage, welche der aufgelösten Komponenten verwundbar ist.
Werkzeuge, die den Einstieg leicht machen
Für den Start braucht es kein kommerzielles Produkt. Der Dependency Graph in GitHub plus Dependabot Alerts ist mit wenigen Klicks aktiv. OSV-Scanner von Google prüft Lockfiles gegen die OSV-Datenbank und läuft als CLI oder GitHub Action. Trivy und Grype scannen zusätzlich Container-Images und Dateisysteme. Wer zentral über viele Projekte hinweg auswerten will, nimmt Dependency-Track und füttert es mit SBOMs aus dem Build.
Wichtiger als die Werkzeugwahl ist die Verankerung: Der Scan muss im Pull Request oder im Build laufen, nicht als manueller Quartalslauf. Nur dann erwischt er neue Abhängigkeiten in dem Moment, in dem sie hereinkommen.
Vom Befund zur Entscheidung
Der erste Scan eines gewachsenen Projekts liefert oft hunderte Findings. Wer versucht, alles sofort zu fixen, gibt nach zwei Wochen auf. Sinnvoller ist Priorisierung nach drei Fragen: Ist die Schwachstelle in der Praxis ausnutzbar, etwa laut KEV-Katalog der CISA oder EPSS-Score? Ist die verwundbare Funktion im eigenen Code überhaupt erreichbar? Und gibt es eine gepatchte Version, auf die ein Update ohne Breaking Changes möglich ist?
Aus dieser Priorisierung entsteht ein bearbeitbarer Rest. Alles andere wird dokumentiert und bei Updates mitgenommen. In Kombination mit automatischen Update-Werkzeugen wie Dependabot oder Renovate schrumpft der Bestand kontinuierlich, statt einmal im Jahr in einer Hauruck-Aktion.
SCA und SBOM gehören zusammen
Eine SBOM ist die formale Stückliste, SCA die laufende Prüfung dieser Stückliste gegen neue Schwachstellen. Wer beides koppelt, kann bei der nächsten Log4Shell-Situation in Minuten beantworten, ob und wo eine Komponente im Einsatz ist. Diese Auskunftsfähigkeit ist auch das, was Kunden und Auditoren zunehmend konkret abfragen.
Wissen, was in Ihren Builds steckt
Der GitSecOps QuickCheck prüft Ihre Repositories und Pipelines in 3 Werktagen: Abhängigkeiten, Secrets, Workflow-Härtung, Nachvollziehbarkeit. Sie bekommen einen priorisierten Maßnahmenkatalog statt einer Rohdaten-Liste. Festpreis 1.990 Euro netto. Kontakt: mm@crank.zone.
Dein Blog zum Thema digitales Business 