Speichersicherheit ist jetzt eine Frage der nationalen Sicherheit – warum die USA und die EU Entwickler auffordern, C nicht mehr zu schreiben

Im Februar 2024 veröffentlichte die US-amerikanische Cybersecurity and Infrastructure Security Agency einen 19-seitigen Bericht mit dem Titel „The Case for Memory Safe Roadmaps“. Das Büro des National Cyber Director im Weißen Haus legte einen technischen Bericht nach, in dem Softwarehersteller aufgefordert wurden, Speichersicherheitslücken zu beseitigen. Das britische National Cyber Security Centre, das deutsche BSI und das australische Signals Directorate unterstützten dies gemeinsam. Die Botschaft aller fünf Behörden war identisch: Stellt die Entwicklung sicherheitskritischer Software in C und C++ ein.

Dies ist keine Nischenposition von Akademikern, die Haskell bevorzugen. Es handelt sich um die koordinierte Sicherheitspolitik der wichtigsten Geheimdienst- und Cybersicherheitsbehörden der Welt, gestützt auf zwei Jahrzehnte Schwachstellendaten – und sie beginnt bereits zu verändern, welche Software tatsächlich ausgeliefert wird.

Was Speichersicherheit bedeutet

Speichersicherheit ist die Eigenschaft, dass ein Programm nicht auf Speicher außerhalb der vorgesehenen Grenzen zugreifen, freigegebenen Speicher lesen oder nicht initialisierte Werte verwenden kann. Sprachen setzen Speichersicherheit entweder durch Garbage Collection (Java, Python, Go) oder durch statische Besitzregeln durch, die zur Compile-Zeit erzwungen werden (Rust). C und C++ bieten beides nicht: Der Programmierer ist für die korrekte Speicherverwaltung verantwortlich, und der Compiler prüft die Korrektheit nicht.

Die Folge ist eine Klasse von Fehlern, die seit der Erschaffung von C im Jahr 1972 besteht: Pufferüberläufe, Use-after-free-Schwachstellen, Nullpointer-Dereferenzen, Heap-Korruption und Typverwirrung. Dies sind keine exotischen Randfälle – sie sind die am häufigsten ausgenutzte Schwachstellenklasse in der Praxis und machen durchgängig 60–70 % der kritischen CVEs in großen Softwareprojekten aus.

Das Microsoft Security Response Center berichtete 2019, dass etwa 70 % aller CVEs in Microsoft-Produkten der letzten 12 Jahre auf Speichersicherheitsprobleme zurückzuführen waren. Google Project Zero meldete 2020, dass 67 % der schwerwiegenden Chrome-Fehler speichersicherheitsbedingt waren. Beide Zahlen blieben bis 2026 trotz erheblicher Investitionen in Tools (Fuzzing, Sanitizer, statische Analyse) hartnäckig stabil – weil das zugrundeliegende Problem das Sprachmodell selbst ist, nicht die mangelnde Qualität der Programmierer, die es verwenden.

Das Ausmaß des geerbten Problems

Die Schwere der aktuellen Situation ergibt sich daraus, wie viel kritische Infrastruktur auf C-Code läuft. Der Linux-Kernel – die Grundlage der meisten Server, Android-Geräte, IoT-Hardware und eingebetteten Systeme – besteht zu etwa 97 % aus C. Die OpenSSL-Bibliothek, die den größten Teil des HTTPS-Datenverkehrs sichert, ist C. SQLite, die am weitesten verbreitete Datenbank der Welt, ist C. Die V8-JavaScript-Engine, die die Hälfte des weltweiten Web-Browsings ausführt, ist C++. Die Kernel von Windows, macOS und iOS enthalten mehrere Dutzend Millionen Zeilen C und C++.

Eine Neuschreibung eines dieser Systeme ist kein Mehr-Monats-Projekt. Der Linux-Kernel umfasst etwa 30 Millionen Codezeilen mit Mitwirkenden aus Tausenden von Organisationen und einem Änderungsprozess, der sich absichtlich in geologischen Zeiträumen bewegt. Die Google-Chrome-Codebasis umfasst 40 Millionen Zeilen. Die Frage „Warum nicht einfach in Rust neu schreiben?“ verkennt den Maßstab: Bei einer Neuschreibungsrate von 1 Million Zeilen pro Jahr und Team dauert eine vollständige Neuschreibung Jahrzehnte und führt bei jedem Schritt neue Fehler ein.

Der praktische Ansatz ist die schrittweise Ersetzung: Schreibt zuerst die Komponenten mit dem höchsten Risiko neu (Parsing, Netzwerkeingabeverarbeitung, Kryptographie), nutzt Sprachinteroperabilität, um Rust-Module neben C auszuführen, und akzeptiert, dass die Legacy-C-Unterlage 20–30 Jahre bestehen bleibt, während sie zunehmend isoliert wird.

Rusts Entwicklung

Rust, ursprünglich 2015 von Mozilla veröffentlicht, ist die primär verwendete speichersichere Systemsprache für diesen Übergang. Sein Ownership-und-Borrowing-Typsystem verhindert die gesamte Klasse von Speichersicherheitsfehlern zur Compile-Zeit, ohne Garbage-Collection-Overhead und mit nahezu C-Leistung. Der Nachteil ist eine steile Lernkurve: Rusts Compiler lehnt Code ab, den ein C-Compiler akzeptieren würde, weil der Rust-Compiler eine Korrektheit nachweist, die C dem Programmierer überlässt.

Die Einführungskurve ist nun steil genug, um einen strukturellen Wandel darzustellen. Google hat wesentliche Teile von Androids Bluetooth- und WiFi-Stacks in Rust neu geschrieben; das Android-Team berichtete 2024, dass neuer Code in speichersicheren Sprachen die Speichersicherheits-CVE-Rate für diese Komponenten auf nahezu Null gesenkt hat, während Legacy-C-Komponenten ihre historische Schwachstellenrate beibehielten. Der Linux-Kernel hat Rust 2022 formell als zweite Implementierungssprache akzeptiert, und die ersten Rust-Treiber wurden in den Hauptkernel integriert.

Das Windows-Team von Microsoft schreibt Komponenten des Windows-Kernels in Rust um, mit dem langfristigen Ziel, neue Speichersicherheitsfehler aus der Kernel-Codebasis fernzuhalten. Die NSA-Leitlinie von 2022 nannte ausdrücklich Rust, Swift, Go, Kotlin und Java als bevorzugte Sprachen für Neuentwicklungen im Kontext nationaler Sicherheit. Das EU-Cyber-Resilience-Gesetz, das 2025 in Kraft trat, verlangt von Herstellern von Produkten mit digitalen Elementen den Nachweis von „Secure by Design“-Praktiken – eine rechtliche Formulierung, die implizit speicherunsichere Sprachen in sicherheitskritischen Kontexten benachteiligt.

Was „speichersicher“ nicht löst

Der politische Vorstoß für speichersichere Sprachen ist gut belegt, wird aber manchmal überverkauft. Speichersicherheit verhindert eine bestimmte Fehlerklasse – aber keine Logikfehler, Authentifizierungsfehler, Injection-Schwachstellen oder kryptografische Implementierungsfehler. Ein Rust-Programm kann genauso leicht eine SQL-Injection-Schwachstelle aufweisen wie ein C-Programm. Ein Go-Programm kann einen Geschäftslogikfehler haben, der eine Privilegieneskalation ermöglicht. Speichersicherheit ist eine notwendige Bedingung für Sicherheit, aber keine hinreichende.

Es gibt auch einen bedeutenden Unterschied zwischen „safe“ und „unsafe“ Rust. Die Rust-Standardbibliothek enthält unsafe-Blöcke – Abschnitte, in denen der Programmierer die Ownership-Prüfungen für leistungskritischen Code explizit deaktiviert. Diese unsicheren Bereiche müssen manuell überprüft werden, und Schwachstellen in ihnen sind möglich. Die Race-Condition CVE-2022-21658 in Rusts Standardbibliothek existierte beispielsweise in einer sorgfältig überprüften std::fs-Implementierung. Rust macht unsicheren Code selten und hochsichtbar, beseitigt ihn aber nicht.

Das Leistungsargument gegen speichersichere Sprachen wurde empirisch weitgehend entkräftet. Bei den meisten Arbeitslasten liegt Rust innerhalb von 5–15 % der Leistung äquivalenten C-Codes und übertrifft C in einigen Benchmarks, weil der Compiler aggressiver optimieren kann, wenn er bewiesene Aliasing- und Lifetime-Garantien hat. Der verbleibende Overhead tritt hauptsächlich in pathologischen Fällen auf, nicht in der Art von Systemcode, der Netzwerkpakete, Dateisystemoperationen oder Protokollparsing verarbeitet.

Die nächsten zehn Jahre

Der Druck der Regierungen zeigt messbare Wirkung. CISA's Secure-by-Design-Initiative, gestartet 2023, hat Zusagen von über 200 großen Softwareanbietern gesammelt, Memory-Safe-Roadmaps zu erstellen – konkrete Pläne zur Migration bestimmter Codebasen weg von C und C++ mit einem veröffentlichten Zeitplan. Die ersten jährlichen Fortschrittsberichte dieser Anbieter zeigten bescheidene, aber reale Bewegungen: neue Module in Rust, veraltete unsichere APIs, Migration von Parsing-Komponenten mit höchstem Risiko.

Der realistische Zeitrahmen für eine spürbare Reduzierung von Speichersicherheitsschwachstellen in der kritischen Infrastruktur beträgt 15–20 Jahre. Der Code, der heute in Rust geschrieben wird, wird jahrzehntelang in Produktion sein; der noch laufende Legacy-C-Code wird über einen ähnlichen Zeitraum die Quelle kritischer Schwachstellen sein. Die politische Frage ist nicht, ob dieser Übergang vollzogen werden soll – die Beweislage ist überwältigend, dass C und C++ in großem Maßstab ein inakzeptables Sicherheitsrisiko darstellen – sondern wie aggressiv der Übergang vorangetrieben werden soll, angesichts der Engineering-Kosten und der Risiken neuer Defekte während der Migration.

Was sich geändert hat, ist, dass dies nun eine politische Frage ist, keine akademische. Wenn CISA etwas als nationale Sicherheitsfrage bezeichnet und das Weiße Haus einen technischen Bericht unterzeichnet, folgen Beschaffungsanforderungen und regulatorische Leitlinien. Die Dynamik hinter der Einführung speichersicherer Sprachen wird nicht mehr nur von der Entwicklerpräferenz getrieben – sie wird in Regierungsverträge, EU-Produkthaftungsregeln und Versicherungsanforderungen kodifiziert. C und C++ werden noch Jahrzehnte in Gebrauch bleiben, aber ihre Position als Standardwahl für neue sicherheitskritische Systeme ist vorbei.