Sicherheit & Datenschutz

Wandel von CVE-Zählungen zu risikobasierter Schwachstellenverwaltung im KI-Zeitalter

KI beschleunigt die Erstellung von Exploits, wodurch statische Schweregrad-Scores unzureichend werden. Teams müssen Schwachstellen basierend auf der tatsächlichen Produktions-Exposition und Erreichbarkeit priorisieren.

Automatisch aus dem englischen Original übersetzt.

Künstliche Intelligenz verkürzt das Zeitfenster zwischen der Entdeckung einer Schwachstelle und deren aktiver Ausnutzung rapide und erzwingt einen grundlegenden Wandel in der Art und Weise, wie Engineering-Teams Sicherheits-Schulden verwalten. Da das Softwarevolumen zunimmt und die Automatisierung von Angriffen fortschreitet, bietet die traditionelle, tabellenbasierte Verfolgung von Common Vulnerabilities and Exposures (CVEs) kein genaues Bild des organisationalen Risikos mehr.

Was passiert ist

Das traditionelle Modell der Schwachstellenverwaltung hat sich über Jahre hinweg kaum verändert: Code scannen, CVEs identifizieren, Schweregrade über das Common Vulnerability Scoring System (CVSS) zuweisen und die Liste zur Behebung an Entwickler übergeben. Dieser Ansatz ging davon aus, dass die technische Schwere direkt mit dem Geschäftsrisiko korreliert. Die aktuelle Landschaft zeigt jedoch eine wachsende Lücke zwischen der Anzahl der Schwachstellen, die Sicherheitsteams identifizieren können, und der Anzahl, die sie sinnvoll untersuchen und beheben können.

Diese Lücke weitet sich aus, da KI sowohl die Softwareproduktion als auch die Raffinesse von Angriffen beschleunigt. Während die Schwachstellendichte pro Zeile Code möglicherweise sinkt, steigt durch das schiere Volumen der generierten Software die Gesamtexposition. Gleichzeitig nutzen Angreifer KI, um Aufgaben zu automatisieren, die zuvor erheblichen manuellen Aufwand erforderten, und kombinieren Schwachstellen auf unvorhersehbare Weise, um neue Angriffswege zu schaffen. Das Ergebnis ist, dass Organisationen in Daten ertrinken, aber nach Kontext hungern, was dazu führt, dass einige Experten von "CVE-Theater" sprechen, bei dem Teams Aktivität statt tatsächlicher Risikominderung messen.

Das Kernproblem besteht darin, dass eine CVE lediglich anzeigt, dass ein öffentlich bekannter Fehler existiert, aber nicht, ob dieser Fehler in einer spezifischen Umgebung ausnutzbar ist. Zwei Organisationen können dieselbe CVE haben, aber wenn eine Organisation die verwundbare Komponente hinter mehreren Sicherheitsebenen ohne externe Exposition betreibt, während die andere sie in einer internetseitigen Produktionsanwendung laufen lässt, sind ihre Risikoprofile völlig unterschiedlich. Eine Gleichbehandlung verschwendet Engineering-Ressourcen für Risiken mit geringer Priorität, während kritische Expositionen unbehandelt bleiben.

Wie es funktioniert

Um diese Lücke zu schließen, müssen Sicherheitsprogramme von statischen Schweregrad-Bewertungen zu kontextueller, kontinuierlicher Risikobewertung übergehen. Dies beginnt damit, den Fußabdruck der Schwachstellen vor der Bereitstellung zu reduzieren, indem gehärtete Basis-Images und kuratierte Sprachbibliotheken verwendet werden. Eigenentwickelter Code wird durch Static Application Security Testing (SAST) und KI-gestütztes Scannen gesichert, während Konfigurationsschwächen mit Frameworks wie Security Technical Implementation Guides (STIGs) adressiert werden. Diese automatisierten Checklisten identifizieren Probleme wie übermäßige Berechtigungen oder schwache Authentifizierung, die genauso gefährlich sein können wie Code-Schwachstellen.

Entscheidend ist, dass der Fokus auf das Scannen dessen liegt, was tatsächlich in der Produktion läuft, da Registries und Repositories nur wahrgenommene Risiken widerspiegeln. Produktionsumgebungen ändern sich ständig, daher ist kontinuierliche Sichtbarkeit erforderlich. Tools führen Reachability-Analysen durch, um festzustellen, ob ein verwundbarer Codepfad tatsächlich ausgeführt wird und ob das System extern erreichbar ist. Dieser Umweltkontext ermöglicht es Teams, zwischen theoretischen Schwachstellen und solchen zu unterscheiden, die unmittelbare, handlungsrelevante Bedrohungen darstellen.

Schließlich werden die Prioritäten für die Behebung durch die Kombination von Threat-Intelligence-Signalen, wie dem Known Exploited Vulnerabilities-Katalog der CISA und dem Exploit Prediction Scoring System (EPSS), mit Daten zur Produktions-Exposition festgelegt. Dies schafft ein dynamisches Modell, das beantwortet, welche Schwachstelle zuerst, in dieser spezifischen Umgebung und warum behoben werden sollte, anstatt sich auf eine statische Liste zu verlassen, die nach CVSS-Score sortiert ist.

Wichtige Details

  • KI beschleunigt die Entwicklung von Exploits und verkürzt die Zeit zwischen Offenlegung einer Schwachstelle und aktivem Angriff.
  • CVSS-Scores messen die technische Schwere, berücksichtigen aber weder die Umgebungs-Exposition noch die Wahrscheinlichkeit einer Ausnutzung.
  • "CVE-Theater" tritt auf, wenn Teams die Schließung großer Mengen von Befunden priorisieren, ohne das relevante Risiko zu mindern.
  • Produktions-Scanning liefert die Quelle der Wahrheit darüber, was tatsächlich bereitgestellt und ausgeführt wird.
  • Reachability-Analyse bestimmt, ob verwundbare Codepfade ausgeführt werden und ob Systeme extern erreichbar sind.
  • Threat-Intelligence-Quellen wie KEV und EPSS helfen dabei, die Wahrscheinlichkeit einer Ausnutzung innerhalb eines bestimmten Zeitraums einzuschätzen.

Warum es wichtig ist

Für Software-Ingenieure und technische Leads bedeutet dieser Wandel, sich von reaktiver, volumenbasierter Behebung hin zu einem strategischeren, risikobasierten Ansatz zu bewegen. Das alte Modell, Entwicklern eine Tabelle mit Tausenden von CVEs zu übergeben, ist in einer KI-getriebenen Bedrohungslandschaft nicht nachhaltig. Es führt zu Alarm-Müdigkeit und falsch zugewiesenen Ressourcen, bei denen kritische Bugs unter Rauschen begraben werden. Durch den Fokus auf Kontext können Teams die kognitive Belastung für Entwickler reduzieren und sicherstellen, dass Behebungsmaßnahmen auf die Fehler abzielen, die für das Geschäft tatsächlich relevant sind.

Darüber hinaus bringt dieser Ansatz Sicherheitsziele mit der operativen Realität in Einklang. Zu verstehen, welche Türen offen sind, welche ein Angreifer erreichen kann und welche zu kritischen Assets führen, ermöglicht bessere Entscheidungsfindung. Es verwandelt Sicherheit von einem Engpass in einen kontinuierlichen Verbesserungsprozess. Wie Russ Andersson bemerkt: "Wir müssen wissen, welche Türen offen sind, welche ein Angreifer erreichen kann, welche irgendwohin führen, wo es wichtig ist, und welche das größte Risiko im Moment darstellen."

Was Sie tun können

  • Ersetzen Sie die statische, CVSS-basierte Priorisierung durch Risikomodelle, die Produktions-Exposition und Reachability-Daten einbeziehen.
  • Implementieren Sie kontinuierliches Produktions-Scanning, um die Sichtbarkeit darauf zu erhalten, was in Ihrer Umgebung tatsächlich läuft.
  • Verwenden Sie gehärtete Basis-Images und kuratierte Bibliotheken, um den anfänglichen Schwachstellen-Fußabdruck von Anwendungen zu reduzieren.
  • Integrieren Sie Threat-Intelligence-Feeds wie CISA KEV und EPSS, um die Wahrscheinlichkeit einer aktiven Ausnutzung einzuschätzen.
  • Automatisieren Sie Konfigurationsprüfungen unter Verwendung von STIGs, um Sicherheitsschwächen in Einstellungen und Berechtigungen zu identifizieren und zu beheben.
  • Stellen Sie zeitliche Disziplin her, indem Sie unterschiedliche Behebungszeiträume für Schwachstellen basierend auf ihrem realen Risikoniveau definieren.

Tools aus dem Bytechap-Shop

Weiterlesen

Alle Artikel