Sicherheit ist mehr als nur ein Wert CVE-Bewertungen unter die Lupe genommen

Anbieter zum Thema

JFrog

FTAPI Software GmbH

Um Schwachstellen und Risiken von Software-Lieferketten effektiv und effizient beheben zu können, müssen sie zunächst eingehend bewertet werden. Das Problem: CVE-Standards und CVSS-Werte allein genügen nicht, die tatsächliche Risikolage abzubilden.

Allein im vergangenen Jahr wurden weltweit mehr als 33.000 neue Common Vulnerabilities and Exposures (CVEs) gemeldet und registriert. Ein Anstieg von sage und schreibe 27 Prozent im Vergleich zum Vorjahr. Softwarepakete hatten im gleichen Zeitraum nur einen Anstieg von 24,5 Prozent zu verzeichnen. Auf den ersten Blick erscheint die Risikolage im Software-Bereich damit dramatisch. Doch liegt den Zahlen ein unzureichendes Bewertungssystem zugrunde. Laut JFrogs aktuellem „Software Supply Chain State of the Union 2025 Report“ stellen derzeit lediglich zwölf Prozent aller als kritisch (CVSS 9.0 bis CVSS 10.0) eingestuften Software-Supply-Chain-Schwachstellen tatsächlich ein konkretes Sicherheitsrisiko dar.

Software Supply Chain State of the Union 2025

Blinde Flecken in der Software-Lieferkette

Ressourcen an der falschen Stelle

Von staatlichen Stellen, wie der Cybersecurity and Infrastructure Security Agency (CISA) oder der National Vulnerability Database (NVD), wird dem CVE-Standard und seinem Common Vulnerability Scoring System (CVSS) regelmäßig eine hohe – eine zu hohe – Bedeutung zugesprochen. Die Folge: Registrierte CVEs und CVSSs erwecken den Eindruck von Dringlichkeit. DevSecOps-Teams werden dazu verleitet, rasch – zu rasch – zu handeln. Unnötige, vorschnelle Patches, die Verschwendung der eigenen begrenzten Ressourcen und im schlimmsten Fall die Vernachlässigung der tatsächlich vorhandenen Risiken sind die Folge. Sie werden dazu gedrängt, zu reagieren, ohne zuvor den tatsächlichen, aktuellen Risikokontext einer Schwachstelle erfasst und bewertet zu haben.

JFrog hat CVE-Bewertungen untersucht und dabei ein bedenkliches Muster festgestellt: Ermittelte CVEs werden oft mit zu hohen CVSS-Werten versehen; obwohl für sie keine bekannten Exploits existieren, obwohl sie auf Systeme mit minimalem Verbreitungsgrad abzielen, obwohl sie nur unter speziellen Bedingungen aktivierbar sind. Die Diskrepanz zwischen hoher CVE-Bewertung und niedrigen real vorhandenen Risiken kann dann leicht dazu führen, dass DevSecOps-Teams ihre begrenzten Ressourcen an der falschen Stelle zum Einsatz bringen.

Priorisierung von Schwachstellen

Sicherheitslücken nur mit CVSS bewerten reicht nicht!

Sicherheit von Software-Lieferketten in Deutschland

Für Deutschland zeichnet der JFrog-Report ein widersprüchliches Bild: Das allgemeine Problembewusstsein in Bezug auf die Sicherheit von Software-Lieferketten ist gewachsen. Gleichzeitig scheitern viele Unternehmen aber nach wie vor an der konsequenten Umsetzung der erforderlichen Maßnahmen.

• So schützen laut dem JFrog-Report nur 88 Prozent der deutschen Unternehmen ihren Code gegen die Bedrohung versehentlich offengelegter Zugangsdaten.

• Zwölf Prozent verfügen über keinerlei Schutzmechanismen im Fall von geleakten Zugangsdaten.

• Noch kritischer: 48 Prozent verzichten auf Sicherheitsscans während der Laufzeit, was in produktiven Umgebungen ein erhebliches Risiko darstellt.

• Und 58 Prozent nutzen mehr als zehn Programmiersprachen gleichzeitig. Eine Komplexität, die mit erheblichen Abhängigkeits- und Integrationsrisiken einhergeht.

Positiv fällt auf, dass 38 Prozent der befragten deutschen IT-Entscheider den Zugriff auf öffentliche Repositories bereits aktiv einschränken – ein Wert, der deutlich über dem globalen Durchschnitt liegt und zeigt, dass das diesbezügliche Risikobewusstsein hierzulande durchaus vorhanden ist. Dennoch: 41 Prozent haben nach eigenen Angaben keinen klaren Überblick darüber, welche Software in ihrer produktiven Umgebung zum Einsatz kommt und woher diese stammt. Wirklich umfassende Transparenz sieht anders aus.

SBOM, CI/CD-Pipeline & mehr

7 Maßnahmen für sichere Software-Lieferketten

Wie 'falsche' CVE-Bewertungen entstehen

Die meisten CVEs erhalten ihre CVSS-Scores anhand theoretischer Modelle, die den aktuellen, realen Risikokontext – wie die konkreten Angriffsvektoren oder die Exploit-Verfügbarkeit – nicht mit einbeziehen. Es mangelt an einer kontinuierlichen Neubewertung der Schwachstellen und Risiken in der Software-Lieferkette – gestützt auf aktuelle Ausnutzungsversuche, Threat-Intelligence-Daten sowie branchenspezifische Gefährdungslagen. Zudem fällt das „Signal-to-Noise“-Verhältnis bei CVEs eher negativ aus: Inmitten unzähliger Alarmmeldungen verlieren DevSecOps-Teams die Möglichkeit, sich auf jene Schwachstellen zu konzentrieren, die gerade tatsächlich im Fokus der Angreifer stehen.

Sollen Schwachstellen und Risiken effektiv bewertet werden, ist deshalb ein Paradigmenwechsel erforderlich: Weg von einer quantitativen, möglichst umfassenden Übersicht über sämtliche Risiken, hin zu einer qualitativen, fundierten Bewertung sämtlicher aktuell relevanter Schwachstellen. Genau hier setzen moderne Plattformen, wie JFrog, an. Auf Basis einer eigenen Telemetrie, von Crowdsourcing-Analysen und ML-gestützten Kontextdaten geben sie eine realistische Einschätzung zu den aktuellen Schwachstellen und Risiken von Software-Lieferketten.

Ergänzung oder Alternative zur CVE-Datenbank?

Neue EU-Datenbank für Sicherheitslücken geht an den Start

Handlungsempfehlungen für CISOs und DevSecOps-Teams

Der JFrog-Bericht empfiehlt CISOS und DevSecOps-Teams fünf Maßnahmen, um die eigenen Software-Lieferketten resilienter zu gestalten:

• 1. Risikokontext in die Bewertung integrieren: Unternehmen sollten ein mehrstufiges Bewertungssystem einführen, das Schwachstellen in ihrem realen und aktuellen Risikokontext bewertet. Statt blind CVSS-Scores zu folgen, sollten Priorisierungen bei der Behebung von Schwachstellen und Risiken auf Grundlage ihrer Ausnutzbarkeit, Reichweite und Relevanz erfolgen.

• 2. Binär-Scans implementieren: Mittlerweile entziehen sich viele Schwachstellen einer Erkennung auf Code-Ebene. Auf Binärebene dagegen treten sie klar zutage. Aus diesem Grund sollten Binär-Scans in CI/CD-Pipelines implementiert werden.

• 3. SBOMs und Herkunftsnachweise nutzen: Umfassende Transparenz entlang der gesamten Software-Lieferkette ist ein wesentlicher Baustein für deren Sicherheit. Nur wer jederzeit nachvollziehen kann, welche Komponenten im Einsatz sind und woher sie stammen, kann bei Vorfällen schnell reagieren.

• 4. Sicherheitstools konsolidieren: Oft führt eine Vielzahl an im Einsatz befindlichen Sicherheitslösungen zu einer unkoordinierten Datenlage. Integrierte Plattformen mit einem einheitlichen Risikomodell bieten einen besseren Überblick und einen deutlich geringeren Verwaltungsaufwand.

• 5. Automatisierungen ausbauen: Manuelle Prozesse führen oft zu Inkonsistenzen und Fehlern. Eine KI-gestützte Automatisierung hilft sicherzustellen, dass Security-Richtlinien durchgängig und fortlaufend umgesetzt werden – etwa im Umgang mit ML-Modellen, wo die Risikolage im Hinblick auf bösartige Artefakte besonders hoch ist.

„Shift-Left“ in der Cybersecurity

Wie DevSecOps Sicherheit in die Softwareentwicklung integriert

Fazit

Um Schwachstellen und Risiken von Software-Lieferketten effektiv und effizient beheben zu können, müssen sie zunächst eingehend bewertet werden. Die reine Betrachtung von CVEs und CVSS-Werten greift zu kurz. Schwachstellen und Risiken müssen fortlaufend unter Berücksichtigung ihrer realen Auswirkungen bewertet werden. Nur so lässt sich effektiv ermitteln, an welchen Stellen DevSecOps-Teams ihre begrenzten Ressourcen bestmöglich zum Einsatz bringen können. Das CVE-System kann hierbei durchaus gute Dienste leisten. Man sollte es aber auch nicht überbewerten und sich allein darauf verlassen. Dafür ist der Sicherheitsbereich Software Supply Chain mittlerweile einfach zu wichtig geworden.

Über den Autor: Jonathan Sar Shalom ist Director of Threat Research bei JFrog.

(ID:50458757)