4 ms·
It's a double-whammy because not only do security vendors have an incentive to overstate scores, so do their researchers. I talk about it a little in the sectio
by jacques_chester 4y ago
It's a double-whammy because not only do security vendors have an incentive to overstate scores, so do their researchers. I talk about it a little in the section on comparing scores over several years.
One thing I didn't analyse that might be interesting would be to see if there's a consistent gap between security vendor / researcher reported scores in NVD and scores given to customers by their general software vendors.
- lmeyerov 4y agoI keep coming back to something like collaborative filtering Raw context-unaware scores may come from researchers, but 'real' scores are based on deployment context. So a vuln may have diff final scores based on context, and the community needs ways identifying which bucket they fall into. Likewise, there is probably an 80/20 for most libs in terms of use case, so a good bet on default bucket of typical personal profile might help further decrease overhyping for raw scores. CI vs Server vs Browser vs TCB vs ... . Ex: npm audit reports on dev dependencies by default, but a regex complexity attack there is less legit, yet that's where most of the alerts seem to be. Instead of pushing to the user, can push a use-adjusted score to the reporting tool, and user can pick sensitivities for both. Collaborative filtering is one way, and others as well. Without something like thay, scores are largely ungrounded FUD / box checking.