Het lek is vijf jaar oud, uw leverancierscontract ook

Eind juli 2026 publiceerde hardwarefabrikant Coinkite een beveiligingswaarschuwing voor zijn Coldcard-apparaten, waarmee bedrijven en particulieren cryptosleutels bewaren. In diezelfde dagen werden de wallets al leeggehaald: één veegactie van ongeveer 41 minuten kostte gebruikers circa 70 miljoen dollar, en begin augustus stond de teller volgens Galaxy Research op ongeveer 1.755 bitcoin uit zo'n 5.000 wallets, terwijl het incident nog liep (Cinco Días, 4 augustus 2026). Het gebrek dat dit mogelijk maakte zat op dat moment al ruim vijf jaar in de firmware. Betaalbedrijf Block publiceerde een eigen technische analyse die de oorzaak bevestigde. Voor Nederlandse ondernemers die software of apparatuur inkopen roept dit incident een heel gewone contractvraag op: wie draagt de schade wanneer een oud gebrek plots wordt uitgebuit, en wat staat daarover eigenlijk in uw leverancierscontract?

Een gewoon gebrek, vijf jaar onzichtbaar

Technisch was het gebrek banaal. De firmware bevatte twee versies van de functie die willekeurige getallen levert: de hardwaregenerator van de fabrikant en een softwarematige reserveversie. Beide droegen dezelfde naam. Een controle in de bouwomgeving toetste alleen óf een bepaalde instelling bestond, en keek niet naar de waarde ervan. Vanaf firmwareversie 4.0.1 uit maart 2021 tot en met 4.1.9 werd daardoor ongemerkt de zwakke reserveversie meegeleverd. Voor de oudere modellen schatte Coinkite de effectieve zoekruimte van zo'n sleutel voorlopig op een sterkte van ongeveer 40 bits, waar 128 bits de bedoeling was; nieuwere modellen bleven met circa 72 bits eveneens onder de norm. Vijf jaar lang deed het apparaat het gewoon, en vijf jaar lang was vrijwel elke sleutel die eruit kwam te raden voor wie hard genoeg zocht; alleen wie bij het aanmaken zelf ten minste vijftig geheime dobbelworpen als extra invoer toevoegde, bleef volgens de fabrikant buiten de gevarenzone.

Naar Nederlands recht kán zo'n verborgen zwakte een tekortkoming opleveren; automatisch is dat niet. Het hangt ervan af welke prestatie is overeengekomen en welke eigenschappen de afnemer op grond van de overeenkomst mocht verwachten. Bij koop biedt de conformiteitseis van artikel 7:17 BW het kader; bij een tekortkoming regelt artikel 6:74 BW de schadeplichtigheid. Ook het moment telt: kwetsbare firmware kan bij levering al op het apparaat hebben gestaan, of pas later via een update zijn binnengekomen, en dat verschil kleurt de juridische beoordeling. De tijd wringt bovendien op een andere plek. Wie in 2021 of 2022 kocht, heeft vaak algemene voorwaarden geaccepteerd met korte klachttermijnen, vervalbedingen en garantieperiodes van twaalf of vierentwintig maanden. Het gebrek is dan ouder dan elke termijn die het contract kent.

De patch dicht het lek, de oude sleutels blijven zwak

Coinkite bracht een firmware-update uit, en die repareert de generator. De fabrikant is er in zijn waarschuwing zelf expliciet over: een sleutel die onder de fout is aangemaakt blijft zwak, ook na de update, en ook wanneer de gebruiker die sleutel netjes overzet naar een apparaat van een andere fabrikant. Een sterke, unieke passphrase werpt een extra barrière op, maar repareert de onderliggende sleutel niet. Wie veilig wil zijn moet nieuwe sleutels aanmaken en alles verhuizen. Herstel omvat hier dus veel meer dan de update, en dat patroon ziet u bij gewone bedrijfssoftware net zo goed: heeft een gebrek wachtwoorden, certificaten of back-ups aangetast, dan is de patch pas het begin van het werk.

Vergelijk het met een terugroepactie in de autobranche. De fabrikant vervangt het onderdeel én organiseert en betaalt de operatie eromheen. In softwarecontracten eindigt de herstelverplichting daarentegen opvallend vaak bij het beschikbaar stellen van een nieuwe versie. De heruitgifte van sleutels en certificaten, de migratie van data, het forensisch onderzoek en de melding aan klanten en toezichthouders, kortom de duurste onderdelen van de nasleep, blijven dan stilzwijgend voor rekening van de afnemer. Die verdeling staat in een clausule, en over clausules valt te onderhandelen.

De tijd tussen waarschuwing en aanval krimpt

De veegacties en de waarschuwing vielen hier in dezelfde dagen; wie de advisory las, had in het gunstigste geval uren om te handelen. Coinkite vermoedt in zijn technische toelichting zelf dat de aanvaller AI heeft gebruikt om het lek in oudere firmware op te sporen. Die toeschrijving is een aanname van de fabrikant en blijft vooralsnog onbewezen. Het hardere gegeven staat in dezelfde toelichting: het bedrijf had weken eerder een geavanceerd AI-model over precies deze code laten lopen, en dat model vond dit gebrek niet, en ook niets anders van betekenis. Eén AI-codescan bewijst dus weinig, in beide richtingen. Wat dit ene incident over AI bewijst, blijft daarmee open. Het bredere beeld is wel gedocumenteerd: IBM telde in 2026 dat een op de vier onderzochte kwaadaardige inbreuken AI-ondersteund was, 56 procent meer dan een jaar eerder (cijfers geraadpleegd op 5 augustus 2026).

Voor inkopende ondernemingen is de risico-inschatting daarmee verschoven. Wie een openbare waarschuwing van een leverancier ontvangt, moet er rekening mee houden dat misbruik in uren of dagen op gang komt, en soms al loopt. En het verweer "onze leverancier had de code met AI laten controleren" zal in een aansprakelijkheidsdiscussie weinig gewicht krijgen. Zorgvuldigheid zit in het proces: meerdere controlelagen, onafhankelijke audits en snelle, controleerbare openheid zodra iets misgaat. Dat Block binnen een dag een openbare technische reconstructie leverde, is precies het soort transparantie dat u als afnemer contractueel wilt kunnen afdwingen.

Vijf vragen aan uw leverancierscontract

Leg uw eigen inkoopcontract of de algemene voorwaarden van uw softwareleverancier naast deze vijf vragen. Ze bepalen samen wie in zo'n week als deze de rekening krijgt.

1. Wat telt als gebrek? Leg vast dat de software bij levering moet voldoen aan de stand van de techniek voor veilige ontwikkeling, en dat een beveiligingskwetsbaarheid een tekortkoming is, ook zolang er nog geen schade is ontstaan. Vraag daarbij om controleerbare toezeggingen; hoe u bewijs boven geruststelling stelt, werkten wij eerder uit voor leveranciersverklaringen bij SaaS-contracten.
2. Hoe snel hoort u het? Een openbare advisory is geen melding aan u. Beding een rechtstreekse meldplicht binnen een concreet aantal uren, met voorlopige maatregelen die u zelf kunt treffen en een hersteltermijn die past bij het risico van het systeem.
3. Wat blijft er over van de exoneratie? Leveranciersvoorwaarden sluiten gevolgschade vrijwel altijd uit, en tussen ondernemingen houden zulke bedingen vaak stand, al blijven de totstandkoming, de uitleg, de ernst van het verwijt en de beperkende werking van redelijkheid en billijkheid (artikel 6:248 lid 2 BW) meewegen. Beding daarom een uitzondering: de aansprakelijkheidsbeperking geldt niet bij schending van de beveiligings- en meldverplichtingen. Bewaak daarnaast uw eigen positie, want de wettelijke klachtplicht (artikel 6:89 en, bij koop, 7:23 BW) loopt gewoon door; hoe u een ontdekt gebrek tijdig en juridisch bruikbaar meldt, beschreven wij eerder in onze bijdrage over de klachtplicht en ingebrekestelling.
4. Wat omvat herstel? Reken naast de patch ook de heruitgifte van sleutels en certificaten, datamigratie en de redelijke kosten van onderzoek en klantnotificatie tot de herstelverplichting. Anders financiert u de nasleep van andermans fout.
5. Welk bewijs krijgt u? Neem een auditrecht op, afspraken over logging en een technische rapportageplicht bij incidenten. Wie bij een geschil het technische bewijs heeft, stuurt de uitkomst, een les die ook bij bedrijfsgeheimen en NDA's telkens terugkeert. In het Coldcard-geval kwam de bruikbaarste analyse van een derde partij; van dat toeval wilt u niet afhankelijk zijn.

Sneller weten waar u staat

Deze vijf vragen zijn met het contract en de voorwaarden ernaast in een middag te beantwoorden. Wie het grondiger wil aanpakken: de contract-scan licht leverancierscontracten en algemene voorwaarden door op precies deze risicoverdeling, van exoneraties en meldtermijnen tot de vraag wat er onder herstel valt, en levert per clausule een concreet red-flag-overzicht op, zodat de risicoverdeling vastligt vóórdat een advisory van uw leverancier uw ochtend bepaalt.