# Die Maschinen lesen den Code

> KI hat die Kosten des Schwachstellenfindens kollabieren lassen. In Bitcoins Open-Source-Ökosystem kam diese Kollision diesen Monat an — und Brüssel hat eine Uhr darauf gestellt, was als Nächstes geschieht.

Source: https://counterproof.io/de/notes/die-maschinen-lesen-den-code/ · Published 14 August 2026 · CounterProof ist eine Praxis der Clavestra Capital Limited (Malta, C 113987).


In der zweiten Augustwoche 2026 postete ein pseudonymer Bitcoin-Entwickler namens Calle einen
Satz, der durch die Branche ricochettierte: „Everything is broken, Bitcoin is burning" — alles
sei kaputt, Bitcoin brenne. Hinter der Hyperbel lag ein Datensatz. Das ehrenamtliche Bitcoin Red
Team hatte gerade Moonshot AIs Kimi K3 — ein erst zwei Wochen zuvor veröffentlichtes chinesisches
Open-Weight-Frontier-Modell — durch praktisch das gesamte Bitcoin-Open-Source-Ökosystem
getrieben: Wallets, Lightning-Anwendungen, Zahlungsbibliotheken und das Werkzeug darum herum.
Nach rund 108 Stunden — verstrichene Kampagnenzeit, gearbeitet von einem auf fünfundzwanzig
angewachsenen Team — über 501 Projekte hatte das Team 7.958 potenzielle Sicherheitsbefunde
protokolliert, davon 1.280 als hoch oder kritisch eingestuft.

Diese eine Kampagne verdichtet alles, worum es in diesem Artikel geht: was KI-Modelle einer
Codebasis inzwischen antun können, wer sie auf Bitcoin richtet, was sie finden — und warum eine
europäische Verordnung, die am 11. September 2026 zu greifen beginnt, all das von einer
Ingenieursgeschichte in eine juristische verwandelt.

## Die Angreifer waren zuerst da

Bevor die Verteidiger industrialisierten, taten es die Angreifer. Die
Open-Source-Lieferkette, von der Bitcoin und die weitere Digital-Asset-Branche abhängen, steht
seit Jahren unter anhaltendem, finanziell motiviertem Beschuss — und das Krypto-Ökosystem war
durchgehend das gemeinte Opfer.

Im September 2025 phishten Angreifer den Maintainer von `chalk`, `debug` und sechzehn weiteren
npm-Utilities — Pakete mit zusammen Milliarden wöchentlicher Downloads — und lieferten einen
Crypto-Clipper aus, der Browser-APIs einhakte und Empfängeradressen still austauschte, genau in
dem Moment, in dem ein Wallet-Nutzer eine Transaktion freigab — die Angreiferadressen sogar nach
visueller Ähnlichkeit gewählt, um der Entdeckung zu entgehen. Wochen später fügte der
Shai-Hulud-Wurm Selbstverbreitung hinzu und verwandelte isolierte Maintainer-Kompromittierungen
in Kettenreaktionen. Im März 2026 wurde die Axios-Bibliothek — in der Größenordnung von hundert
Millionen wöchentlicher Downloads — für knapp drei Stunden über ein gekapertes Maintainer-Konto
mit einer Backdoor versehen, parallel zur TeamPCP-Kampagne, die in einer einzigen Woche vier
weit verbreitete Open-Source-Projekte kompromittierte. Und im Juli 2026 schoben Angreifer eine
als „Telemetrie" getarnte Backdoor in das SDK der Injective-Blockchain und verdrahteten die
Exfiltration von Seed-Phrasen und privaten Schlüsseln direkt in die
Schlüsselableitungsfunktionen der Wallets; automatisiertes Publishing verbreitete sie binnen
Minuten auf achtzehn Pakete.

Die Richtung ist messbar. Sonatypes State-of-the-Software-Supply-Chain-Report 2026 zählte mehr
als 454.600 neue bösartige Open-Source-Pakete allein in 2025 — ein Sprung von 75 % gegenüber dem
Vorjahr, der die kumulierte Blockier-Summe über 1,2 Millionen treibt. Und auch das Werkzeug auf
der Angriffsseite entwickelt sich: Googles Threat Intelligence Group berichtete 2026, erstmals
einen Bedrohungsakteur mit einem Zero-Day-Exploit identifiziert zu haben, der nach ihrer
Einschätzung mit KI entwickelt wurde — bestimmt für ein Massenausnutzungsereignis.

Open-Source-Repositories werden genau deshalb angegriffen, weil sie die Vertrauensschicht sind.
Niemand muss Ihre Infrastruktur durchbrechen, wenn er eine Abhängigkeit vergiften kann, die Sie
freiwillig installieren. Und nirgends ist dieser Hebel größer als in Software, die Schlüssel und
Geld berührt.

## Das ColdCard-Debakel

Ende Juli wurde aus dem abstrakten Risiko ein lebensveränderndes. Ab dem 30. Juli 2026 begann
ein Angreifer, das zu leeren, was Bitcoins sicherstes Versteck sein sollte: Cold Storage. In
aufeinanderfolgenden Wellen — die größte fegte nach Zählung von Galaxy Research 1.082 BTC aus
1.196 Wallets in nur 41 Minuten — erreichte der Verlust 1.367 BTC — etwa 88,6 Millionen Dollar —
über 4.585 Adressen, die auf ColdCard-Hardware-Wallets von Coinkite erzeugt worden waren, Stand
Galaxys Kontrollpunkt vom 1. August. Spätere Zählungen liefen über 1.800 BTC und auf 130
Millionen Dollar zu, sobald eine vermutete vierte Welle eingerechnet wurde. (Korrigiert: Eine
frühere Fassung dieser Notiz nannte 116 Millionen Dollar — übernommen aus kursierender
Berichterstattung und im Nachhinein auf keine Quelle rückführbar, die die Zahl nennt, datiert
und definiert. Die größeren Summen rechnen eine Welle ein, die Wochen später noch als
unbestätigt beschrieben wurde, und Galaxys eigener Vorbehalt gehört mitgeführt: Sie haben
Adressen nach Muster zugeordnet und keine Rechenleistung eingesetzt, um zu beweisen, dass diese
Seeds schwach waren.) Nach dem veröffentlichten Mechanismus erforderte nichts davon Phishing,
ein gestohlenes Gerät oder physischen Zugriff irgendeiner Art — die Schlüssel wurden offline
rekonstruiert. Diese Ausschlüsse folgen daraus, wie der Fehler funktionierte; die Advisories des
Herstellers beanspruchen nicht, jeden einzeln untersucht und ausgeschlossen zu haben. Tausende
Langzeithalter, die alles getan hatten, was die Selbstverwahrungs-Orthodoxie vorschreibt —
Hardware-Wallet, Schlüssel offline, Air Gap intakt —, sahen Ersparnisse eines Lebens Adressen
verlassen, die allein sie kontrollieren sollten. Die Ursache war niederschmetternd banal: Ein im
März 2021 ausgeliefertes Firmware-Build-Flag ließ betroffene Geräte ihren dedizierten
Hardware-Zufallschip überspringen und auf einen schwachen Software-PRNG zurückfallen — die
effektive Entropie kollabierte, auf älteren Mk3-Geräten auf bis zu rund 40 Bit, weit genug, dass
Seed-Phrasen offline rekonstruiert werden konnten. Bitcoins Mathematik hielt; die Software darum
herum nicht. Coinkite lieferte Notfall-Firmware, vernichtete verwundbaren Lagerbestand und
flehte Nutzer an zu migrieren — bei gleichzeitigem Eingeständnis, dass kein Patch einen Seed
reparieren kann, der bereits auf verwundbarer Firmware erzeugt wurde.

Dann kam der Deutungskrieg. Coinkite-CEO Rodolfo Novak rahmte den Exploit als „a sober reality
of the new AI paradigm" — eine nüchterne Realität des neuen KI-Paradigmas: KI-gestütztes
Code-Review fördere latente Bugs inzwischen schneller zutage als selbst die erfahrensten
menschlichen Experten, und jede Firmware, die öffentlich ist oder je war, müsse als unter
maschineller Prüfung durch Angreifer wie Verteidiger stehend gelten. Diese Behauptung ist
umstritten, und Ehrlichkeit verlangt, das zu sagen. Kein Angreifer wurde identifiziert. Kein
Beweis ist aufgetaucht, dass ein Modell den Fehler fand — Coinkites eigene Formulierung ist,
man müsse „annehmen" („we have to assume"), dass jemand KI auf die veröffentlichte Firmware
angesetzt habe, und im selben Dokument legt das Unternehmen offen, dass sein eigenes
KI-Review, Wochen zuvor gefahren, „diesen Bug oder irgendetwas Ernstes nicht fand" („did not
find this bug or anything serious"). Eine frühere Fassung dieser Notiz schrieb außerdem,
Sicherheitsspezialisten hätten hart widersprochen — ein Build-Flag, das einen Hardware-RNG
deaktiviert, sei ein menschliches Ingenieursversagen, das konventionelles Review Jahre früher
hätte fangen müssen. Das konnten wir beim Nachprüfen nicht halten: Der eine Beitrag, den wir
verfolgt hatten, liegt auf einem gesperrten Konto, und der nächste benennbare Kommentator, den
wir fanden, stimmte Coinkite eher zu, als zu widersprechen. Das Argument scheint uns weiterhin
richtig — aber es ist jetzt unseres statt ein zugeschriebenes. In einem Sinn ist der Streit
aber nebensächlich. Ob eine KI *diesen* Bug fand oder nicht: Das Ökosystem weiß jetzt, dass
Modelle Bugs genau dieser Klasse in genau diesem Tempo nachweislich finden können — und es
reagierte, als wäre die Bedrohung real. Binnen Tagen pausierte die Börse Boltz ihren Betrieb,
um KI-getriebenen Angriffsversuchen zuvorzukommen. Und eine ehrenamtliche Gegenmacht trat
zusammen.

## Der Aufstieg des Red Teams in Bitcoin

Das Bitcoin Red Team formierte sich binnen Tagen nach dem ColdCard-Abfluss: eine ehrenamtliche
Notfall-Gegenmacht aus sechzehn Forschern, geführt von Calle an der Seite von AnchorWatch-CEO
Rob Hamilton, unterlegt mit rund 40.000 Dollar an KI-Rechenleistung und unterstützt von
OpenSats, dessen neues Code-RED-Förderprogramm verantwortliche Schwachstellenoffenlegung im
Ökosystem inzwischen belohnt. Die Methode paart KI-getriebene Analyse mit menschlicher
Verifikation — Modelle fegen durch Wallets, Lightning-Implementierungen und Bibliotheken;
Forscher reproduzieren und würdigen; belastbare Befunde gehen privat an die Maintainer, bevor
irgendetwas veröffentlicht wird.

Die Entwicklung seiner Zahlen erzählt, was KI mit der Ökonomie des Schwachstellenfindens macht.
Der erste Sprint reichte 4.962 Befunde über 390 Projekte in 27,5 Stunden ein — 85 kritisch und
635 hoch, im Schnitt, nach Calles Rechnung beim Start, in der Größenordnung eines kritischen
Exploits pro Forscher und Stunde. Tage später stand der erweiterte Durchlauf bei 7.958 Befunden
über 501 Projekte. Calles Zusammenfassung: Der Basis-Scan praktisch des gesamten
Bitcoin-Open-Source-Ökosystems ist abgeschlossen, die niedrig hängenden Früchte sind gepflückt.

Die Befunde kommen mit einer Textur, die mehr zählt als die Summen. Schwachstellen
konzentrierten sich in älteren und wenig geprüften Codebasen. Lightning-nahe Software —
strukturell komplex, performancesensibel, schwer zu auditieren — trug überproportionale
Exposition. Die Verbreitung C-basierter Implementierungen wurde als anhaltendes strukturelles
Risiko markiert. Und wie schnell ein Projekt auf eine private Offenlegung reagierte, erwies
sich selbst als Diagnostikum: Reaktionsgeschwindigkeit, so das Team, ist ein sichtbarer Proxy
für Projektgesundheit. Unbetreute Projekte, warnten sie, sollte man nicht trauen.

Die Kampagne hat bereits verifizierte, reale Wirkung erzeugt. BTCPay Server — einer der am
weitesten verbreiteten selbstgehosteten Bitcoin-Zahlungsabwickler — lieferte am 7. August
Version 2.4.2 aus und patchte einen kritischen Zwei-Faktor-Authentifizierungs-Bypass, teilweise
Forschern des Bitcoin Red Teams zugeschrieben — und bestätigte anschließend, dass der Fehler
bereits in freier Wildbahn ausgenutzt worden war, um
Lightning-Wallet-Zugangsdaten abzuziehen. Das ist die ganze These in einem Vorfall: Die
Schwachstelle war real, sie wurde benutzt, und maschinengestütztes Review erreichte sie, bevor
die meisten Menschen es getan hätten.

Es lohnt, direkt zu sagen, was das gekostet hat. Sechzehn Freiwillige, rund 40.000 Dollar
Rechenleistung, ein paar Wochen — und eine Disziplin, die die meisten finanzierten
Sicherheitsprogramme nie aufbringen: private Offenlegung zuerst, Veröffentlichung erst, nachdem
die Maintainer die Befunde hatten, und die eigene Reproduktionsquote öffentlich benannt statt
vergraben. Sie haben ein Ökosystem kartiert, das ein Jahrzehnt unkartiert geblieben war, und
sie haben die Ergebnisse verschenkt. Was auch immer in diesem Artikel noch folgt: Das ist der
Referenzstandard dafür, wie diese Arbeit zu führen ist, und das Bitcoin-Ökosystem ist diesen
Monat sicherer als letzten — ihretwegen.

Eine Einschränkung dieser Arbeit verdient es, klar ausgesprochen zu werden, weil sie
routinemäßig als methodische Wahl missverstanden wird. Das Team berichtete, dass
Nutzungsbeschränkungen von US-Modellen für Sicherheitsforschung sie wiederholt blockierten —
und sie zu Open-Weight-Modellen wie Kimi K3 und Z.ais GLM 5.2 drängten, die sich lokal und ohne
Policy-Torwächter betreiben lassen. Kimi K3 war kein Kompromiss; für diese Arbeit, in diesem
Moment, gehörte es zu den besten Instrumenten, die zu benutzen ihnen überhaupt erlaubt war.

Das ist ein Politikversagen, kein Forschungsversagen. Die Werkzeugwahl in der
Sicherheitsforschung wird inzwischen weniger von der Modellqualität geprägt als davon, wer die
Arbeit überhaupt gestattet — und ein Team, das zu dem Modell greift, das den Job tatsächlich
ausführt, verhält sich korrekt. Westlichen Laboren sollte das zu denken geben: Die defensive
Forschung findet so oder so statt. Die einzige Frage ist, auf wessen Modellen — und ob die
Menschen, die sie betreiben, in ein engeres Werkzeugset gezwungen werden, als die Angreifer es
haben.

## Was 7.958 Befunde tatsächlich bedeuten

Hier ist Ehrlichkeit geschuldet — und das Team war das erste, das sie schuldete. Von den 7.958
Befunden hatten 24,7 % einen reproduzierbaren Proof of Concept — die eigene Formulierung des
Teams — und 29,4 % waren beim letzten Stand upstream gemeldet; Zahlen, die das Team selbst
veröffentlichte, statt sie wegzurunden. (Eine frühere Fassung dieser Notiz schrieb „dynamisch
reproduziert"; das war unsere Glosse, nicht ihre, und die Meldequote sind an Maintainer
gesandte Befunde, nicht von Maintainern akzeptierte.) Eine gemeinsame Bewertung des britischen
AI Security Institute und des US-amerikanischen CAISI befand Kimi K3 für fähig, aber weit von
unfehlbar — 32 % auf Exploit-Entwicklungs-Benchmarks, vor GLM-5.2, aber deutlich hinter den
stärksten geschlossenen Modellen, und beliebige Codeausführung bei keinem von 41 getesteten
Beispielen.

Dies ist also keine Liste von 7.958 ausnutzbaren Löchern in Bitcoin, und niemand Beteiligtes
hat das behauptet. Calles eigene Rahmung war unverblümt: Kandidaten sind billig, und wer die
resultierende Informationsflut nicht bewältigt, soll KI benutzen, um sie zu sortieren. Das ist
die richtige Lesart, und sie zeigt auf die eigentliche Verschiebung. KI hat die
*Kandidatenerzeugung* nahezu kostenlos gemacht. Nicht kostenlos gemacht hat sie das Urteil, das
eine bestätigte, reproduzierbare, korrekt eingestufte Schwachstelle von einer plausibel
klingenden Halluzination trennt — dasselbe „AI-Slop"-Problem, in dem Open-Source-Maintainer von
curl an ertrinken.

Die knappe Ressource in der Sicherheit ist still von der Detektion zur Würdigung gewandert. Das
ist eine Eigenschaft der Technologie, kein Mangel irgendeiner Kampagne — und ein Sweep, der ein
ganzes Ökosystem kartiert, und eine signierte Bewertung einer einzelnen Codebasis sind schlicht
verschiedene Aufgaben. Die erste sagt, wo man hinsehen soll. Die zweite ist, was ein Regulator,
ein Käufer oder ein Versicherer tatsächlich akzeptiert. Jeder ernsthafte Akteur in diesem Feld —
Angreifer, Verteidiger, Maintainer, Regulator — steht jetzt stromabwärts dieses Engpasses.

## Brüssel stellt die Uhr

In diese Kollision hinein tritt der EU Cyber Resilience Act, und sein Timing könnte kaum
schärfer sein.

Ab dem **11. September 2026** verpflichtet Artikel 14 des CRA Hersteller von Produkten mit
digitalen Elementen, die in der EU verkauft werden, jede aktiv ausgenutzte Schwachstelle, von
der sie Kenntnis erlangen, zu melden — binnen 24 Stunden als Frühwarnung, 72 Stunden für die
vollständige Meldung und 14 Tagen für den Abschlussbericht — gleichzeitig an die ENISA und das
benannte nationale CSIRT, über die zentrale Meldeplattform. Entscheidend: Das gilt für Produkte,
die bereits auf dem Markt sind, nicht nur für neue Releases. Ab dem **11. Dezember 2027** gilt
die Verordnung dann vollständig — mit bindenden Secure-by-Design-Anforderungen, der Pflicht aus
Anhang I, die Sicherheit *regelmäßig* und wirksam zu testen und zu überprüfen, technischer
Dokumentation, die die Berichte dieser Tests enthält, und Aufbewahrungspflichten, die sich über
ein Jahrzehnt strecken. Geldbußen nach Artikel 64 reichen bis 15 Millionen Euro oder 2,5 % des
gesamten weltweiten Jahresumsatzes, **je nachdem, welcher Betrag höher ist**.

Jetzt setze man die beiden Hälften dieses Artikels zusammen. KI-gestützte Kampagnen fördern
binnen Wochen Tausende Kandidaten-Schwachstellen über Open-Source-Ökosysteme zutage — und
einige davon, wie der BTCPay-Fehler, werden *aktiv ausgenutzt*, was genau der Meldeauslöser des
CRA ist. Ein Hersteller, dessen Produkt eine kompromittierte Abhängigkeit einbettet — oder
einen Fehler, den ein KI-Sweep zutage fördert und ein Angreifer zuerst erreicht —, steht nicht
mehr vor einer stillen Ingenieurskorrektur. Er steht vor einer juristischen 24-Stunden-Uhr. Und
ein Hersteller ganz ohne Entdeckungsprozess verletzt Artikel 14 womöglich nicht durch
Nichtmelden, sondern dadurch, dass er nie wusste, dass es etwas zu melden gab.

Die unbequeme Folgerung: Viel von dem Code, der jetzt in diesen Produkten ausgeliefert wird,
ist maschinengeschrieben, und viel von dem Review, das darauf angewandt wird, leisten dieselben
Modelle, die ihn geschrieben haben. Code, den ein Modell geschrieben und dasselbe Modell
geprüft hat, wurde von niemandem geprüft. Regulatoren, Käufer, Versicherer und
Unternehmens-Sicherheitsteams konvergieren auf dieselbe Frage — und „unser Modell hat seine
eigene Ausgabe geprüft" ist keine Antwort, die irgendeiner von ihnen akzeptiert.

## Widerlegung als Disziplin: die CounterProof-Methode

Ein Sweep und eine Bewertung beantworten verschiedene Fragen, und die zweite ist, wo unsere
eigene Praxis sitzt. CounterProof wurde nicht in einem Workshop als Produkt entworfen; es
akkretierte, während wir unsere eigene Threshold-Kryptografie-Zahlungsinfrastruktur
absicherten — wo ein durchgerutschter Defekt keine Kundenbeziehung kostet, sondern den Betreiber
sein eigenes Geld.

Die Randbedingung, die sie formte, war das Gegenteil der des Red Teams. Sie brauchten Breite:
501 Projekte, schnell, auf welchem Modell auch immer die Arbeit lief. Wir brauchten einen
einzelnen Befund, der es übersteht, öffentlich falsch zu sein, auf Code, der unser eigenes Geld
hält. Breite verzeiht einen False Positive; eine signierte Bewertung nicht. Anderes Problem,
andere Methode — und wir hatten den Luxus, Instrumente zu wählen, was genau das ist, was die
oben beschriebenen Policy-Beschränkungen ihnen verwehrten.

CounterProof nimmt den Würdigungs-Engpass frontal, mit einem Protokoll, das von den oben
beschriebenen Fehlermodi geformt ist. Jede Bewertung ist ein multi-lineages adversarielles
Review: unabhängige Modell-*Familien* — nicht ein zweiter Durchlauf derselben — greifen jeden
Befund an und versuchen, ihn zu widerlegen; Uneinigkeiten werden durch Lesen der Quelle
entschieden, nicht durch Abstimmung.

Der letzte Punkt ist kein Anspruch auf bessere Modelle. Er ist eine Aussage über eine gemessene
Eigenschaft aller: Das Urteil eines Prüfers ist eine Stichprobe, keine Messung. Gib demselben
Modell dieselben Bytes zweimal, und es liefert nicht immer dieselbe Antwort; gib eine Frage
mehreren Familien, und sie scheitern in verschiedene Richtungen — der einzige Grund, warum
mehrere zu betreiben die Kosten wert ist. Wir haben zugesehen, wie ein Modell selbstbewusst
eine Verordnungsfundstelle „korrigierte" und falsch lag, während ein Modell ohne Quellzugriff
korrekt die Antwort ganz verweigerte. Die Lektion ist nicht, dass eine Lineage überlegen ist.
Sie ist, dass eine einzelne Lineage — jede einzelne — sich nicht selbst prüfen kann. Nichts
wird unwiderlegt ausgeliefert. Jeder Befund, der überlebt, wird entweder gegen die tatsächliche
Quelle bestätigt — exakte Datei und Zeile, Reproduktionspfad, Wirkungsklassifizierung, mit
maschinell gegen die exakt geprüfte Revision aufgelösten Zitaten — oder ausdrücklich als *nur
plausibel* etikettiert. Jeder Befund nennt die Evidenzstufe, die er tatsächlich erreicht hat —
Quellnachverfolgung, Kompilierbeweis, Test oder Live-Reproduktion — und impliziert nie eine
höhere. Und jeder Bericht trägt einen stehenden Rückzugsvertrag: Wird ein Befund als falsch
erwiesen, wird er schriftlich zurückgezogen.

Mit anderen Worten: Wo KI-Ära-Review Rauschen im Industriemaßstab erzeugt, ist CounterProofs
Ergebnis absichtlich das Gegenteil einer Triage-Warteschlange. Es ist eine signierte,
evidenzgestufte Bewertung unter einer persistenten Engagement-Kennung — strukturiert, um einem
Due-Diligence-Team oder einem Versicherer übergeben oder als Prüfbericht nach dem Zuschnitt von
Anhang VII Nummer 6 in die CRA-technische-Dokumentation aufgenommen zu werden, als Beleg der
Prüfpflicht. Die Unabhängigkeit ist strukturell: Wir erstellen keine Bewertung von Code, der
von CounterProof oder einem Unternehmen unserer Gruppe verfasst wurde — und unsere eigene
Codebasis, zu großen Teilen maschinengeschrieben, läuft kontinuierlich durch dasselbe
adversarielle Register. Wir waren unser eigener erster Kunde, und wir bleiben unser härtester.

Wir werden in Kürze einen neuen Dienst auf **CounterProof.io** starten, der diese Praxis auf
Teams ausweitet, die genau der Konvergenz gegenüberstehen, die dieser Artikel beschreibt:
maschinengeschriebener Code, Gegner in Maschinengeschwindigkeit und die Uhr eines Regulators.
Mehr dazu bald.

## Wohin das führt

Drei Vorhersagen, locker gehalten.

Erstens: Die Triage-Lücke weitet sich, bevor sie sich schließt. Open-Weight-Modelle werden
weiter besser, Sweeps wie der des Bitcoin Red Teams werden in anderen Ökosystemen wiederholt,
und das Verhältnis von Kandidatenbefunden zu verifizierten wird schlechter, bevor
Würdigungswerkzeuge und disziplinierte Methoden aufholen. Projekte werden zunehmend — von
Nutzern, Versicherern und Käufern gleichermaßen — an ihrer Reaktionsgeschwindigkeit auf
Offenlegungen gemessen werden, genau wie Calle beobachtete.

Zweitens: Der CRA wird die Zwangsfunktion, die Bug Bountys nie waren. Freiwillige
Offenlegungsnormen haben ein Jahrzehnt lückenhafte Abdeckung erzeugt; eine
24-Stunden-Meldepflicht mit umsatzskalierten Geldbußen wird in achtzehn Monaten erledigen, was
guter Wille nicht tat — und die Nachfrage nach regelmäßiger, unabhängiger,
dokumentationstauglicher Sicherheitsprüfung wird den Audit-Markt um Evidenz statt um Abzeichen
neu strukturieren.

Drittens, und für Bitcoin am grundsätzlichsten: Ein Ökosystem, dessen Sicherheitsmodell auf
offenem Review ruht, steht davor herauszufinden, ob maschinelles Review zählt. Die ehrliche
Antwort: Es zählt nur, wenn eine unabhängige Partei bereit ist, den Befund zu verifizieren, die
Evidenz zu graduieren und zu unterschreiben. Die Detektion wurde automatisiert. Die
Verantwortung nicht — und sie kann es nicht werden. Dort leben jetzt der Wert und die
Verantwortung.

---

*CounterProof ist eine unabhängige adversarielle Review-Praxis der Clavestra Capital Limited
(Malta). Proof bezeugt; CounterProof widerlegt. counterproof.io — Diese Seite ist eine
Übersetzung des englischen Originals; bei Abweichungen gilt das Original.*

---

**Quellen:** Coinkite-Sicherheits-Advisory sowie Berichterstattung von Forbes, Bloomberg, CBC
und Galaxy Research zum ColdCard-Exploit (Jul.–Aug. 2026); Offenlegungen des Bitcoin Red Teams
via Bitcoin Magazine, Decrypt, crypto.news, Coinpaper und Metaverse Post (Aug. 2026);
Release-Notes zu BTCPay Server 2.4.2; gemeinsame Modellbewertung UK AISI / US CAISI; Sonatype
State of the Software Supply Chain 2026; Google Threat Intelligence Group, Bericht zu
KI-gestützter Bedrohungsaktivität (2026); StepSecurity-Analyse der Injective-SDK-Kompromittierung
(Jul. 2026); Berichterstattung zu npm-Lieferketten-Vorfällen (Sept. 2025 – März 2026);
Verordnung (EU) 2024/2847 (Cyber Resilience Act), Art. 13–14, 16, 69, Anhänge I & VII.