Der Fehler, der nicht mehr neu entsteht: Speichersicherheit und die Mathematik der Schwachstellen-Halbwertszeit

Der Aufhänger: Dreimal unabhängig gemessen, dreimal dieselbe Zahl

Es gibt in der Softwaresicherheit nicht viele Zahlen, die man mehrfach unabhängig voneinander messen kann und bei denen dann annähernd dasselbe herauskommt. Diese hier ist eine davon.

Microsoft triagiert seit 2004 jede gemeldete Sicherheitslücke in eigenen Produkten. Das Ergebnis, 2019 im MSRC-Blog veröffentlicht: Rund 70 Prozent der Schwachstellen, denen Microsoft jedes Jahr eine CVE-Nummer zuweist, sind Speichersicherheitsprobleme.

Das Chromium-Projekt zählt separat, in einer völlig anderen Codebasis, mit eigenem Meldeprozess. Das Ergebnis: Rund 70 Prozent der schwerwiegenden Sicherheitsfehler sind Speichersicherheitsprobleme. Die Grundlage ist explizit angegeben – 912 Fehler der Stufen „high" oder „critical" seit 2015, die den Stable-Kanal betrafen. Die Hälfte davon sind Use-after-free-Fehler.

Googles Project Zero zählt noch etwas anderes: nicht gemeldete Schwachstellen, sondern solche, die nachweislich aktiv angegriffen wurden. Für das Jahr 2021 dokumentierte Maddie Stone 58 in freier Wildbahn beobachtete Zero-Days. Davon waren 39 – also 67 Prozent – Speicherkorruptionsfehler.

Drei Organisationen, drei Zählweisen, drei Zeiträume, drei Datenquellen. Rund zwei Drittel bis 70 Prozent. Der gemeinsame Bericht von CISA, NSA, FBI und den Cyber-Behörden Australiens, Kanadas, Großbritanniens und Neuseelands vom Dezember 2023 fasst es in seinem Fazit so zusammen, dass auch heute noch zwei Drittel der gemeldeten Schwachstellen in speicherunsicheren Programmiersprachen mit Speicherproblemen zu tun haben.

Was diesen Artikel lohnend macht, ist nicht diese Zahl. Sie ist seit Jahren bekannt und wird in jedem zweiten Konferenzvortrag zitiert. Interessant ist die Frage, die darunter liegt und die seit etwa 2024 eine empirisch überprüfbare Antwort hat: Wenn 70 Prozent der Fehler aus einer Fehlerklasse kommen, die eine Sprachwahl ausschließen kann – warum ist dann der Rückgang, den man erwarten würde, drei Jahrzehnte lang ausgeblieben? Und was hat sich geändert, dass er jetzt eintritt?

Die Antwort hat die Form einer Rechnung, nicht einer Technologie. Und sie ist kontraintuitiv genug, dass sie in der Praxis regelmäßig in die falsche Handlungsempfehlung übersetzt wird – nämlich in „wir müssen alles neu schreiben", was genau das Gegenteil dessen ist, was aus den Daten folgt.

Teil 1: Was „Speichersicherheit" technisch bedeutet

Die Fehlerklasse

Speichersicherheit ist kein Gefühl und keine Qualitätsstufe, sondern eine klar umgrenzte Eigenschaft: Ein Programm ist speichersicher, wenn es nicht auf Speicher zugreifen kann, auf den es nicht zugreifen darf. Verletzt werden kann das auf zwei Achsen.

Räumlich (spatial): Der Zugriff liegt außerhalb der Grenzen des Objekts, das gemeint war. Buffer Overflow beim Schreiben, Out-of-bounds-Read beim Lesen. Der klassische Fall: ein Array der Länge 16, ein Index 17, und dahinter liegt etwas anderes im Speicher.

Zeitlich (temporal): Der Zugriff liegt außerhalb der Lebensdauer des Objekts. Use-after-free – ein Zeiger wird benutzt, nachdem der Speicher freigegeben wurde. Double-free. Dangling Pointer auf eine Stack-Variable, deren Funktion längst zurückgekehrt ist.

Dazu kommen Nebenwirkungen, die formal eigene Klassen sind, aber praktisch im selben Topf landen: Integer-Overflows, die anschließend eine Längenberechnung verfälschen, nicht initialisierter Speicher, dessen Inhalt nach außen gelangt, und Datenrennen zwischen Threads, bei denen zwei Schreibzugriffe sich überlappen.

Die Schwere dieser Klasse ist der eigentliche Punkt. Ein Speicherfehler ist selten „nur ein Absturz". Er ist eine Primitive: eine Fähigkeit, die ein Angreifer zu etwas Größerem zusammensetzt. Ein kontrollierter Schreibzugriff an eine Adresse der Wahl führt über mehrere Zwischenschritte zur Kontrolle über den Kontrollfluss und damit zur Codeausführung. Deshalb ist die Verteilung über Schweregrade nicht gleichmäßig. Googles Android-Team hat das für 2022 beziffert: Speichersicherheitsfehler machten in jenem Jahr 35 Prozent aller Android-Schwachstellen aus (der Beitrag nennt an einer Stelle 36 Prozent) – aber 86 Prozent der Schwachstellen mit der höchsten Einstufung „critical" und 89 Prozent der aus der Ferne ausnutzbaren. Über die Jahre davor entfielen 78 Prozent der bestätigten, tatsächlich in freier Wildbahn ausgenutzten Android-Schwachstellen auf diese Klasse.

Das ist die Asymmetrie, die alles weitere trägt: Eine Fehlerklasse, die ein Drittel der Meldungen ausmacht, stellt fast neun Zehntel der gefährlichen Fälle.

Warum C und C++ sie zulassen

Nicht aus Nachlässigkeit, sondern konstruktionsbedingt. Beide Sprachen geben dem Programmierer die Adressarithmetik in die Hand und verzichten im Gegenzug auf Laufzeitprüfungen, die Rechenzeit kosten würden. Ein Zeiger in C ist eine Zahl; die Sprache weiß nicht, wie groß das Objekt dahinter ist oder ob es noch existiert. Dieses Wissen existiert nur im Kopf des Entwicklers und in der Dokumentation. Wo es dort fehlerhaft ist, schweigt der Compiler.

Der CISA-Bericht nennt C und C++ ausdrücklich als Beispiele speicherunsicherer Sprachen und weist im selben Satz darauf hin, dass sie weiterhin zu den am weitesten verbreiteten Sprachen überhaupt gehören. Das ist das ganze Dilemma in einem Satz: Die Fehlerklasse sitzt dort, wo die Infrastruktur liegt.

Was speichersichere Sprachen garantieren – und wie

Der Anhang des CISA-Berichts listet C#, Go, Java, Python, Rust und Swift. Die Mechanismen unterscheiden sich fundamental, und der Unterschied ist für die Praxis wichtiger als die Liste.

Laufzeitprüfung plus Garbage Collection (C#, Java, Go, Python): Jeder Array-Zugriff wird gegen die Länge geprüft, und die Lebensdauer von Objekten verwaltet nicht der Entwickler, sondern die Laufzeitumgebung. Use-after-free ist strukturell unmöglich, weil nichts freigegeben wird, solange eine Referenz existiert. Der Preis ist Laufzeit und – wichtiger – Vorhersagbarkeit. Der CISA-Bericht formuliert das präzise: Garbage Collection kann unvorhersehbare Latenz einführen, die das Performanceverhalten der Anwendung beeinflusst; auf moderner Hardware sei der Effekt vernachlässigbar, bei eingeschränkten Geräten wie eingebetteten Systemen aber nicht.

Prüfung zur Übersetzungszeit (Rust): Ein Typsystem mit Eigentumsbegriff (ownership) und ein „Borrow Checker" stellen sicher, dass zu jedem Zeitpunkt entweder ein schreibender oder beliebig viele lesende Zugriffe auf ein Objekt existieren, und dass kein Zugriff die Lebensdauer des Objekts überlebt. Das kostet keine Laufzeit, sondern Kompilierzeit und Umdenken. Der CISA-Bericht beschreibt den Borrow Checker als nicht perfekt, aber als Mechanismus, der Speichersicherheitsprobleme zur Übersetzungszeit weitgehend adressiert.

Für die Einordnung des Rust-Versprechens lohnt ein Blick auf das, was formal bewiesen ist – und was nicht. Ralf Jung, Jacques-Henri Jourdan, Robbert Krebbers und Derek Dreyer legten 2018 auf der POPL mit RustBelt: Securing the Foundations of the Rust Programming Language den ersten formalen, maschinengeprüften Sicherheitsbeweis vor. Die Formulierung in der Zusammenfassung ist sorgfältig: Es handelt sich um einen Beweis für eine Sprache, die eine realistische Teilmenge von Rust darstellt – nicht für Rust als Ganzes. Entscheidend ist die zweite Hälfte: Rust erweitert sein Kerntypsystem durch Bibliotheken, die intern unsichere Mittel verwenden; der Beweis ist so angelegt, dass für jede solche Bibliothek eine Verifikationsbedingung angegeben werden kann, deren Erfüllung sie zu einer sicheren Erweiterung macht. Die Autoren haben das für einige der wichtigsten Bibliotheken des Ökosystems durchgeführt – nicht für alle.

Die korrekte Aussage lautet also nicht „Rust ist bewiesen sicher", sondern: Für eine realistische formale Teilmenge von Rust existiert ein maschinengeprüfter Sicherheitsbeweis, und für unsicher implementierte Bibliotheken existiert ein Kriterium, das einzeln nachgewiesen werden muss. Das ist deutlich mehr, als jede andere Systemsprache vorweisen kann, und deutlich weniger als ein Pauschalfreibrief.

Teil 2: Die Zahlen – und was sie tatsächlich zählen

Die drei 70-Prozent-Angaben aus dem Aufhänger werden gern als eine Zahl behandelt. Sie sind es nicht. Sie messen unterschiedliche Grundgesamtheiten, und wer sie zusammenwirft, zieht leicht die falschen Schlüsse.

Drei Dinge fallen daran auf.

Erstens: Die Konvergenz ist bemerkenswert, aber sie ist eine Konvergenz unabhängiger Schätzungen, keine Messung einer Naturkonstante. Niemand hat „70 Prozent der Software weltweit" gemessen. Was gemessen wurde, sind große C/C++-Codebasen mit professionellen Sicherheitsprozessen.

Zweitens: Die Project-Zero-Zahl ist die interessanteste und die unsicherste. Sie zählt nicht Meldungen, sondern tatsächliche Angriffe – also das, was zählt. Stone benennt die Grenze selbst und unmissverständlich: Angreifer teilen nicht mit, welche Zero-Days sie verwenden oder welchen Anteil man in der Erfassung verpasst, weshalb man nie genau wissen wird, welcher Anteil der Zero-Days öffentlich gefunden und offengelegt wird. Die Stichprobe ist zudem klein (58) und hängt an der Melde- und Annotationspraxis der Hersteller.

Drittens, und das ist der für die Praxis wichtigste Punkt: Die Zahl ist ein Anteil, kein Niveau. Ein Anteil kann sinken, weil die Speicherfehler weniger werden – oder weil die übrigen Fehler mehr werden. Wer eine Sicherheitsstrategie auf einen Anteil stützt, muss beide Größen nebeneinander betrachten. Genau das macht Androids Datenreihe so ungewöhnlich wertvoll: Dort liegen beide vor.

Teil 3: Drei Jahrzehnte Mitigation – und das Plateau

Von 1995 bis etwa 2019 war die Antwort der Industrie auf Speicherfehler nicht die Sprache, sondern die Härtung. Stack-Canaries, die einen Überschreibversuch erkennen. Nicht ausführbarer Speicher (NX/DEP), damit injizierte Daten kein Code werden. Adressraum-Randomisierung (ASLR), damit der Angreifer nicht weiß, wohin er zielen muss. Kontrollfluss-Integrität. Gehärtete Allokatoren wie Scudo. Sandboxing, Prozesstrennung, Rechteabgabe.

Diese Maßnahmen funktionieren. Sie erhöhen den Aufwand pro Ausnutzung erheblich, und der CISA-Bericht hält ausdrücklich fest, dass sie weiterhin wertvoll bleiben – besonders in Kombination – um Code zu schützen, der noch nicht oder nicht mehr auf eine speichersichere Sprache umgestellt werden kann.

Nur: Sie senken die Zahl der Fehler nicht. Sie senken die Erfolgsquote pro Fehler. Und weil die Codebasen in derselben Zeit wuchsen, blieb der Anteil der Speicherfehler dort, wo er war – auf dem Plateau von rund 70 Prozent, über zwei Jahrzehnte, quer durch die Industrie. Der MSRC-Beitrag von 2019 formuliert es für Microsoft ungeschminkt: Mit wachsender Codebasis und zunehmender Verwendung von Open-Source-Software werde das Problem nicht besser, sondern schlimmer.

Das ist der Befund, mit dem die Geschichte 2019 beginnt: eine bekannte Fehlerklasse, eine bekannte Gegenmaßnahme, dreißig Jahre Arbeit – und eine flache Linie.

Nebenbei sei angemerkt, dass dieselbe Härtungslogik dort an ihre Grenze stößt, wo die Fehlerquelle unterhalb der Software liegt. Spekulative Ausführung und physikalische Störeffekte im DRAM gehorchen keiner Grenzprüfung; wer das nachlesen will, findet es in Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung und Bits, die von selbst umkippen: Rowhammer und die physikalische Schwachstelle des Arbeitsspeichers.

Teil 4: Das Android-Experiment

Android ist der bisher am besten dokumentierte Großversuch zu der Frage, was passiert, wenn eine große, gewachsene, speicherunsichere Codebasis beginnt, neuen Code in einer speichersicheren Sprache zu schreiben. Das Android-Team begann nach eigener Angabe um 2019 damit, neue Entwicklung vorrangig in speichersichere Sprachen zu verlagern. Seitdem erscheinen die Zahlen regelmäßig.

Die Datenreihe

Die absoluten Zahlen für 2019 und 2022 stammen aus dem Beitrag „Memory Safe Languages in Android 13" (Jeff Vander Stoep, 1. Dezember 2022), die Anteile für 2024 aus „Eliminating Memory Safety Vulnerabilities at the Source" (Jeff Vander Stoep und Alex Rebert, 25. September 2024), der Wert für 2025 aus „Rust in Android: move fast and fix things" (Jeff Vander Stoep, 13. November 2025).

Zwei Einschränkungen, die man mitlesen muss. Der Wert für 2024 ist eine Extrapolation; zum Zeitpunkt der Veröffentlichung lag die Zahl bei 27, hochgerechnet auf 36. Und der Rückgang der absoluten Zahl verlief nicht monoton: In einer Fußnote räumt Google ein, dass 2023 die absolute Zahl leicht anstieg – die Meldungen waren in jenem Jahr ungewöhnlich hoch, was angesichts des Codewachstums im Rahmen lag –, während der Anteil weiter fiel. Wer also sagt, die absolute Zahl sei durchgehend gesunken, sagt etwas, das Google selbst in der Fußnote korrigiert.

Die Rust-Seite der Rechnung

Ende 2022 lagen etwa 1,5 Millionen Zeilen Rust in AOSP, und rund 21 Prozent des gesamten neuen nativen Codes (C/C++/Rust) in Android 13 war Rust – nicht 21 Prozent des neuen Codes insgesamt. Der Befund damals: Bis zu diesem Zeitpunkt war in Androids Rust-Code keine einzige Speichersicherheitsschwachstelle entdeckt worden. Google formulierte im selben Atemzug, man erwarte nicht, dass diese Zahl für immer null bleibe.

Drei Jahre später, im November 2025, liest die Bilanz so: rund fünf Millionen Zeilen Rust in der Android-Plattform und eine potenzielle Speichersicherheitsschwachstelle, gefunden und vor der Freigabe behoben (CVE-2025-48530). Daraus leitet Google eine geschätzte Fehlerdichte von 0,2 Schwachstellen pro Million Codezeilen ab und stellt ihr die historische Dichte des eigenen C- und C++-Codes gegenüber, die näher bei 1.000 pro Million Zeilen liege. Das Verhältnis beschreibt der Beitrag als Reduktion um mehr als den Faktor 1.000.

Diese Zahl ist die meistzitierte und die am stärksten zu relativierende des ganzen Themas, deshalb hier ausdrücklich: Es ist eine Dichteschätzung, bei der der Zähler auf der Rust-Seite aus einem einzigen, als „potenziell" bezeichneten und nie ausgelieferten Fund besteht. Google hedged im Fließtext konsequent („roughly", „potential", „estimated", „closer to") und lässt diese Hedges in der Einleitung des eigenen Beitrags weg. Der Beitrag nennt außerdem keinen Zeitraum für die Zählung und sagt nicht, ob die C/C++-Dichte gefundene oder ausgelieferte Fehler zählt. Die Richtung des Effekts ist durch die Anteilsreihe unabhängig gestützt; die präzise Zahl 1.000 ist es nicht.

Der unerwartete Teil: die Prozesskennzahlen

Was in der Sicherheitsdiskussion untergeht, ist der zweite Datensatz. Nach Angaben des Android-Teams werden Rust-Änderungen mittlerer und großer Größe etwa viermal seltener zurückgerollt als vergleichbare C++-Änderungen; Rust-Änderungen verbringen etwa 25 Prozent weniger Zeit im Code-Review und benötigen bei ähnlicher Größe etwa 20 Prozent weniger Revisionen. Google nennt das selbst „modest productivity gains" und spekuliert, die deutliche Verbesserung zwischen 2023 und 2024 gehe auf gewachsene Rust-Expertise im Team zurück; für die Ursachen insgesamt gibt es keine Gewissheit, nur eine Liste wahrscheinlicher Faktoren.

Die Einleitung desselben Beitrags nennt die vierfach niedrigere Rollback-Rate ohne die Einschränkung auf mittlere und große Änderungen. Wer sie zitiert, sollte die Einschränkung mitnehmen.

Teil 5: Die Mathematik der Halbwertszeit – und wie weit sie trägt

Hier liegt der eigentliche intellektuelle Gehalt des Themas, und hier liegt auch die Stelle, an der die populäre Darstellung über das hinausgeht, was die Quellen hergeben.

Das Modell

Googles Argument von 2024 ist kein Messergebnis, sondern eine Simulation mit anschließendem Realitätsvergleich. Der Aufbau: eine wachsende Codebasis, überwiegend in speicherunsicheren Sprachen, mit konstantem Zustrom neuer Speicherfehler. Nun wird neue Funktionalität allmählich in speichersicheren Sprachen geschrieben, während der bestehende Code bis auf Fehlerkorrekturen unangetastet bleibt. Die Parameter nennt Google in einer Fußnote: Die Codebasis verdoppelt sich alle sechs Jahre, die durchschnittliche Lebensdauer einer Schwachstelle beträgt 2,5 Jahre, der Übergang zu speichersicheren Sprachen für neuen Code dauert zehn Jahre und wird durch eine Sigmoidfunktion modelliert.

Der entscheidende Baustein ist die Annahme, dass Schwachstellen exponentiell zerfallen – dass sie eine Halbwertszeit haben. Daraus folgt alles Weitere fast mechanisch: Wenn der Zustrom neuer Speicherfehler versiegt, sinkt der Bestand nicht linear, sondern exponentiell. Googles eigene Formulierung dazu ist eingängig: Sobald man den Hahn für neue Schwachstellen zudreht, nehmen sie exponentiell ab, und das mache den gesamten Code sicherer – auch in großen bestehenden Systemen. Für die Konsequenz auf der Investitionsseite verwendet der Beitrag die Formel, Interoperabilität sei das neue Neuschreiben („Interoperability is the new rewrite").

Wo das Modell empirisch aufsitzt – und wo nicht

Google beruft sich für die Zerfallsannahme auf eine Arbeit der TU Darmstadt: Nikolaos Alexopoulos, Manuel Brack, Jan Philipp Wagner, Tim Grube und Max Mühlhäuser, How Long Do Vulnerabilities Live in the Code? A Large-Scale Empirical Measurement Study on FOSS Vulnerability Lifetimes, USENIX Security 2022. Die Studie vermisst 5.914 CVEs über elf verbreitete Open-Source-Projekte (darunter Linux-Kernel, Firefox, Chromium, OpenSSL, PHP, FFmpeg, QEMU, PostgreSQL).

Was die Studie findet: Die durchschnittliche Lebensdauer einer Schwachstelle liegt bei etwa vier Jahren, mit starker Streuung zwischen den Projekten – rund zwei Jahre bei Chromium, rund sieben bei OpenSSL. Und: Die Verteilung der Lebensdauern lässt sich näherungsweise durch eine Exponentialverteilung beschreiben. Das ist genau der funktionale Baustein, den das Modell braucht, und er ist damit belastbar belegt.

Was die Studie nicht findet, ist der zweite, populärere Teil der Behauptung. Googles Beitrag stellt die Studie so dar, als hätten die Forscher festgestellt, dass die überwältigende Mehrheit der Schwachstellen in neuem oder kürzlich geändertem Code sitze. Eine solche Aussage enthält die Arbeit nicht. Sie vermisst Lebensdauern – den Abstand zwischen einführendem und behebendem Commit –, nicht die Verteilung von Schwachstellen über Codealtersklassen. Ihre erklärten Forschungsfragen betreffen durchgängig Lebensdauern; eine Aussage über die Fehlerdichte nach Codealter findet sich weder in der Zusammenfassung noch im methodischen Teil der Arbeit. Ihre altersbezogenen Befunde gehen eher in die andere Richtung: Schwachstellen würden älter, weil der Code insgesamt altert, und verwundbarer Code lebe kürzer als nicht verwundbarer Code, was die Autoren als Hinweis auf eine Art Reifung und damit auf Qualität deuten.

Dazu kommt eine Spannung in den Zahlen, die man sehen sollte: Googles Simulation rechnet mit 2,5 Jahren mittlerer Lebensdauer, die zitierte Studie berichtet rund vier Jahre im Mittel. Eine längere Lebensdauer bedeutet im selben Modell einen langsameren Zerfall – das Modell wird also mit einem Parameter betrieben, der günstiger ist als der Wert der Arbeit, auf die es sich für seine Form beruft.

Die Konzentration von Fehlern in neuem Code ist damit nicht widerlegt – sie ist nur anders belegt, als meist behauptet. Google selbst hatte sie 2021 für Android beobachtet: Die Dichte von Androids Speicherfehlern nahm mit dem Alter des Codes ab und saß vor allem in jüngeren Änderungen. Und Google rechnet aus Lebensdauerzahlen eine eigene Kennziffer: Fünf Jahre alter Code habe eine 3,4-fach (mit den Lebensdauern aus der Studie) bis 7,4-fach (mit den in Android und Chromium beobachteten Lebensdauern) geringere Fehlerdichte als neuer Code. Das ist Googles Ableitung, nicht ein Befund der Studie.

Was damit gezeigt ist und was nicht

Nüchtern bilanziert:

Belegt. Die Lebensdauerverteilung von Schwachstellen ist näherungsweise exponentiell (Alexopoulos et al. 2022). Androids Anteil an Speicherfehlern ist von 76 Prozent (2019) auf unter 20 Prozent (2025) gefallen. Die absolute Zahl ist im gleichen Zeitraum deutlich gesunken, mit einem leichten Anstieg 2023. In Androids Rust-Code wurde über fünf Millionen Zeilen hinweg bislang eine potenzielle Speichersicherheitsschwachstelle gefunden.

Modelliert, nicht gemessen. Dass der beobachtete Verlauf kausal aus dem Sprachwechsel folgt. Google formuliert hier selbst vorsichtig: Die Ergebnisse stimmten mit der Simulation überein und seien sogar besser, möglicherweise als Folge der parallelen Anstrengungen, auch den speicherunsicheren Code sicherer zu machen. Zur Rolle der Mitigations heißt es ausdrücklich, man habe in Android keine endgültigen Antworten. Es gibt keine Kontrollgruppe – kein zweites Android, das ohne Sprachwechsel weitergelaufen wäre. Der Schluss ruht auf der Passung zwischen Modell und Verlauf, nicht auf einem isolierten Effekt.

Ich bin der Meinung, dass das für eine Entscheidung reicht. Die Richtung ist durch mehrere unabhängige Datenreihen gestützt, die Mechanik ist plausibel und die Kosten einer Fehlentscheidung sind asymmetrisch: Neuen Code in einer speichersicheren Sprache zu schreiben, kostet auch dann wenig, wenn der Effekt kleiner ausfällt als modelliert. Aber es ist eine begründete Entscheidung unter Unsicherheit, kein Beweis – und wer sie als Beweis verkauft, beschädigt sie.

Teil 6: Die Lecks in der Garantie

Eine Garantie, die man an der falschen Stelle für absolut hält, ist gefährlicher als keine. Vier Stellen, an denen sie ausläuft.

1. Das unsafe-Schlüsselwort

Rust erlaubt es, Codeblöcke als unsafe zu markieren und damit Prüfungen auszusetzen. Der CISA-Bericht hält fest, dass die Speicherschutzgarantien einiger speichersicherer Sprachen damit aushebelbar sind, nennt legitime Gründe dafür – etwa die direkte Interaktion mit dem Betriebssystem – und fügt die Mahnung an, das Schlüsselwort nicht zu verwenden, um Speichersicherheitsprobleme einzuführen.

Die Größenordnung in der Praxis: Googles Beitrag von 2025 benennt die hauptsächliche Sicherheitssorge bei Rust als die rund vier Prozent des Codes innerhalb von unsafe{}-Blöcken. Und fügt eine lesenswerte Rechnung an: Selbst die konservativere Annahme, eine Zeile unsicheres Rust sei genauso fehleranfällig wie eine Zeile C oder C++, überschätze das Risiko unsicheren Rusts nach Googles Daten deutlich. Der Grund ist strukturell: unsafe ist eine durchsuchbare, auditierbare, lokal begrenzte Markierung – in C ist jede Zeile implizit unsafe.

2. Die Sprachgrenze

Das ist das unterschätzte Leck. Eine Mixed-Methods-Studie von Ian McCormack, Tomás Dougan, Sam Estep, Hanan Hibshi, Jonathan Aldrich und Joshua Sunshine (Carnegie Mellon University und weitere; arXiv 2404.02230, v4 vom 18. Februar 2026, DOI 10.1145/3798277) befragte 19 Entwickler in Interviews und erreichte anschließend 160 weitere per Umfrage. Der zentrale Befund: 70 Prozent der Umfrageteilnehmer nutzten unsicheren Code, um fremde Funktionen aufzurufen; die häufigsten Gegensprachen waren C (90 Prozent), C++ (57 Prozent), JavaScript/TypeScript (22 Prozent), Assembly (21 Prozent) und Python (17 Prozent). Die Teilnehmer gaben an, unsicheren Code dann zu verwenden, wenn sie keine Alternative sahen, und ihn ansonsten zu meiden; die begrenzte Werkzeugunterstützung für Fremdfunktionsaufrufe machte sie allerdings unsicher über ihre eigenen Entwurfsentscheidungen. Die Autoren benennen als Verzerrungsrisiko, dass Rekrutierung über Schneeballverfahren und Online-Communities die Ergebnisse in Richtung bestimmter Teile der Rust-Community verzerren kann und engagierte Rust-Experten in der Interviewgruppe überrepräsentiert sein dürften.

Der CISA-Bericht sagt dasselbe aus Systemsicht: Die Speichersicherheitsgarantien speichersicherer Sprachen seien eingeschränkt, wo Daten über solche Grenzen fließen, und speichersichere Sprachen würden mit großer Wahrscheinlichkeit weiterhin auf Bibliotheken in Sprachen wie C und C++ angewiesen sein. Für die absehbare Zukunft würden die meisten Entwickler in einem hybriden Modell aus sicheren und unsicheren Sprachen arbeiten.

Das ist die wichtigste praktische Konsequenz dieses Artikels: Die Sprachgrenze ist der neue Angriffspunkt. Wer „wir sind auf Rust/C#/Go" sagt und darunter eine C-Bibliothek bindet, hat die Fehlerklasse nicht eliminiert, sondern an eine Stelle verschoben, die schlechter überwacht ist – weil die Analysewerkzeuge der sicheren Sprache dort typischerweise nicht hinsehen.

3. Was Speichersicherheit nicht abdeckt

Die verbleibenden 20 bis 30 Prozent verschwinden nicht. Logikfehler, kaputte Zugriffskontrolle, Injektion, fehlerhafte Kryptoverwendung, unsichere Standardkonfigurationen, Verwirrung über Zuständigkeiten in verteilten Systemen – nichts davon berührt eine Sprachwahl. Der CISA-Bericht formuliert es knapp: Speichersichere Sprachen seien nicht frei von anderen potenziellen Schwachstellen kritischer Schwere, und ein Übergang zu ihnen werde Cyberkriminalität oder Spionage nicht von sich aus aufhalten oder abschrecken. Ebenso: Keine einzelne speichersichere Sprache passe auf alle Programmierbedürfnisse.

Und ein Angriff, der die Lieferkette nimmt, interessiert sich für Speichersicherheit gar nicht – der XZ-Fall ist das Lehrstück dazu: Die Hintertür im Herzen von Linux: Der XZ-Backdoor und die Anatomie eines Supply-Chain-Angriffs.

4. Die Betriebsgrenzen

Garbage-Collection-Latenz bei eingeschränkten Geräten wurde oben genannt. Für Betriebstechnik ergänzt der CISA-Bericht, dass jeder Übergang in OT-Systemen einen Nachweis von Performance, Zuverlässigkeit und Echtzeitgarantien erfordern wird.

Teil 7: Der Hardware-Pfad

Wenn Code auf Jahrzehnte hinaus speicherunsicher bleibt, lässt sich die Prüfung auch unter die Sprache schieben. Zwei Ansätze nennt der CISA-Bericht im Abschnitt über künftige Mitigations, und er ordnet das Feld als in aktiver Entwicklung befindlich und vielversprechend ein.

CHERI (Capability Hardware Enhanced RISC Instructions) ist ein gemeinsames Forschungsprojekt von SRI International und der University of Cambridge. Die Projektseite beschreibt den Ansatz so, dass konventionelle Befehlssatzarchitekturen um architekturale Mittel erweitert werden, die feingranularen Speicherschutz und hoch skalierbare Software-Kompartimentierung ermöglichen; das Modell führt architekturale Capabilities ein – hardwaregestützte Beschreibungen von Berechtigungen –, die anstelle ganzzahliger virtueller Adressen verwendet werden, um auf Daten, Code und Objekte zu verweisen. Der erklärte Zweck ist ausdrücklich, historisch speicherunsichere Sprachen wie C und C++ so anpassbar zu machen, dass sie starken, kompatiblen und effizienten Schutz gegen viele der heute verbreitet ausgenutzten Schwachstellen bieten. Arm hat nach Angabe des CISA-Berichts im Januar 2022 den CHERI-fähigen Morello-Prototyp als Prozessor, SoC und Board ausgeliefert; die Entwicklung wird laut Projektseite seit 2019 von UKRI im Rahmen des Programms Digital Security by Design gefördert. Eine Zahl zum Laufzeitaufwand nennt die Projektseite nicht.

ARM MTE (Memory Tagging Extension) markiert Speicherbereiche und Zeiger mit Tags und erkennt Zugriffe, bei denen die Tags nicht zusammenpassen – also typischerweise Use-after-free und Out-of-bounds. Der CISA-Bericht nennt hier eine Aufwandsschätzung von ein bis zwei Prozent und schreibt sie ausdrücklich Arm selbst zu; es handelt sich also um die Angabe des Herstellers, nicht um eine unabhängige Messung.

Der Bericht hält außerdem fest, was gern übersehen wird: Hardwaremerkmale wie MTE würden auch in Systemen gebraucht, die in speichersicheren Sprachen geschrieben sind – Rust-Programmierer könnten Code als unsafe markieren und dort von Hardwarekontrollen profitieren. Hardware und Sprache sind keine Alternativen, sondern greifen genau an der Stelle ineinander, die Teil 6 als Leck identifiziert hat.

Teil 8: Was daraus 2026 folgt

Die Priorisierung – ausdrücklich kein Neuschreiben

Der verbreitetste Fehlschluss aus den Zahlen dieses Artikels ist „also alles neu schreiben". Beide Hauptquellen sagen das Gegenteil.

Google formuliert als Lehre, es sei klar geworden, dass man den bestehenden speicherunsicheren Code nicht wegwerfen oder vollständig neu schreiben müsse – und bietet Interoperabilität als Ersatzstrategie an. Der CISA-Bericht wird operativer und nennt eine Reihenfolge: mit neuen und kleineren Projekten anfangen (Neuschreiben bestehenden Codes sei eine erhebliche Herausforderung, besonders wenn der Code bereits gut funktioniert und die Organisation die gewählte Sprache noch nicht beherrscht); in sich geschlossene unsichere Komponenten ersetzen; sicherheitskritischen Code priorisieren – genannt werden Code, der mit nutzergenerierten Inhalten arbeitet, und Code, der geheime Schlüssel verwaltet, Netzwerkverbindungen öffnet, Authentifizierung und Autorisierung durchführt oder auf tiefen Ebenen wie Firmware arbeitet; und dort, wo eine Umstellung nicht möglich ist, Anwendungen umhüllen, indem für alle öffentlichen Schnittstellen eine Zwischenanwendung in der sicheren Sprache geschrieben wird. Im Fazit nennt der Bericht die Migration sicherheitskritischer Komponenten bestehender Codebasen als Ziel – nicht die Migration aller.

Beides zusammengenommen ergibt eine klare Regel: Neuer Code speichersicher, alter Code nur dort, wo er exponiert und sicherheitskritisch ist, und die Grenze zwischen beidem bewusst entworfen.

Entscheidungsmatrix

Und wenn man längst in einer speichersicheren Sprache arbeitet?

Für jeden, der den Arbeitstag in C#, TypeScript, Python oder Go verbringt, sieht dieses Thema zunächst wie eine fremde Debatte aus. Das ist ein Trugschluss in drei Punkten.

Erstens ist man Konsument dieser Fehlerklasse, auch ohne sie zu produzieren. Betriebssystem, Laufzeitumgebung, Bildbibliotheken, Parser, Treiber, TLS-Stacks – die Angriffsfläche unter der eigenen Anwendung ist weitgehend in C und C++ geschrieben. Das Patch-Tempo für diese Schicht ist eine eigene Betriebsdisziplin und keine Nebensache.

Zweitens liegt das Risiko an der Grenze, und diese Grenze überschreitet man häufiger als gedacht: jedes P/Invoke, jedes native Node-Modul, jedes Python-Rad mit kompilierter Erweiterung, jede ausgelagerte Bildverarbeitung. Dort gilt genau die Garantie nicht, die man von der eigenen Sprache gewohnt ist – und die Werkzeuge der eigenen Sprache prüfen sie dort nicht.

Drittens verschiebt sich damit die eigene Fehlerverteilung. Wer die 70 Prozent strukturell ausgeschlossen hat, dessen Fehler sitzen in den verbleibenden 30 Prozent: Logik, Autorisierung, Zustand, Nebenläufigkeit auf fachlicher Ebene. Das ist keine Entlastung, sondern eine Verlagerung des Prüfschwerpunkts – Code-Review und Testdesign sollten dort hinsehen, wo die Fehler nach dem Sprachwechsel noch sein können, nicht dort, wo sie vor dem Sprachwechsel waren.

Es sei angemerkt, dass der regulatorische Druck in dieselbe Richtung zeigt: Die Pflicht, Produkte ohne bekannte ausnutzbare Schwachstellen auszuliefern und Schwachstellen über den Lebenszyklus zu behandeln, trifft Hersteller unabhängig von ihrer Sprachwahl – siehe Sicherheit ab Werk: Der EU Cyber Resilience Act und das Ende des unsicheren Produkts.

Teil 9: Das übergeordnete Denkprinzip

Der eigentliche Gedanke dieses Themas ist allgemeiner als Speichersicherheit, und er lohnt die Übertragung.

Dreißig Jahre lang bestand die Strategie darin, die Ausnutzbarkeit vorhandener Fehler zu senken. Das ist Arbeit am Bestand, und Arbeit am Bestand skaliert mit dem Bestand – also mit einer wachsenden Größe. Der Wechsel bestand darin, stattdessen die Entstehungsrate zu senken. Das ist Arbeit am Zustrom, und sie skaliert mit der Neuentwicklung, nicht mit dem Altbestand. Weil der Bestand gleichzeitig von selbst zerfällt – Fehler werden gefunden und behoben, Code reift –, arbeitet die Zeit danach für statt gegen einen.

Diese Figur findet man an vielen Stellen wieder, sobald man sie einmal gesehen hat: in jeder technischen Schuld, bei der man aufhört, Symptome zu bekämpfen, und die Quelle abstellt; in der Entscheidung, ein fehlerträchtiges Muster im Linter zu verbieten statt es in Reviews einzeln zu rügen; in jeder Migration, bei der der ehrlichste Plan nicht lautet „alles umstellen", sondern „ab heute nichts Neues mehr im alten Muster". Auch die Kryptomigration, die derzeit vor uns liegt, folgt derselben Logik – mit dem Unterschied, dass dort eine harte Frist von außen kommt: Ernte jetzt, entschlüssle später: Post-Quanten-Kryptographie und das Rennen gegen den Quantencomputer.

Erkenntnis zum Mitnehmen

Vier Punkte, jeder davon so stark formuliert, wie die Quellen ihn tragen:

1. Rund zwei Drittel bis 70 Prozent der schwerwiegenden Schwachstellen in großen C/C++-Codebasen sind Speicherfehler – dreimal unabhängig gemessen (Microsoft, Chromium, Project Zero), jeweils mit eigener Grundgesamtheit. Es ist eine robuste Konvergenz, keine gemessene Konstante.
2. Die wirksamste Maßnahme betrifft neuen Code, nicht alten. Androids Anteil fiel von 76 Prozent (2019) auf unter 20 Prozent (2025), während der Großteil des Codes unsicher blieb. Dass dieser Verlauf kausal aus dem Sprachwechsel folgt, ist durch Modellpassung gestützt, nicht durch einen isolierten Effekt belegt – Google selbst nennt parallele Härtungsarbeiten als möglichen Mitverursacher.
3. Nicht neu schreiben, sondern priorisieren. Google wie CISA empfehlen ausdrücklich keinen Pauschalumbau: neuer Code sicher, bestehender Code nur dort, wo er exponiert und sicherheitskritisch ist, sonst härten und umhüllen.
4. Die Sprachgrenze ist der neue Angriffspunkt. Rund 70 Prozent der befragten Rust-Entwickler nutzen unsafe für Fremdfunktionsaufrufe, zu 90 Prozent nach C; CISA erwartet für die absehbare Zukunft ein hybrides Modell. Die konkrete Handlung daraus: Jedes FFI- und P/Invoke-Grenzstück im eigenen Projekt kennen, benennen und gezielt prüfen – dort gilt die Garantie der eigenen Sprache nicht.

Der kleinste sinnvolle nächste Schritt, wenn man ihn heute tun will: eine Liste der Stellen anlegen, an denen der eigene Code die Sprachgrenze zu nativem Code überschreitet. Nicht um sie zu beseitigen, sondern um zu wissen, wo man eine Garantie hat, die man nicht hat.

Eine Frage zum Nachdenken

Die Industrie hat dreißig Jahre damit verbracht, die Ausnutzbarkeit einer Fehlerklasse zu senken, deren Entstehung sie mit einer Werkzeugentscheidung hätte unterbinden können – und die Daten, die das belegen, lagen die ganze Zeit vor. Welche Fehlerklasse in Ihrer eigenen Arbeit bekämpfen Sie gerade an den Symptomen, weil die Maßnahme am Zustrom unbequem, teuer oder politisch schwierig wäre? Und woran würden Sie merken, dass Sie bereits dreißig Jahre zu lang warten?

Querverweise im Vault

• Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung – die Fehlerklasse, die unterhalb der Sprache sitzt und von keiner Grenzprüfung erfasst wird.
• Bits, die von selbst umkippen: Rowhammer und die physikalische Schwachstelle des Arbeitsspeichers – wenn der Speicher selbst das Problem ist und Speichersicherheit auf Sprachebene nicht hilft.
• Die Hintertür im Herzen von Linux: Der XZ-Backdoor und die Anatomie eines Supply-Chain-Angriffs – der Angriffsweg, dem die Sprachwahl gleichgültig ist.
• Sicherheit ab Werk: Der EU Cyber Resilience Act und das Ende des unsicheren Produkts – der regulatorische Druck in Richtung derselben Entscheidungen.
• Ernte jetzt, entschlüssle später: Post-Quanten-Kryptographie und das Rennen gegen den Quantencomputer – dieselbe Migrationslogik, nur mit harter äußerer Frist.

Faktenprüfung

Geprüft: 31 prüfbare Aussagen, gegliedert in harte Fakten (18), Zitate (3), Quellenzuschreibungen (4) und Synthese-Aussagen (6). Jede Aussage wurde gegen die Primärquelle geprüft, die im Rahmen dieses Durchlaufs selbst aufgerufen wurde. Korrigiert oder abgeschwächt: 7.

Die drei wichtigsten Korrekturen:

1. Die Zuschreibung an die USENIX-Studie war falsch und wurde korrigiert. Der Entwurf übernahm Googles Darstellung, die Arbeit von Alexopoulos et al. (USENIX Security 2022) habe gezeigt, dass die überwältigende Mehrheit der Schwachstellen in neuem oder kürzlich geändertem Code sitzt. Die Arbeit enthält diesen Befund nicht; sie vermisst Lebensdauern, nicht die Verteilung von Schwachstellen nach Codealter. Belegt ist durch sie nur die exponentielle Form der Lebensdauerverteilung. Die Konzentration in neuem Code wird im Artikel jetzt Googles eigener Android-Beobachtung von 2021 und Googles eigener Ableitung (3,4- bis 7,4-fach) zugeschrieben.

2. Die Kausalaussage zum Android-Rückgang wurde abgeschwächt. Aus „der Sprachwechsel hat den Rückgang bewirkt" wurde „der beobachtete Verlauf stimmt mit dem Modell überein, ohne Kontrollgruppe und mit parallelen Härtungsarbeiten als möglichem Mitverursacher" – entsprechend Googles eigener Formulierung, zur Rolle der Mitigations keine endgültigen Antworten zu haben.

3. Die Faktor-1.000-Angabe wurde als Schätzung mit schmaler Basis gekennzeichnet. Sie ruht auf einem einzigen, als „potenziell" bezeichneten und vor Freigabe behobenen Fund auf fünf Millionen Zeilen Rust, ohne angegebenen Zeitraum. Weitere Abschwächungen betrafen den Umfang des RustBelt-Beweises (realistische Teilmenge statt „Rust ist bewiesen sicher"), die vierfach niedrigere Rollback-Rate (nur für mittlere und große Änderungen), die Arm-MTE-Aufwandsangabe von ein bis zwei Prozent (Herstellerangabe, keine unabhängige Messung) und die absolute Android-Zahl (2023 leicht angestiegen, nicht monoton fallend).

Automatisierte KI-Prüfung gegen Primärquellen; keine menschliche Fachprüfung.

Quellen und zum Weiterlesen

1. Jeff Vander Stoep, Rust in Android: move fast and fix things, Google Security Blog / blog.google, 13. November 2025. https://blog.google/security/rust-in-android-move-fast-fix-things/
2. Jeff Vander Stoep und Alex Rebert, Eliminating Memory Safety Vulnerabilities at the Source, Google Online Security Blog, 25. September 2024. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
3. Jeff Vander Stoep, Memory Safe Languages in Android 13, Google Online Security Blog, 1. Dezember 2022. https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
4. CISA, NSA, FBI, ASD's ACSC, CCCS, NCSC-UK, NCSC-NZ, CERT-NZ, The Case for Memory Safe Roadmaps – Why Both C-Suite Executives and Technical Experts Need to Take Memory Safe Coding Seriously, Dezember 2023. https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF
5. Nikolaos Alexopoulos, Manuel Brack, Jan Philipp Wagner, Tim Grube, Max Mühlhäuser, How Long Do Vulnerabilities Live in the Code? A Large-Scale Empirical Measurement Study on FOSS Vulnerability Lifetimes, 31st USENIX Security Symposium (USENIX Security 22), Boston, S. 359–376, August 2022. https://www.usenix.org/conference/usenixsecurity22/presentation/alexopoulos
6. Chromium Security, Memory safety, Chromium-Projektdokumentation. https://www.chromium.org/Home/chromium-security/memory-safety/
7. Gavin Thomas / MSRC Team, A proactive approach to more secure code, Microsoft Security Response Center, 16. Juli 2019. https://www.microsoft.com/en-us/msrc/blog/2019/07/a-proactive-approach-to-more-secure-code
8. Maddie Stone, The More You Know, The More You Know You Don't Know – A Year in Review of 0-days Used In-the-Wild in 2021, Google Project Zero, 19. April 2022. https://projectzero.google/2022/04/the-more-you-know-more-you-know-you.html
9. Ralf Jung, Jacques-Henri Jourdan, Robbert Krebbers, Derek Dreyer, RustBelt: Securing the Foundations of the Rust Programming Language, POPL 2018. https://plv.mpi-sws.org/rustbelt/popl18/
10. Ian McCormack, Tomás Dougan, Sam Estep, Hanan Hibshi, Jonathan Aldrich, Joshua Sunshine, A Mixed Methods Study on the Implications of Unsafe Rust for Interoperation, Encapsulation, and Tooling, arXiv:2404.02230 (v4, 18. Februar 2026), DOI 10.1145/3798277. https://arxiv.org/abs/2404.02230
11. CHERI: Capability Hardware Enhanced RISC Instructions, University of Cambridge Computer Laboratory und SRI International. https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

← All articles