[UweSchmidt]

Maybe it's time to take a closer look at reality and correct this meme, which might casually blur the issue and deflect responsibility?

Looking at the IT security landscape we see every layer, every product category if not every product itself riddled with issues at one point or another. At the same time the incentives to put those security issues in are huge, and we know attackers work systematic, creative and persistent to introduce those weak points.

Security is hard and many bugs certainly happen due to mistakes, but I wouldn't assume that all of those security mishaps stem from an endless series of blunders from "stupid" programmers.

So I would go with “Never attribute to ignorance that which is adequately explained by malice.”

[hnlmorg]

> I wouldn't assume that all of those security mishaps stem from an endless series of blunders from "stupid" programmers.

The saying doesn’t mean that all vulnerabilities are blunders. It means we shouldn’t automatically assume vulnerabilities are nefarious.

If closer inspection proves beyond reasonable doubt that it was placed there deliberately and maliciously then that’s different.

But the point is most vulnerabilities are blunders so it’s better to assume that until proven otherwise.

[UweSchmidt]

It's usually not possible to prove that something was put in deliberately and maliciously, so that puts the bar very high. We know it for sure in some of the supply chain attacks, and should assume that other kinds of bugs are being introduced by malicious actors across the board, rather than to risk downplaying the issues to "just blunders".

[hnlmorg]

It’s actually quite easy in most cases:

1. You can generally get a feel for the intent by the developers reputation.

2. Look at the code that changed as part of the same commits. Eg was the vulnerable code included as part of the same commits as an unrelated change elsewhere in the codebase? If the latter then that’s hugely suspicious.

3. How is that vulnerability encoded? Eg is a bug parsing logic that was discovered via fuzzing? Or is it obfuscated code? Clearly the latter demonstrates intent.

4. What’s the nature of the vulnerability? Is it simply a dumb unhandled bounds or allocation error in C? Or is there an entire path of code that opens network ports? The latter also demonstrates intent.

5. How did the authors behind the vulnerable code react to the big report? Did they rush a patch out? Write more robust tests? Work with the community? Was there any transparency? Or was the issue quietly brushed over? This is least reliable indicator but it does demonstrate trustworthiness.

With these and other indicators you can build a body of evidence that can make an argument for or against a particular vulnerability being malicious. And while I do agree that in some cases it isn’t going to be clear cut, in most cases the evidence, or lack of, will be enough to justify an opinion.

The key part of my earlier statement being “beyond reasonable doubt”. Ie I’m not talking about a mathematical proof here.