Heute Morgen sind Datasette 1.0a39 und 0.65.4 erschienen, zwei Security-Patches: einer für die aktuelle Alpha-Reihe, einer für die stabile 0.65er-Familie. Wenn du eine Datasette-Instanz im offenen Netz betreibst und dort öffentliche und private Tabellen mischst, solltest du sie einspielen.
Die eigentliche Geschichte steht daneben. Angestoßen hat das Ganze Sevban Dönmez mit Meldungen, die er selbst KI-gestützt erarbeitet hat. Danach haben Simon Willison und Alex Garcia ein ausführliches Audit gefahren - mit Claude Fable 5.1, GPT-5.6 Sol und GPT-6 Astra. Danach saßen sie fast eine Woche an den Fixes.
Der Ablauf ist der spannende Teil
Willison beschreibt eine Arbeitsteilung, die Alex Garcia vorgeschlagen hat und die ich ziemlich klug finde. Beide arbeiteten in einem gemeinsamen privaten Repository. Bei den meisten Befunden hat einer den automatisierten Test geschrieben, der das Problem zeigt, und der andere hat den Fix gebaut.
Damit schauen zwei Menschen auf jeden Befund - zusätzlich zu den Agenten, die auf unterschiedlichen Modellen liefen. Die Modelle liefern Hinweise, der Test beweist sie, und die Trennung der Rollen verhindert, dass jemand seinen eigenen Fehler durchwinkt.
Die Tests selbst bleiben vorerst außerhalb der öffentlichen Repositories. Das ist der übliche Umgang mit frisch geschlossenen Lücken: erst sollen die Leute patchen, dann kommen die Details.
Willisons Fazit ist eine Ankündigung: Sie fanden “some very subtle bugs”, und Sicherheitsaudits durch Frontier-Modelle sollen künftig zu jeder Entwicklungsarbeit an Datasette gehören.
Warum ich das für mehr halte als eine Anekdote
Datasette ist kein Spielzeug. Das Projekt läuft seit Jahren, wird von einem sehr erfahrenen Entwickler gepflegt, der öffentlich über Sicherheit schreibt. Wenn ein Audit dort noch subtile Fehler findet, sagt das wenig über Datasette und viel über die Grenze menschlicher Aufmerksamkeit bei genau dieser Art von Fehlern.
Dazu kommt: Es waren drei Modelle von zwei Anbietern. Das ist kein Zufall. Verschiedene Modelle haben verschiedene blinde Flecken, und wer nur eins laufen lässt, erbt dessen Lücken. Dieselbe Logik kennst du aus der Statik oder aus dem Code-Review - nur dass die zweite Meinung hier ein paar Dollar kostet statt ein paar Tage.
Und es steht in einer Woche, in der die andere Seite derselben Medaille zu sehen war: Calif Research hat gezeigt, dass ein Team mit KI-Unterstützung in etwa zwei Tagen von der Lücke zum funktionierenden Exploit kommt. Dieselben Fähigkeiten, zwei Richtungen. Wer verteidigt, kann sie sich nicht mehr aussuchen.
Was du daraus mitnehmen kannst
Der Ablauf ist übertragbar, auch auf kleine Projekte:
- Mehr als ein Modell laufen lassen, am besten von verschiedenen Anbietern
- Jeden Befund erst durch einen Test bestätigen lassen, bevor jemand etwas repariert
- Test und Fix auf zwei Personen verteilen
- Erst patchen und ausliefern, dann die Details veröffentlichen
Der Punkt ist nicht, dass die Modelle Lücken finden. Der Punkt ist, dass ein Verfahren drumherum steht, das Fehlalarme aussortiert, bevor sie Arbeit erzeugen. Ein Agent, der zwanzig angebliche Sicherheitsprobleme meldet, ist wertlos, solange niemand sie auseinanderhält.
Quellen: Datasette: September security releases, Simon Willison