Spec-Driven Development: Wenn der Patch zur Bauanleitung für den Exploit wird

Klaus Rodewig ist langjähriger Sicherheitsfachmann und Pentester und beschreibt seinen Weg vom Skeptiker zum Nutzer. Er hat ein vollständiges Softwareprojekt fast ausschließlich mit KI umgesetzt: Embedded-C auf einem Raspberry-Pi-Teil plus eine Flutter-Desktop-Anwendung, kleinteilig beauftragt und Modell für Modell durchprobiert.

Der Einstieg ist ein Malheur mit Wiedererkennungswert: Ein Ausfall der AWS-Zone us-east-1 legt Perplexity lahm, während im Hintergrund die Sorge umgeht, ein liegengelassener n8n-Workflow mit gültigem Zugangstoken könnte gerade die Kreditkarte belasten.

Wo alle Modelle gleich scheitern

Der lehrreichste Teil des Praxisberichts betrifft eine Grenze. Ein einfaches Filterproblem mit systemd und journalctl lösten weder Claude noch Gemini zuverlässig, egal wie oft nachgefragt wurde.

Das ist der wichtigste Befund für alle, die bei Schwierigkeiten das Modell wechseln. Wenn mehrere Modelle an derselben Stelle scheitern, liegt das Problem nicht am Modell. Es liegt daran, dass zu diesem Thema wenig gutes Material existiert, oder daran, dass die Aufgabe unpräzise gestellt ist.

Dazu passt die kuriose Anekdote, die zugleich ein ernstes Muster beschreibt: Ein Modell änderte wochenlang eigenmächtig eine Variable namens „Fahrzeugkontrolle“ in „Fahrzeugkontrolk“. Ohne Erklärung, auch auf Nachfrage nicht.

Solche stillen Änderungen sind der Grund, warum jede Ausgabe durch eine Versionskontrolle laufen sollte. Ein Fehler, den man sieht, ist harmlos. Einer, der zwischen zweihundert Zeilen steht, ist es nicht.

Spec-Driven Development

Der rote Faden der Folge ist ein Vorgehen, das die verbreitete Praxis umdreht.

Der Sicherheitsteil

Rodewig zieht die Linie konsequent zur Sicherheit weiter, und dieser Teil ist der beunruhigendste der Folge.

Sprachmodelle können Binärdateien ohne Symbolinformationen disassemblieren und in lesbaren C-Code zurückübersetzen. Für Audits ist das praktisch: Man kann prüfen, was eine Software tatsächlich tut, auch ohne Quelltext.

Für Patch-Zyklen ist es ein Problem. Ein veröffentlichtes Sicherheitsupdate war immer schon ein Hinweis: Wer die Version davor mit der danach vergleicht, sieht, was repariert wurde, und damit, wo die Lücke war. Bisher brauchte es Tage an Erfahrung, um daraus einen funktionierenden Angriff zu bauen. Mit Diffing und Modellanalyse sind es Minuten.

Die praktische Konsequenz betrifft jeden, der Software ausliefert: Das Zeitfenster zwischen Veröffentlichung eines Updates und dessen Installation beim Kunden ist zum kritischen Zeitraum geworden. Wer monatliche Wartungsfenster hat, hat einen Monat offenes Fenster.

Regelwerke, maschinenlesbar

Zum Schluss geht es um MISRA C, den Kodierstandard für sicherheitskritische Automobilsoftware, und um den Cyber Resilience Act, der ab 2027 verbindliche Sicherheitsanforderungen für vernetzte Produkte bringt.

Beides sind hundertseitige Regelwerke, die sich in maschinenlesbare Vorgaben übersetzen und direkt bei der Beauftragung durchsetzen lassen. Das ist eine der überzeugendsten Anwendungen überhaupt: Regeln, die niemand vollständig im Kopf hat, werden zur Voraussetzung statt zum Prüfschritt am Ende.

Fazit

Rodewigs Bilanz ist unaufgeregt und pointiert: Arbeitslos wird man nicht durch KI, sondern dann, wenn man sie ignoriert.

Für die eigene Arbeit ergeben sich drei Punkte. Wechseln Sie nicht das Modell, wenn mehrere an derselben Stelle scheitern. Suchen Sie stattdessen den Fehler in der Aufgabenstellung.

Schreiben Sie Spezifikationen vor dem Code und lassen Sie daraus zuerst Tests entstehen. Das ist der wirksamste bekannte Schutz gegen Ergebnisse, die gut aussehen und falsch sind.

Und rechnen Sie damit, dass Ihre Sicherheitsupdates als Bauanleitung gelesen werden. Wer bisher davon lebte, dass Reverse Engineering aufwendig ist, hat diesen Schutz verloren.