Bitcoin Core liegt richtig: Wenn eine KI den Fehler findet, ist Geheimhaltung Theater

Was nützt ein Geheimnis, das jeder Chatbot mit einem einzigen Prompt neu erzeugen kann? Genau diese Frage hat Bitcoin Core gerade beantwortet, und unserer Ansicht nach richtig.

Am Donnerstag, dem 22. Oktober, übernahm das Projekt eine Änderung seiner Sicherheitsrichtlinie, verfasst von Antoine Poinsot, Entwickler bei Chaincode Labs. Bisher stufte Core jede Schwachstelle nach Schweregrad ein und richtete den Zeitpunkt der Offenlegung danach aus. Fehler mit geringem Schweregrad wurden zwei Wochen nach Erscheinen der nächsten Hauptversion offengelegt. Mittlere und schwere Fehler konnten bis zwei Wochen nach dem Support-Ende der letzten betroffenen Version verborgen bleiben, eine Wartezeit, die sich auf etwa ein Jahr ausdehnen kann. Nun können die Maintainer einen Fehler bei der Triage als „leicht auffindbar“ einstufen. Diese Einstufung gilt für einen Fehler, der sich mit einem einfachen LLM-Prompt finden lässt. Für einen solchen Fehler wird der Fix in alle gepflegten Versionen zurückportiert, so schnell wie möglich ein Point Release veröffentlicht und ein Sicherheitshinweis mit einigen Details herausgegeben. Kritische Fehler bleiben außerhalb der Standardrichtlinie und werden von Fall zu Fall behandelt.

Das Embargo war eine Wette auf Schwierigkeit, und die Chancen haben sich verändert

Ein langes Embargo funktioniert nur, wenn Angreifer die Lücke wahrscheinlich nicht selbst finden. Stilles Patchen verschafft Node-Betreibern Zeit für das Update, bevor jemand erfährt, wo die Schwachstelle liegt. Poinsots eigene Diagnose lautet, wie CoinDesk ihn zitiert, dass LLMs die Hürde, bestimmte Arten von Problemen zu finden oder verdeckte Fixes zu erkennen, „drastisch“ gesenkt haben. Dieser zweite Teil wird unterschätzt. Ein stiller Patch ist selbst ein Hinweis, und ein Modell kann einen Diff lesen.

Bei dieser Art von Fehler schützt das Embargo also niemanden außer den Angreifer, der ohnehin Bescheid weiß. Währenddessen sitzen ehrliche Nutzer auf nicht behobenen älteren Versionen und warten auf eine Hauptversion. Die Richtlinie sagt es deutlich: „Die Embargofrist bringt wenig, verzögert aber die Verfügbarkeit einer korrigierten Version.“

Die Belege zeigen: Das ist nicht hypothetisch

Denken wir an den vergangenen Sommer. Eine ehrenamtliche Gruppe von 16 Entwicklern, das Bitcoin Red Team, ließ KI-Modelle in rund einem Tag über 390 Bitcoin-Projekte laufen und protokollierte laut CoinDesk 4.962 Funde, davon 85 kritische. Nicht alle dieser Funde wurden reproduziert (ein Bericht nennt zu diesem Zeitpunkt nur etwa ein Fünftel), die Zahl ist also mit diesem Vorbehalt zu lesen. Dennoch wurde binnen weniger Tage eine Schwachstelle in BTCPay Server, die die Gruppe privat gemeldet hatte, auf produktiven Händlerservern ausgenutzt. Die private Meldung war den Angreifern nicht voraus.

Das größere Bild weist in dieselbe Richtung. Eine Research Note der Cloud Security Alliance argumentiert, das klassische Modell der koordinierten Offenlegung mit seinem üblichen 90-Tage-Fenster sei für menschliche Forscher entworfen worden, die im menschlichen Tempo arbeiten. Wir sehen die Bitcoin-Entscheidung als konkreten Fall dieses Arguments.

Transparenz hat ihren Preis, und er lohnt sich

Die Änderung ist nicht umsonst. Poinsot räumt ein, dass schnellere Fixes weniger „Reifezeit“ in Tests bekommen. Das ist ein reales Risiko, denn ein hastiger Patch an Software, die ein riesiges Netzwerk absichert, kann schiefgehen. Die vom Entwickler Antoine Riard vorgeschlagene Alternative, Fixes in einigen Fällen ohne Sicherheitshinweis auszuliefern, wurde abgelehnt, und wir stimmen dieser Ablehnung zu. Poinsot argumentierte, Nutzer ohne Details zu warnen, könne übereilte Migrationen von Leuten auslösen, die gar nicht betroffen wären. Halbe Geheimhaltung liefert die Panik ohne die Information.

Auch an der Grenzziehung selbst gibt es berechtigte Kritik. Bisher wurde kein Fehler nach der neuen Regel eingestuft, daher ist, wie Crypto Briefing anmerkt, offen, wie einheitlich die Maintainer entscheiden, was als „leicht auffindbar“ gilt. Eine vage Einstufung könnte in beide Richtungen zum Schlupfloch werden. Wir halten das Kriterium für redlich, weil es davon abhängt, wie leicht ein Fehler zu finden ist, und nicht davon, welches Werkzeug ihn gefunden hat.

Was andere Projekte daraus lernen sollten

Die Lehre lautet nicht „alles sofort offenlegen“. Schwer auffindbare Fehler verdienen weiterhin Zeit, und Core behält dafür seinen Zeitplan nach Schweregrad bei. Die Lehre ist, dass sich die Grundannahme umgekehrt hat. Projekte sollten sich nun fragen, ob ein Fehler mit geringem Aufwand wiederentdeckt werden kann, und wenn ja, die Patch-Geschwindigkeit über die Diskretion stellen. Kritische Open-Source-Projekte mit träger Update-Kultur haben am meisten zu gewinnen, denn sie haben bei einem langen Expositionsfenster am meisten zu verlieren.

Unser Urteil: Bitcoin Core hat einen pragmatischen und leicht unbequemen Schritt getan, und es ist der richtige. Betreiber sollten auf Point Releases und Sicherheitshinweise achten und bereit sein, schnell zu aktualisieren. Alle anderen, die weit verbreiteten Code pflegen, sollten ihre Embargo-Regeln prüfen und fragen, welche davon Nutzer noch schützen und welche nur die Gewohnheit.