3 ms·
> might be able to do purchasing decisions based on used components, their CVE/etc. history, or sheer amount (in less being generally better, unless there is a
by jacques_chester 6y ago
> might be able to do purchasing decisions based on used components, their CVE/etc. history, or sheer amount (in less being generally better, unless there is a reason to suspect the vendor e.g. rolled their own TLS instead of using one of the usual suspects).
Counting CVEs is a poor indicator. It's not a pure function of how many vulnerabilities exist, it's a function of how many exist, are found and reported. Those latter two components have a strongly economic nature. It's cheaper to not search and report than be fastidious.
If anything, more CVE reports from a given company is a positive signal that they give a damn.
(There's also the problem that CVSSv3 is not a very sound measurement of risk. It's sorta-kinda just made up without derivation from a sound theoretical foundation, nor is it based on data about actual impacts. The scores don't move smoothly as a continuous function but jump around a fair amount. It's very easy to swing between widely-separated named categories with a bit of argumentation.)
- PowerBar 6y agoAgreed. For me CVE's serve 2 purposes. The first is to check if there are any known exploits in the currently-shipping version of a piece of software. The second is as a starting point in evaluating how the company, or community, responds to reports of exploits. I'll take a problem from a company that published software with an embarrassingly bad security hole that thanked the reported and issued a fix immediately over a company with a hard to exploit security problem that ignored initial reports, threatened public reporters, denied its existence, and dragged their heals when the public demanded they fix it.