In den Anfangsjahren von C++ waren Probleme mit der Speichersicherheit – Pufferüberläufe, hängende Zeiger und Use-after-free-Fehler – weithin bekannt wurden jedoch nicht als dringende Schwachstellen betrachtet, die auf Sprachebene behoben werden mussten. Warum?
1. Performance stand über allem
C++ entstand in den 1980er-Jahren als leistungsfähige Weiterentwicklung von C. Die Sprache bot Entwicklern:
- Direkte Kontrolle über den Speicher
- Objektorientierte Programmierung
- Abstraktionen ohne Laufzeitkosten
Diese Kontrolle ermöglichte extrem schnelle Anwendungen. Speicherfehler? Sie galten als Verantwortung des Entwicklers. Die damalige Haltung lautete: „Macht bedeutet Verantwortung – schreiben Sie einfach besseren Code.“ Tatsächlich bietet C++ Entwicklern:
- C++ bietet Entwicklern direkten Zugriff auf den Speicher, manuelle Ressourcenverwaltung, Low-Level-Kontrolle, and präzise Performance-Optimierung.
- Das bedeutet jedoch auch, dass die Sprache Sie nicht an die Hand nimmt. It won’t prevent you from making dangerous mistakes — like buffer overflows, double frees, or dangling pointers.
- So, the Verantwortung is on the Entwickler Code zu schreiben, der korrekt, sicher und effizient ist.
2. Entwickler arbeiteten näher an der Hardware
Damals waren die meisten C++-Entwickler Systemprogrammierer oder arbeiteten sehr hardwarenah. Sie verstanden die Speicherverwaltung im Detail – malloc, Zeiger, Stack und Heap. Sicherheitsnetze wurden weder erwartet noch unbedingt gewünscht.
3. Sicherheit stand nicht im Mittelpunkt
In den 1980er- und 1990er-Jahren hatten Sicherheitsbedrohungen noch nicht die weitreichenden Folgen von heute. Ein Speicherleck oder Pufferüberlauf galt meist als Fehler oder Stabilitätsproblem, not a Einfallstor für die Ausführung von Schadcode aus der Ferne oder für Datendiebstahl.
4. Die nötigen Werkzeuge gab es noch nicht
Statische Analysatoren, Fuzzer und Werkzeuge wie ASan oder Valgrind? Sie existierten entweder noch nicht oder waren äußerst eingeschränkt. Subtile Speicherprobleme frühzeitig zu erkennen war schwierig. Entsprechend wurden sie von den meisten Teams erst spät entdeckt.
Zeitsprung: Warum das heute wichtig ist
Heute steuert Software praktisch alles – Autos, Flugzeuge, Herzschrittmacher und Finanzsysteme. Eine Speicherschwachstelle führt nicht nur zu einem Absturz – sie kann einen Cyberangriff oder einen katastrophalen Ausfall.
Mit dem wachsenden Bewusstsein und Initiativen wie:
- Microsofts Vorstoß für speichersichere Sprachen
- dem Aufstieg von Rust
- Security-Hardening-Flags in GCC und Clang
- Googles Bemühungen rund um Carbon und speichersichere C++-Teilmengen
…wird deutlich, dass die Branche endlich auf ein Risiko reagiert, das seit Jahrzehnten besteht.
Wie geht es weiter?
Die ursprüngliche C++-Philosophie priorisierte Leistungsfähigkeit, Performance und Flexibilität – nicht Sicherheit. Das war für die damalige Zeit sinnvoll. Doch die Welt hat sich verändert. Heute überdenken wir, was „modernes C++“ bedeuten sollte – nicht nur schneller, sondern auch sicherer konzipiert.
Vor Kurzem richtete Bjarne Stroustrup, der Schöpfer von C++, einen Handlungsaufruf an die C++-Community. Anlass ist die zunehmende Kritik von Behörden und führenden Vertretern der Industrie an der Speichersicherheit der Sprache. Dazu gehören Empfehlungen der US-amerikanischen Cybersecurity and Infrastructure Security Agency (CISA) und der National Security Agency (NSA), die Organisationen dazu raten, sich von Sprachen wie C und C++ wegzubewegen und stattdessen speichersichere Alternativen wie Rust, Go und Java einzusetzen.
Die entscheidende Frage ist nun, ob C++ seine Sicherheitsprobleme künftig bereits durch das Sprachdesign lösen wird oder ob Sprachen wie Rust in Bereichen, die traditionell von C++ dominiert werden, weiter an Boden gewinnen.