Supply-Chain-Risiken reduzieren – mit SBOM-basiertem Dependency Scanning

Drittanbieter-Code prägt die meisten Codebasen, und vier aktuelle Supply-Chain-Vorfälle zeigen, wie ein einzelnes kompromittiertes Paket in jeden abhängigen Projekt Folgen haben kann. KI verschärft dieses Problem: Forschungsergebnisse legen nahe, dass fast die Hälfte von KI-generiertem Code Schwachstellen enthält.

Traditionelle Dependency-Scanner, einschließlich des GitLab-Gemnasium-Analyzers, wurden entwickelt, um eine Frage zu beantworten: Welche der deklarierten Pakete haben bekannte CVEs? Als Abhängigkeitsbäume noch nicht so tief und Release-Zyklen noch nicht so schnell waren, funktionierte dieser Ansatz.

Heutige Application-Security-Teams müssen schwierigere Fragen beantworten: Wie ist ein verwundbares Paket ins Projekt gelangt? Was kam mit ihm? Und welche Abhängigkeiten erreicht der eigene Code tatsächlich? Mit GitLab 19.0 wird Dependency Scanning auf Basis einer Software Bill of Materials (SBOM) allgemein verfügbar, um diese Fragen zu beantworten. Das Feature inventarisiert jede direkte und transitive Abhängigkeit im Projekt und zeigt, welche verwundbaren Pakete die Anwendung tatsächlich verwendet.

Wie GitLab verwundbare Abhängigkeiten aufdeckt

SBOM-basiertes Dependency Scanning ist ein schlanker Analyzer, der Schwachstellen in Drittanbieter-Bibliotheken und -Paketen erkennt. Er katalogisiert Abhängigkeiten in einem SBOM und gleicht diese Komponenten mit der GitLab Advisory Database ab, um bekannte Probleme zu markieren.

GitLab zeigt Findings dort, wo Entwicklungsteams arbeiten. Die durch eine Änderung eingeführten Schwachstellen erscheinen im Merge Request, damit Fixes vor dem Ausliefern möglich sind. Findings werden auch in Schwachstellen-Dashboards und -Berichten angezeigt, sodass Security-Teams Ergebnisse aus allen Projekten an einem Ort sehen können.

Dependency-Scanning-Bericht mit Software Bill of Materials

Der Analyzer generiert sowohl ein SBOM im CycloneDX-Format als auch einen Dependency-Scanning-Bericht – maschinenlesbare Ausgaben, die innerhalb von GitLab, für Compliance-Reporting oder in übergreifenden Supply-Chain-Werkzeugen verwendet werden können.

Was SBOM-basiertes Dependency Scanning ermöglicht

SBOM-basiertes Dependency Scanning führt Fähigkeiten ein, die über den Gemnasium-basierten Analyzer hinausgehen:

Transitive Abhängigkeiten bis zur Quelle zurückverfolgen. Der Analyzer verfolgt transitive Abhängigkeiten, egal wie tief verschachtelt. Wenn ein verwundbares Paket markiert wird, zeigt er die Kette, über die es ins Projekt gelangt ist. Wenn library-a von library-b abhängt, das seinerseits von dem verwundbaren library-c abhängt, lässt sich dieser Pfad nachverfolgen und der richtige Eingriffspunkt identifizieren.

Auf Schwachstellen fokussieren, die der eigene Code tatsächlich verwendet. Nicht jede in Manifest- und Build-Dateien enthaltene Abhängigkeit läuft in der Anwendung. Für Java-, JavaScript/TypeScript- und Python-Projekte prüft der Analyzer, ob der Code verwundbare Pakete direkt importiert oder einbindet – und unterscheidet damit erreichbare Abhängigkeiten von solchen, die transitiv hereingezogen, aber nie von der Anwendung referenziert werden. GitLab zeigt den Erreichbarkeitsstatus bei jedem Finding, damit Teams Schwachstellen in Paketen, die der Code nie importiert, nachrangig behandeln und den Behebungsaufwand dort konzentrieren können, wo tatsächliche Exposition plausibel ist.

Kontinuierlich auf neue Schwachstellen scannen. Den Analyzer bei der Veröffentlichung neuer Advisories sowie für jeden MR und Pipeline-Lauf aufrufen. Das ist besonders relevant für Projekte, bei denen die aktive Entwicklung nachgelassen hat, der Code aber noch in Produktion läuft.

SBOM-basiertes Dependency Scanning in Aktion

Unterstützte Sprachen und Dateiformate

Dieses Release unterstützt mehr als 24 Paket-Ökosysteme, weitere sind für zukünftige Releases geplant. Die Unterstützung neuer Sprachen und Dateiformate ist jetzt einfacher, weil der Analyzer Lockfiles und Dependency-Graphs direkt parst, statt die Build-Toolchain jedes Paketmanagers nachzubilden.

Wenn kein unterstütztes Lockfile oder Dependency-Graph verfügbar ist, fällt der Analyzer auf das Parsen von Manifest-Dateien wie pom.xml, requirements.txt und Gradle-Build-Dateien zurück. Damit werden direkte Abhängigkeiten, aber keine transitiven erkannt – die Abdeckung ist damit weniger vollständig als bei einem Lockfile-basierten Scan. Lockfiles bleiben der empfohlene Ansatz, aber das Manifest-Parsing gibt Teams einen Einstiegspunkt für Projekte, die noch kein Lockfile haben.

Dependency Scanning einmal konfigurieren, überall durchsetzen

Mit wachsender Projektzahl wird die manuelle Konfiguration von Scannern über jedes Projekt hinweg zur erheblichen operationellen Last. Projekte werden übergangen, Konfigurationen driften auseinander, und Audits fördern Lücken zutage, von denen niemand wusste.

GitLab 19.0 liefert ein Security-Configuration-Profile für Dependency Scanning. Security- und Platform-Teams konfigurieren das Scanning einmalig und wenden es auf Hunderte von Projekten an, statt jede Pipeline von Hand zu bearbeiten.

Mit Scan Execution Policies und Pipeline Execution Policies lassen sich diese Sicherheitsstandards verbindlich machen. Sie ermöglichen die Durchsetzung von Dependency Scanning über mehrere Projekte hinweg, ohne eine einzige .gitlab-ci.yml-Datei anzufassen. Die Anforderung einmal auf Group- oder Instanz-Ebene definiert – und die Richtlinie gilt überall automatisch.

Jetzt starten

SBOM-basiertes Dependency Scanning ist für GitLab-Ultimate-Kunden verfügbar. Das Feature ist auf GitLab.com aktiv und wird für GitLab Dedicated und selbstverwaltete Kunden im regulären Release-Rhythmus ausgerollt.

Teams, die vom Gemnasium-Dependency-Scanner migrieren, können beide Analyzer während der Umstellung parallel betreiben. Der Migrationsleitfaden führt durch den Wechsel, einschließlich des Ergebnisvergleichs zwischen beiden.

Für einen Neustart steht das Setup-Tutorial mit Schritt-für-Schritt-Anleitung zur Verfügung. Die technische Dokumentation deckt Konfiguration, unterstützte Sprachen und erweiterte Optionen ab.

Wünsche und Ideen zum Dependency Scanning bitte im Feedback-Epic teilen.

Weitere Informationen zu GitLab 19.0

• CI/CD-Credentials mit GitLab Secrets Manager verwalten
• MRs von manuellen Aufgaben zu automatisierten Workflows transformieren
• CI-Komponentennutzung in der Organisation nachverfolgen
• Mehr KI-Modelle für GitLab Duo Agent Platform Self-Hosted
• Vollständige Security-Scanner-Abdeckung der Codebase in Minuten