Re:Critical vulnerability of NPM package macaddress
by f055 on Monday June 11, 2018 @02:24PM
(#17286933)
I think comparing is pointless. You are correct that a project with a small number of vulns is no more secure than the one with a high number of vulns. But counting seem sensible - if a project spills major vulns at a continuous rate it means two things: the overall codebase is not improving, and who knows how many more vulns there are. It's not something to be happy about.
Re:Critical vulnerability of NPM package macaddress
by staticassertion on Monday June 11, 2018 @03:04PM
(#17287411)
I disagree for exactly the reasons I've stated - "more vulns" doesn't take impact into account. "More vulns" doesn't take who is reporting them into account (internal? paid pentester?). These things matter a lot.
Again, look at projects that pay for vulns. They have hundreds a year - this is a good thing. They come in at a continuous rate.
Counting is pointless.
As an example, lots of projects have active bug bounty programs where they pay people to disclose vulns. This generates more CVEs than a competing product that does not pay for more vulns. Would we then call the project with a bug bounty program less secure? I'd hope not.
Alternatively, what about impact? Maybe 100 DOS's is less serious than 5 RCE's, or 10 privescs is more serious than 1 RCE? How do we convert between these severities to understand risk?
Counting vulns is pointless.