[l] Google ist zufrieden mit ihrer Safe-Coding-Strategie. Schön für sie, und eigentlich keiner Erwähnung wert, aber ein-zwei Stellen in dem Artikel lassen bei mir die Post-Hoc-Alarmglocken bimmeln.
Im aktuellen Bericht zu seiner Safe-Coding-Strategie hebt das Unternehmen hervor, dass der Anteil der Sicherheitslücken durch Speicherprobleme stark von der verwendeten Programmiersprache abhängt.
No shit, Sherlock!
Bei Android machten diese 2019 noch 76 Prozent aller Schwachstellen aus, sind aber bis 2024 auf 24 Prozent gesunken – deutlich unter dem Branchendurchschnitt von 70 Prozent.
Der Anteil des gefährlichen Codes in nicht speichersicheren Programmiersprachen ist nur marginal gewachsen seit dem. Das kann also eigentlich gar nicht sein, und wenn dann kann man daraus nichts dergleichen schließen.
Schließlich setzen Entwicklungsteams noch auf proaktive Maßnahmen, zum Beispiel per Fuzzing oder Code-Analyse, was jedoch meist nur die Symptome von Schwachstellen lindert.
Das stimmt nicht. Die schließen echte Schwachstellen. Das Problem ist eher, dass man nicht sicher sein kann, dass es alle Schwachstellen geschlossen hat, und dass man auch seine Prozesse umbauen muss, damit man keine neuen Schwachstellen einbaut. Das macht halt niemand. Lieber einmal im Jahr einen völlig wertlosen Pentest als Security-Theater veranstalten.
Den Teams bei Google war bekannt, dass die meisten Schwachstellen in neuem oder kürzlich geändertem Code auftreten.
Das deckt sich überhaupt nicht mit meinen Erfahrungen, und es ergibt auch inhaltlich keinen Sinn. Man würde es nicht erwarten, denn Entwickler heute haben von Security gehört, die von früher nicht unbedingt. Wir haben heute Prozesse und Tools, die Entwicklern helfen. Das ergibt keinen Sinn.
In meiner Erfahrung bei Kunden ist es umgekehrt. Der neue Code ist halbwegs OK, der alte Code stinkt drei Meilen gegen den Wind. Häufig sagen Kunden dann auch noch: Der alte Code ist out of scope. Von dem wissen wir ja, dass er Scheiße ist.
Wenn Google jetzt also nur Bugs in neuem Code findet, dann liegt das aller Wahrscheinlichkeit nach daran, dass sie den alten nicht mehr rigoros durchsuchen.
Studien legen zudem nahe, dass von nur rund drei Prozent aller Probleme auch ein kritisches Risiko ausgeht.
Wenn es nach mir ginge, würden Leute, die solche Theorien verbreiten, direkt aus dem Verkehr gezogen. Kritisch ist bei Security wohldefiniert und heißt: Ist über das Netz ohne Authentisierung ausnutzbar. Bugs nach Login oder ohne Netzwerk können natürlich genau so viel Schaden anrichten und müssen auch umgehend gefixt werden.
Fehler werden bereits in der Entwicklungsphase gefunden, was die Korrektheit des Codes verbessert. Als Beispiel nennt Google, dass Rust im Android-Team weniger als halb so viele Rollbacks wie C++ erfordert.
Das kann auch heißen, dass Rust-Code nur halb so oft überhaupt fertig wird, weil die Entwickler am Borrow-Checker scheitern :-)
Statt alten unsicheren Code komplett neu zu schreiben, setzt Google mit Safe Coding auf Interoperabilität, um speichersichere Sprachen wie Rust einzubinden. Das schütze bestehende Investitionen und erlaubt es, neue Funktionen schneller zu entwickeln.
Aller Erfahrung nach ist das Wunschdenken. Die Idee bei Rust ist ja gerade, dass Entwickeln länger dauert und aufwendiger ist, aber dafür der Compiler diverse Bugs schon während des Übersetzens verhindert. Dass die jetzt plötzlich mit Rust schneller entwickeln können wollen, kann also eigentlich nicht sein. Außer sie machen cherrypicking oder sie machen nur Trivialscheiß in Rust oder jemand hat sich die Zahlen aus dem Arsch gezogen.
#fefebot #noshitsherlock #google
