Was ist Software Composition Analysis (SCA) und warum ist sie kritisch?
Kurzantwort
SCA inventarisiert die Open-Source- und Drittanbieter-Komponenten, die eine Anwendung einbindet — einschließlich transitiver Abhängigkeiten — und markiert jene mit bekannten CVEs oder problematischen Lizenzen. Sie ist wichtig, weil der meiste moderne Code aus Abhängigkeiten besteht, die du nicht geschrieben hast, und ein einziges anfälliges transitives Paket (wie Log4j) die gesamte App gefährden kann. Gute SCA priorisiert nach Erreichbarkeit und Ausnutzbarkeit, nicht nur nach reinen CVE-Zahlen.
Moderne Anwendungen bestehen größtenteils aus Code, den jemand anderes geschrieben hat. Software Composition Analysis (SCA) ist die Art und Weise, wie du diesen Code und das Risiko, das er trägt, im Blick behältst.
Was SCA tut
Ein SCA-Tool parst deine Manifeste und Lockfiles (package-lock.json, pom.xml, go.sum usw.), um ein Inventar jeder Open-Source-Komponente aufzubauen, die du auslieferst. Anschließend gleicht es jede Komponente und Version mit Schwachstellendatenbanken (NVD, GitHub Advisories, Vendor-Feeds) ab, um bekannte CVEs zu markieren, und prüft die deklarierten Lizenzen, sodass rechtlich riskante Komponenten (z. B. starkes Copyleft in einem proprietären Produkt) früh auffallen.
Warum sie kritisch ist
Der Hauptgrund sind transitive Abhängigkeiten: die Bibliotheken, von denen deine Bibliotheken abhängen. Du ziehst vielleicht 20 direkte Pakete herein und erbst 800 transitive. Du hast sie nie ausgewählt, prüfst sie selten, und ein Fehler tief in diesem Baum — Log4Shell ist das kanonische Beispiel — kann eine App kompromittieren, deren eigener Code fehlerfrei ist. SCA ist die einzige praktikable Möglichkeit zu wissen, was tatsächlich in deinem Build steckt.
Wie man es gut macht
Reine CVE-Zahlen überwältigen Teams. Reife SCA priorisiert nach Erreichbarkeit (wird die anfällige Funktion tatsächlich aufgerufen?), Ausnutzbarkeit (gibt es einen bekannten Exploit, einen ins Internet exponierten Pfad?) und Schweregrad — nicht nur nach der Anzahl. Sie läuft in der CI, sodass ein neu offengelegtes CVE in einer bestehenden Abhängigkeit den Build brechen lässt, und sie speist die SBOM, sodass du in Minuten "Sind wir betroffen?" beantworten kannst, wenn die nächste große Schwachstelle auftaucht.
Worauf Interviewer achten
Sie wollen, dass du transitive Abhängigkeiten betonst, SCA mit der Geschwindigkeit der Incident Response verknüpfst und zeigst, dass du nach Erreichbarkeit triagieren würdest, statt Entwickler in Rauschen zu ertränken.
Wahrscheinliche Anschlussfragen
- Warum sind transitive Abhängigkeiten der schwierige Teil?
- Wie würdest du Hunderte von SCA-Befunden priorisieren?
- Wie steht SCA zu einer SBOM in Beziehung?