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.