| 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. |