Red Hat Product Security Risk Report 2024: CVEs, XZ Backdoor, SSCAs, KI und weitere Themen!

Nehmen Sie sich einen großen Eistee oder eine Tasse Kaffee und lesen Sie den Product Security Risk Report 2024 von Red Hat Product Security. Als jemand, der sich stets über das Open Source-Ökosystem und seine Sicherheitsherausforderungen auf dem Laufenden hält, empfand ich den diesjährigen Bericht als merklich länger, aber die Tiefe und Detailtreue enttäuschten nicht. Eine bemerkenswerte Ergänzung des diesjährigen Berichts ist die Diskussion über das Thema KI. 

Zahlenspiel: Hoch, hoch, höher .... und was dann?

Sehen wir uns zunächst die reinen Zahlen an. Red Hat Security Advisories (RHSA) erreichte 2024 mit 2975 einen neuen Höchststand. In den letzten Jahren war ein stetiger Anstieg zu verzeichnen. Interessanterweise ist festzustellen, dass, während Meldungen der Kategorien 'Wichtig' und 'Moderat' einen deutlichen Anstieg verzeichneten, die 'Kritischen' Meldungen hingegen leicht zurückgingen, was auf proaktivere Sicherheitspraktiken und eine schnellere Erkennung hindeutet.

Die Zahl der Common Vulnerabilities and Exposures (CVEs) stieg auf 4.272 an, was einen bedeutenden Anstieg gegenüber den relativ stabilen Vorjahren darstellt. Was hat dies verursacht? Der Bericht hebt hervor, dass die Linux Kernel Organization im Februar 2024 zur CVE Numbering Authority (CNA) wurde. Sie begann, zahlreichen Kernel-Problemen CVEs zuzuweisen, von denen viele zuvor keine Zuweisungen erhalten hätten. Wenn man diese neuen kernel.org CVEs herausfiltert, erscheint die Trendlinie vertrauter, mit einem leichten Anstieg, der wahrscheinlich das wachsende Portfolio von Red Hat widerspiegelt, aber nichts Besorgniserregendes darstellt. 

Bei genauerer Betrachtung sind die meisten neuen Kernel-CVEs als 'Moderat' und 'Gering' eingestuft, und nur 45 % der von kernel.org im Jahr 2024 zugewiesenen CVEs betrafen aktuelle Red Hat Enterprise Linux (RHEL)-Kernel. Darüber hinaus sollte der Fokus weiterhin auf jenen 'Kritischen' und 'Wichtigen' Schwachstellen liegen, bei denen tatsächliche Ausnutzungsversuche beobachtet werden. Dieser Ansatz wird durch die schnelle Reaktion von Red Hat bei mehr als der Hälfte der 'Kritischen' CVEs bestätigt, indem die ersten Fixes innerhalb von maximal 7 Tagen und 3 Fixes noch am Tag 0 bereitgestellt wurden.

Ohne den oben beschriebenen Kontext könnte man sich bei der Betrachtung dieser Kennzahlen fragen: Was macht Red Hat eigentlich? Die reine CVE-Zahl stieg deutlich an, aber das zugrunde liegende Risikoprofil für Red Hat Produkte änderte sich nicht parallel dazu. Diese Zahlen bestätigen, dass es nicht ausreicht, sich allein auf die CVE-Zahlen zu verlassen. Sie müssen auch Schweregrad, Ausnutzbarkeit und Relevanz berücksichtigen. Der Fokus von Red Hat auf das Patching 'Kritischer' und 'Wichtiger' Probleme wird durch die Daten validiert, was belegt, dass hier die meisten realen Ausnutzungsversuche stattfinden. Dies beweist, dass ein risikobasierter Ansatz am sinnvollsten ist.

XZ Backdoor: Der Elefant im Raum

Wer kann im Jahr 2024 über Sicherheit sprechen, ohne den XZ Backdoor-Vorfall zu erwähnen? Es war ein gut durchdachter Angriff auf die Lieferkette, der die Open Source Community immer noch beschäftigt. Ein vertrauenswürdiger Betreuer, der über 2 Jahre damit verbracht hat, eine Beziehung in der Community aufzubauen, führte eine ausgereifte Backdoor in die XZ library ein. Hätte Andres Freund die verursachte Leistungsverzögerung nicht bemerkt, hätte dies den Secure Shell (SSH)-Zugriff auf zahllosen Systemen kompromittieren können.

In diesem Bericht beschäftigt sich Red Hat mit der Reaktion der Open Source Community. Gleichzeitig nimmt sich Red Hat Zeit, die inhärenten Risiken hervorzuheben und die Stärken des Open Source-Modells herauszustellen. Diese schnelle, gemeinsame Analyse und der Informationsaustausch waren möglich, weil der Quellcode und die Interaktionen öffentlich zugänglich waren. Der Bericht erörtert auch die Hindernisse innerhalb der eigenen Pipeline, wie Fedora-Tests und RHEL Quality Engineering, die das Problem hätten erkennen können, auch wenn sich das nicht mit Sicherheit sagen lässt.  

Der XZ Backdoor-Vorfall war ein Weckruf. Dieser Vorfall wird langfristige Auswirkungen auf das Vertrauen und die Beitragsprozesse in Open Source haben. Die Zahl der Angriffe auf die Lieferkette nimmt stetig zu. Die Angreifer suchen nach Wegen, gängige Tools und gemeinsam genutzten Code, den Entwicklungsteams täglich verwenden, anzugreifen, in der Hoffnung, weitreichende Probleme zu verursachen. Diese Art von Angriffen zeigt, dass Softwareanbieter mehrere Schutzschichten benötigen: eine automatische Überprüfung der Sicherheit der verwendeten vorgefertigten Codeteile, sichere Prozesse zur Softwareerstellung und eine sorgfältige Prüfung neuer Teile, bevor sie hinzugefügt werden. Es ist gut zu wissen, dass bei Red Hat mehrere Kontrollstufen vorhanden waren, die das jüngste XZ-Sicherheitsproblem hätten erkennen und auch erkannt hätten, was unterstreicht, dass diese Sicherheitsebenen tatsächlich helfen. Sicherheit wird niemals eine einmalige Aufgabe sein.

Probleme mit der Lieferkette

Die steigende Anzahl von SSCAs (Software Supply Chain Attacks) und die Abhängigkeit von Open Source-Komponenten ist fast unglaublich und doch statistisch wahr. Die Analyse von Black Duck zeichnet ein beunruhigendes Bild: Ein erstaunlicher Anteil von 97 % der kommerziellen Codebasen basiert auf Open Source-Komponenten. Dies erhöht zwar das Tempo von Innovation und Entwicklung, stellt aber auch ein äußerst verlockendes Ziel für böswillige Akteure dar und Daten belegen, dass diese keine Chance auslassen. Die Nachverfolgung von öffentlich gemeldeten SSCAs durch Red Hat ergab 89 Vorfälle im Jahr 2024, was einem deutlichen Anstieg von 68 % im Vergleich zum Vorjahr entspricht. Der Bericht von Sonatype spiegelt diesen beunruhigenden Trend wider. Software-Lieferketten geraten zunehmend unter Beschuss.

Die XZ Util-Kompromittierung und Bedrohungsakteure aus Nordkorea, die ausgeklügelte Beschäftigungsbetrugsmaschen nutzten, um Insider-Zugang zu erlangen, waren nur 2 Beispiele für die sich entwickelnden Taktiken böswilliger Akteure. Das Problem dabei ist, dass bei den meisten dieser Angriffe das Motiv weitgehend unbekannt ist und ein Großteil unbeansprucht bleibt. Eine effektive Verteidigung ist schwierig, wenn Sie nicht genau wissen, wer angreift und warum. Wir wissen, dass einige Angreifer Geld verdienen oder ausspionieren möchten, aber wir kennen das Ziel vieler Angriffe nicht. Dies macht die gesamte Situation mit Cyberbedrohungen kompliziert und ist schwer vorherzusagen oder zu modellieren. Die gezielte Nutzung von Entwicklern und ihren Zugangspunkten macht aus der Perspektive eines Angreifers durchaus Sinn, da sie Schlüsselfunktionen im Unternehmen innehaben. Gleichzeitig bedeutet dies jedoch auch, dass das menschliche Element beim Aufbau unserer digitalen Welt ein Hauptanngriffspunkt darstellt.

Diese SSCAs demonstrieren die zunehmende Ausnutzung kritischer Open Source-Abhängigkeiten durch erfahrene, anonyme Angreifer. Wir können nicht einfach aufhören, Open Source zu verwenden, da es die Grundlage moderner Software bildet. Deshalb müssen wir einen grundlegenden Wandel vollziehen. Wir brauchen proaktivere Sicherheitsprotokolle, die in den gesamten Entwicklungszyklus integriert sind, nicht nur, wenn wir auf Sicherheitsverletzungen reagieren. Dazu gehören eine bessere Überprüfung von Abhängigkeiten, robuste Sicherheitspraktiken für Entwickelnde und, wie die XZ-Antwort zeigt, ein Modell der gemeinsamen Verantwortung, bei dem Anbieter, Communities und Nutzende in die Sicherung des Ökosystems investieren. Allein das Ausmaß unserer Abhängigkeit erfordert eine entsprechende Investition in die Sicherheit. Wir spielen immer noch ein Aufholspiel gegenüber Gegnern, die offensichtlich mehrere Schritte voraus sind.

Eine Ode an die KI

Falls Sie es noch nicht mitbekommen haben: Im letzten Jahr ist die generative KI (gen KI) geradezu explodiert – von Chatbots über Programmierassistenten bis hin zu kreativen Tools. Die Dynamik lässt nicht nach; generative KI wird bis 2030 voraussichtlich jährlich um 37 % wachsen. Das ist, gelinde gesagt, umwerfend. 

Aber wie bei jeder neuen Technologie gibt es eine anfängliche Euphorie, in der sich alle auf ihr Potenzial konzentrieren. Wie schnell kann sie arbeiten? Wie viel kann sie leisten? Wie könnte sie unsere Arbeitsweise und praktisch alles verändern?

Doch jetzt, da wir den wahren Wert erkennen, vor allem in stark regulierten Branchen wie Gesundheits- und Finanzwesen sowie Behörden, in denen Fehler schwerwiegende Folgen haben können, müssen wir uns mit den ernsten Fragen befassen. Wie sorgen wir dafür, dass die KI-Nutzung sicher, geschützt und vertrauenswürdig ist? Können wir darauf vertrauen, dass sie keine Fehler macht oder private Informationen preisgibt? Entscheidungsträger geben an, dass der Datenschutz bereits die größte Sorge im Zusammenhang mit KI in diesem Jahr darstellt. Das macht absolut Sinn. Sie möchten doch auch verhindern, dass Ihre persönlichen Daten an die Öffentlichkeit gelangen oder dass eine KI falsche Entscheidungen trifft, weil sie nicht sicher entwickelt wurde. Wie Sie oben gelesen haben, gibt es im Open Source-Bereich bereits einige öffentlichkeitswirksamen Vorfälle. 

Ich finde es großartig, dass wir nicht einfach auf den KI-Zug aufspringen, sondern aktiv daran arbeiten, KI sicher und zuverlässig zu gestalten. Aber das ist keine leichte Aufgabe. 

Einer der ersten Punkte, auf die Red Hat im Bericht „Building Trust: Foundations of Security, Safety and Transparency in AI“ hinweist, ist die Notwendigkeit, eine KI-Sicherheitslücke von einem KI-Sicherheitsproblem zu trennen:

• Sicherheitslücke: Ein Hacker findet einen Weg, in das KI-System einzudringen.
• Sicherheitsproblem: Die KI selbst sagt etwas Ungenaues, Voreingenommenes oder sogar Schädliches, selbst wenn sie niemand „geknackt“ hat.

Diese Probleme müssen unterschiedlich angegangen werden, denn die Behebung eines Fehlers ist nicht dasselbe wie der KI beizubringen, nicht toxisch zu sein oder sich Dinge auszudenken. Sie brauchen unterschiedliche Regelwerke.

Es ist beruhigend zu sehen, dass Unternehmen wie Red Hat, Regierungen wie die EU und die USA und verschiedene Branchenverbände hart daran arbeiten, dies herauszufinden. Sie versuchen, Richtlinien, Standards und Methoden zu erstellen, um diese verschiedenen KI-Risiken nachzuverfolgen. Sie bemühen sich, diese Technologie von Grund auf verantwortungsvoll zu entwickeln, ihre Engineering-Teams zu schulen und sichere Designs zu erstellen. Das Wichtigste ist, dass Red Hat nicht nur redet, sondern auch handelt.

Was hat das alles zu bedeuten? Der KI-Boom ist aufregend und könnte viele Dinge verändern. Letztendlich kommt es jedoch auf Vertrauen an. Wie bei jeder guten Beziehung ist Vertrauen die Grundlage. Unsere Beziehung zu KI muss auf Vertrauen aufgebaut sein, damit wir sie in vollem Umfang nutzen können – und das geht über bloße Demos hinaus. Vertrauen entsteht durch harte Arbeit im Hintergrund, um sicherzustellen, dass die Technologie sicher, geschützt und erwartungsgemäß funktioniert. Es hört sich so an, als würden sich die richtigen Leute darauf konzentrieren. Das sind gute Nachrichten. Wir müssen jetzt vorsichtig sein und Rahmenbedingungen schaffen, anstatt zu versuchen, riesige Probleme später zu beheben. Dazu brauchen wir Menschen, die der KI vertrauen.  

Hinter den Kulissen: Das SDLC-Engagement

Im Jahr 2024 hat Red Hat bewiesen, dass hinter jedem zuverlässigen Produkt ein großer Aufwand betrieben wird, um sicherzustellen, dass nichts übersehen wird. Unser Ansatz geht über die bloße Einhaltung der NIST-Sicherheitsstandards hinaus.  Red Hat entwickelt seine eigenen, besonderen Methoden, um zu überprüfen, dass alles, was wir entwickeln, einschließlich KI-Technologien, von Anfang an zuverlässig und vertrauenswürdig ist.

Der Red Hat Secure Software Development Lifecycle (RHSDLC), der unseren Plan zur Entwicklung von sicherheitsorientierter Software darstellt, ist jetzt intelligenter und noch besser auf die aktuellen Sicherheitsherausforderungen der Praxis ausgerichtet. Dabei geht es nicht nur darum, die Vorgaben zu erfüllen. Wir erstellen unsere eigenen Standards wie den RHSDLC, um mithilfe des ausgereiften SOA-Verfahrens (Security Operating Approvals) sicherzustellen, dass die Softwarelieferkette von Anfang bis Ende sicherheitsgehärtet ist. Dazu gehören das Verifizieren von Drittanbieter-Tools, das Automatisieren von Prüfungen und das Erkennen von Risiken, bevor sie zu Problemen werden. Es ist, als würden Sie ein Leck beheben, solange es noch tropft, anstatt auf eine Überschwemmung zu warten. Wir möchten das Vertrauen der Kunden in unsere Produkte stärken, indem wir Sicherheitsdetails eingehend untersuchen und dabei Vertrauen, Transparenz und Resilienz priorisieren.

Ich begrüße es sehr, dass die Security Architecture Reviews (SARs) im RHSDLC standardisiert wurden. Diese Überprüfungen unterstützen die klassischen, praxiserprobten Sicherheitsprinzipien, wie „Zugriff nur auf das absolut Notwendige“, „Verteidigung mehrschichtig gestalten“ und stellen sicher, dass Sicherheit von Anfang an in das Produktdesign integriert wird. 

Und schließlich wäre da noch RapiDAST. Wenn Sie sich für Open Source oder Anwendungsentwicklung interessieren, ist dieses Tool ein Geheimtipp. Es ist das dynamische Testtool für die Anwendungssicherheit von Red Hat und hat 2024 einige wichtige Upgrades erhalten. RapiDAST ist nicht nur leistungsstärker, sondern auch einfacher zu verwenden. Es bietet beispielsweise Unterstützung für Kubernetes Operator-Tests, eine verbesserte Automatisierung und eine wesentlich einfachere Benutzeroberfläche. Die Ergebnisse können jetzt direkt in Google Cloud Storage exportiert werden, was die Zusammenarbeit effizienter macht.

Red Hat integriert all dies direkt in unsere CI/CD-Pipelines, also in dieselben Systeme, die Entwickelnde täglich zum Erstellen und Freigeben von Produkten verwenden. Und für diejenigen, die auf Tools angewiesen sind – egal, ob Entwickelnde, IT-Fachkräfte oder Endnutzende, die Systeme sicher halten möchten – ist ein Engagement für sicherheitsorientierte Entwicklung unerlässlich. In einer Welt ständiger Cyberbedrohungen ist es beruhigend zu wissen, dass der eigene Softwareanbieter sich intensiv auf Sicherheit konzentriert, und zwar von der Designphase über Tests bis hin zur Nachverfolgung der Komponenten. Für Red Hat ist Sicherheit ein zentraler Bestandteil der Qualität, nicht nur eine Nebensache.

Ausblick auf 2025

Der diesjährige Bericht ist eine Erinnerung daran, dass Sicherheit sich ständig verändert. Angesichts der sich ändernden Art und Weise, wie CVEs gemeldet werden, laufender Risiken in der Lieferkette, des zunehmenden Einflusses von KI und der Priorisierung von Schwachstellen – müssen Nutzende vieles berücksichtigen.

Transparente Berichte wie dieser sind sehr wichtig. Solche transparenten Berichte helfen uns allen – von Entwicklungsteams über IT-Teams bis hin zu interessierten Lesenden wie mir – zu sehen, was passiert, die Herausforderungen zu verstehen und fundiertere Entscheidungen zu treffen. Aus meiner Sicht gilt:  es geht nicht nur darum, Probleme zu vermeiden; wie wir auf sie reagieren, ist ebenso entscheidend. Die Art und Weise, wie die Open Source Community bei Vorfällen wie der XZ Backdoor zusammenkam, ist ein Beispiel für die Stärke der Zusammenarbeit in der Praxis!

Lesen Sie den vollständigen Red Hat Product Security Risk Report 2024.