In my locale, we always come to the conclusion in discussions that open source wallets are better than closed ones, obviously because they do not conceal surprises. But in the age of AI development in open source, if people don't see mistakes, AI will see them, which we witnessed (Coinkite wrote about the use of AI by intruders). If this vulnerability has not been found in the five years of its existence, it has given a false feeling that the code is perfect..
Of course, the developers are also to blame for making the low-entropy decision. But I think that all developers with open source code should not disdain unnecessary code reviews, both by their own specialists and by the most intelligent AI...
This vulnerability would be just as fast to find with AI if closed source, maybe even faster.
If I were analyzing the firmware of a closed source wallet, I'd have the AI disassemble it and look for where the HW TRNG was read and trace from there. In this case it wouldn't be read at all (or the code that did would be dead code), and so it would be obvious that it was vulnerable.
In a strange way the open source code was a distraction that hid the behavior because it mostly looked correct. After the theft reports but before the cause of this was known someone I was talking to mentioned pointing AI at it and I said "Might want to disassemble the firmware to make sure a build issue hasn't made this code get used (link to the fallback PRNG)" and "Challenge it to show you in the disassembly". --- it can be easy to get confused by misleading code but the binary is definitive. AI makes analysis of the binary much easier.
A useful lesson to extract from this is that especially now that we have AI these devices should be both reviewed from a source code *and* binary basis, because some vulnerabilities (like this one) would be more obvious from the binary. It's not an entirely new lesson-- e.g. in libsecp256k1 we've used binary level review (esp for things like timing sidechannels) but now its enough easier that it should be done regularly.
A good review approach would intentionally inject serious faults like this one, and make sure the review process catches it... with the hope that this implies if there were any unknown faults they'd be found too. With AI this could even be automated.