SCA-Scanning

Was bei einem SCA-Scan passiert

1. Das Ziel lesen. Der Scanner liest Manifeste und Lockfiles wie package-lock.json, poetry.lock oder Cargo.lock, oder er entpackt ein Container-Image.
2. Die Komponentenliste erstellen. Er löst das Gefundene in Namen und Versionen auf, meist einschließlich transitiver Abhängigkeiten.
3. Die Daten abgleichen. Jede Komponente wird in Quellen wie der GitHub Advisory Database, OSV und der NVD nachgeschlagen, und ihre Lizenz wird mit Ihrer Policy verglichen.
4. Berichten. Die Befunde werden nach Schweregrad sortiert ausgegeben, meist mit einer korrigierten Version. Im CI kann eine Policy den Job fehlschlagen lassen.

Die übergeordnete Praxis, zu der das gehört, beschreibt Was ist Software Composition Analysis.

Wo SCA-Scans laufen sollten

Ein Scan an einem Ort lässt Lücken. Jede Stufe beantwortet eine andere Frage, deshalb nutzen die meisten Teams mehr als eine.

Wo	Was er beantwortet	Was er übersieht
Entwicklerrechner oder IDE	Kann dieses Paket sicher hinzugefügt werden?	Alles, wofür der Entwickler ihn nicht startet
Pull Request	Bringt diese Änderung ein bekanntes Risiko mit?	Neue Advisories für Code, der sich nicht geändert hat
CI-Build	Was enthält das Release?	Alles, was der Scanner im Build nicht sehen kann
Container-Registry	Was steckt in diesem Image?	Kompilierten Code und Build-Tools, die keine Spuren hinterlassen
Nach dem Release	Ist das Ausgelieferte von etwas Neuem betroffen?	Nichts, wenn die Aufzeichnung des Ausgelieferten vollständig ist

Die letzte Zeile lassen die meisten Programme aus. Ein neues Advisory betrifft eine Version, die Sie vor Monaten ausgeliefert haben, und kein Pull Request löst dafür einen Scan aus.

So lesen Sie Ergebnisse von SCA-Scans

Der erste Scan eines echten Projekts liefert oft Hunderte Befunde. Arbeiten Sie sie in dieser Reihenfolge ab:

1. Beginnen Sie mit dem, was ausgenutzt wird. Ein Befund im KEV-Katalog von CISA geht vor einem höheren CVSS-Wert ohne bekannte Ausnutzung. Siehe so priorisieren Sie Schwachstellen.
2. Prüfen Sie, ob er zutrifft. Reine Entwicklungsabhängigkeiten werden nicht ausgeliefert. Manche Tools ergänzen eine Erreichbarkeitsanalyse, um zu prüfen, ob der verwundbare Code überhaupt aufgerufen werden kann.
3. Beheben Sie auf der richtigen Ebene. Bei einem transitiven Befund liegt die Lösung meist in dem Paket, das die Abhängigkeit nachzieht; welches das ist, zeigt ein Abhängigkeitsgraph.
4. Halten Sie fest, was Sie nicht beheben. Ein akzeptierter Befund sollte die Begründung nennen, sonst wiederholt die nächste Person die Arbeit. VEX ist der Standardweg, das festzuhalten.

Warum ein sauberer Scan keine saubere Software bedeutet

• Er sieht, was deklariert ist. Ein Scanner liest die Dateien, die vor ihm liegen. Ein Repository ohne eingechecktes Lockfile gibt ihm also wenig Material, und Code, den ein Install-Hook lädt, taucht nie auf.
• Er sieht, worauf Sie ihn richten. Basis-Image, Build-Tools und GitHub Actions in Ihrer Pipeline stehen nicht im Manifest Ihrer Anwendung.
• Er kennt nur, was veröffentlicht ist. Zu einem neuen bösartigen Paket gibt es noch kein Advisory.
• Die Liste ist nicht der Build. Builds lösen Versionen bei der Ausführung auf, daher können das, was der Scan gelesen hat, und das, was das Release enthält, voneinander abweichen.

Das sind Grenzen des Scannens selbst, 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.

Kostenlose und kommerzielle Scanner

Kostenlose Optionen decken die Grundlagen gut ab. Dependabot-Warnungen gehören zu GitHub, OWASP Dependency-Check und Trivy sind Open Source, und Grype arbeitet mit dem SBOM-Generator Syft zusammen. Kommerzielle Tools ergänzen Policy, Priorisierung, Erreichbarkeit und Workflows über viele Teams hinweg. Die besten SCA-Tools im Vergleich behandelt 13 davon, und dieser Leitfaden zeigt, warum kostenlose Generatoren einander widersprechen.

SCA-Scanning und Aufzeichnung zur Build-Zeit

CRACI ist kein Scanner, und Sie müssen Ihren nicht aufgeben. 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 die SBOMs des Ausgelieferten laufend neu bewertet, sobald neue Schwachstellen veröffentlicht werden. Ihr Scanner deckt Pull Requests und Entwicklerrechner ab. CRACI deckt den Build ab und alles, was danach kommt. Siehe wo CRACI neben Ihren SCA-Tools ansetzt.

SCA-Scanning: häufig gestellte Fragen

Was ist ein SCA-Scan?

Ein SCA-Scan liest die Manifeste, Lockfiles oder das Container-Image eines Projekts, ermittelt, welche Open-Source-Komponenten es nutzt, und gleicht sie mit Schwachstellen- und Lizenzdaten ab.

Ist SCA dasselbe wie Dependency Scanning?

Fast. Dependency Scanning meint meist die Prüfung von Abhängigkeiten auf bekannte Schwachstellen. SCA ist der weitere Begriff und umfasst auch Lizenzen, veraltete Pakete und die Erstellung eines Inventars wie einer SBOM.

Wann sollten SCA-Scans laufen?

Bei Pull Requests, um neue Risiken fernzuhalten, im CI-Build, um das Release zu beschreiben, und nach dem Release laufend, weil neue Advisories bereits ausgelieferte Software betreffen.

Wie lange dauert ein SCA-Scan?

Meist Sekunden bis wenige Minuten, weil er Metadaten liest, statt Ihren gesamten Code zu analysieren. Deshalb lässt er sich praktikabel bei jedem Pull Request ausführen.

Warum melden SCA-Scanner unterschiedliche Ergebnisse?

Jeder hat eigene Regeln dafür, was er liest, wie er Komponenten benennt und welche Schwachstellendaten er nutzt. Derselbe Commit kann unterschiedliche Komponentenlisten und unterschiedliche Befunde ergeben.

Findet SCA-Scanning Malware?

Der Abgleich mit Advisories findet bösartige Releases erst, wenn es ein Advisory gibt. Tools, die das Verhalten von Paketen analysieren, können manche früher erkennen. Zu einem neuen bösartigen Paket gibt es am Tag seines Erscheinens kein Advisory.