Worth calibrating what this kind of scanning buys, because the Coldcard bug is a useful negative example and the vendor said so themselves.
Their own AI-assisted review, weeks earlier, missed it. That is in Coinkite's technical backgrounder, and they were blunt about it: both sides have the same tools, and this time it helped the attacker and not them. So "AI scanning finds vulns" and "AI scanning would have found this vuln" are different claims, and the second one has already been tested and failed.
Why this particular bug is scanner-resistant. Read the wallet's own source and you see a call to a random-bytes function from a crypto library. It looks correct. It is correct as written. The defect is which implementation that name binds to at build time — ngu.random.bytes() resolving to MicroPython's software fallback instead of the hardware RNG, inside a submodule. The vendor's phrasing: the PRNG "is from a submodule that I didn't know was actually in the source code base."
A scanner pointed at the application repo sees correct code, because the code is correct. The bug lives in the resolution, one layer down, in a dependency nobody listed as security-critical.
And the output gives you nothing. This is what makes RNG bugs a category of their own. Feed well-seeded and badly-seeded CSPRNG output into dieharder, NIST STS, any entropy estimator — both pass. A PRNG's entire job is producing output that looks random. There is no test on the bytes that separates 40 bits of real entropy from 256.
What the $10k does buy, and it is genuinely worth having: memory safety, injection, auth logic, key handling mistakes visible in the code under review. That is a real class and real money saved. I am not dismissing it.
What actually catches the Coldcard class is runtime instrumentation, not review: a boot self-test that asserts the TRNG was read during seed generation and fails loudly if it contributed nothing. That is a different discipline, rarely commissioned, and nobody sells it as a scanning product because it requires the device.
And the user-side version of the same idea, which is why I keep repeating it: dice. printf '<rolls>' | sha256sum compared against the entropy hex the device displays proves your rolls were used and nothing else. It does not test the RNG — that is impossible from outside — it removes the RNG from the trust chain. That works whether or not anyone audited anything.
On the marketing point in the post: probably fair, and it can be simultaneously true that he is good at promotion and that the scanning is worth doing. The thing to be skeptical of is not the service, it is the inference that this class of tooling would have caught the thing that just happened. The vendor already ran that experiment.
Worth calibrating what this kind of scanning buys, because the Coldcard bug is a useful negative example and the vendor said so themselves.
Their own AI-assisted review, weeks earlier, missed it. That is in Coinkite's technical backgrounder, and they were blunt about it: both sides have the same tools, and this time it helped the attacker and not them. So "AI scanning finds vulns" and "AI scanning would have found this vuln" are different claims, and the second one has already been tested and failed.
Why this particular bug is scanner-resistant. Read the wallet's own source and you see a call to a random-bytes function from a crypto library. It looks correct. It is correct as written. The defect is which implementation that name binds to at build time —
ngu.random.bytes()resolving to MicroPython's software fallback instead of the hardware RNG, inside a submodule. The vendor's phrasing: the PRNG "is from a submodule that I didn't know was actually in the source code base."A scanner pointed at the application repo sees correct code, because the code is correct. The bug lives in the resolution, one layer down, in a dependency nobody listed as security-critical.
And the output gives you nothing. This is what makes RNG bugs a category of their own. Feed well-seeded and badly-seeded CSPRNG output into dieharder, NIST STS, any entropy estimator — both pass. A PRNG's entire job is producing output that looks random. There is no test on the bytes that separates 40 bits of real entropy from 256.
What the $10k does buy, and it is genuinely worth having: memory safety, injection, auth logic, key handling mistakes visible in the code under review. That is a real class and real money saved. I am not dismissing it.
What actually catches the Coldcard class is runtime instrumentation, not review: a boot self-test that asserts the TRNG was read during seed generation and fails loudly if it contributed nothing. That is a different discipline, rarely commissioned, and nobody sells it as a scanning product because it requires the device.
And the user-side version of the same idea, which is why I keep repeating it: dice.
printf '<rolls>' | sha256sumcompared against the entropy hex the device displays proves your rolls were used and nothing else. It does not test the RNG — that is impossible from outside — it removes the RNG from the trust chain. That works whether or not anyone audited anything.On the marketing point in the post: probably fair, and it can be simultaneously true that he is good at promotion and that the scanning is worth doing. The thing to be skeptical of is not the service, it is the inference that this class of tooling would have caught the thing that just happened. The vendor already ran that experiment.