Mind the Gap

Firefox 150 hat im letzten Monat 271 Schwachstellen gefixt. Die meisten davon hat Anthropics Mythos gefunden, ein KI Modell, das nach Anthropics eigener Aussage gar nicht eigens für Sicherheitsaufgaben trainiert wurde. Diese Fähigkeit hat das Modell einfach so angenommen. Mozilla ist deswegen nicht in Panik verfallen: Ganz im Gegenteil. "The zero-days are numbered" ist ein optimistischer Beitrag in dieser Debatte, trotz des reißerischen Titels. Der rote Faden lautet: Lange Zeit musste der Angreifer nur einen einzigen Fehler finden, während der Verteidiger alle finden musste. Diese Asymmetrie hat klammheimlich dem Angreifer in die Hände gespielt. Sobald wir aber eine Maschine haben, die Bugs mit ähnlich geringem Aufwand findet wie ein richtig guter Mensch, beginnt diese Asymmetrie zu bröckeln.

Ich glaube, im Kern haben sie recht. Das ist tatsächlich eine gute Nachricht. Und es ist, trotz allem gegenteiligen Getöse, auch nicht das Ende von irgendetwas.

Wenn man heute in LinkedIn und Co. stöbert, dann scheinen wir nicht über KI reden zu können, ohne eine von zwei Extrempositionen einzumehmen. Entweder ist KI das Ende der Softwareentwicklung als Beruf (und Berufung), oder KI wird Softwareentwicklung „demokratisieren" und jeder kann sich — endlich — über's Wochenende sein eigenes ERP-System zusammenbasteln. Wie so oft liegt die Wahrheit aber in der Mitte.

Intent vs. Behavior

Was also ist diese Mitte im Falle von Code-Sicherheit? Wenn ein Mensch Code auf Sicherheit prüft, fragt er sich: „Tut das hier, was die Spec vorgesehen hat?" Eine Maschine hingegen stellt eine andere, weniger höfliche Frage: „Was erlaubt dieser Code, ganz gleich, wer ihn geschrieben hat und was er damit gemeint hat?" Viele Schwachstellen sitzen genau in der Lücke zwischen diesen beiden Fragen: Intent vs. Behavior. Der Endpoint, der dir deine eigene Rechnung liefert — aber eben auch alle anderen, wenn Du die ID in der URL änderst: Das hat niemand beabsichtigt, aber der Code hat es trotzdem erlaubt. Wer es ausführlicher mag: Nate hat dazu ein gutes Video.

Man darf das eigentlich nicht laut sagen, aber ich sage es trotzdem: Die meiste Software hat in Wirklichkeit gar keine Spezifikation. In dem Fall wird dann der Code zur Spezifikation.

Die Maschine liest also diese de-facto Spec und sagt dir, was der Code wirklich tut. Nicht, was du dir beabsichtigt^H erhofft hast. Das ändert klammheimlich unser Vertrauen darin, dass ein Stück Code sicher ist. Jahrzehntelang lautete die Antwort darauf, mehr oder weniger: Dieser Code ist sicher, weil ihn kompetente Leute geschrieben und andere kompetente Leute geprüft haben. Diese Antwort wird zunehmend fadenscheinig. Vielleicht ist die bessere Antwort: Dieser Code ist sicher, weil etwas ihn gründlich auseinandergenommen hat, ohne einen Fehler zu finden. Und zwar in einem Ausmaß, den kein Review-Meeting je erreichen wird. Übrigens kann sich natürlich auch beides ergänzen.

Der Nutzen

Nein, das ist keine Tragödie für Entwickler — egal, was die Schlagzeilen sagen. Wir bekommen ein besseres Werkzeug, und es zielt auf genau eine Sache: Sicherheit. Es versicht nicht, Deine Kunden zu verstehen oder Product-Market-Fit zu beurteilen. Was das Werkzeug tut, ist, eine Lücke zu schließen, die wir, ehrlich gesagt, selbst nie wirklich gut schließen konnten. Der Nutzen: Software wird sicherer, und dafür sollten wir dankbar sein.

Wie oft haben wir das schon gelesen? „Maschinen werden nie einen Menschen in Go schlagen" ist etwa so gut gealtert wie die meisten Sätze, die mit „Maschinen werden nie" beginnen. Die richtige Reaktion auf ein besseres Werkzeug bestand aber nie darin, ihm nachzutrauern. Die Antwort lautet: Pragmatismus. Lerne Dein Handwerk, nutze und bewerte neue Werkzeuge und Methoden, und setze sie ein, wenn sie sich als nützlich erweisen.