Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In 2009 some classmates and I wrote a paper called "Security Impact Ratings Considered Harmful":

https://arxiv.org/pdf/0904.4058.pdf

The position is that using CVSS to decide which updates to take is a losing gamble. You don't have a good idea in advance of how easily something is exploitable, and trusting the CVSS scorers to say "oh, this particular out-of-bounds write causes a crash but isn't exploitable to run arbitrary code" is misplaced: they're not exploit developers and they're not spending time trying to build an exploit chain.

If you have a process for doing software updates, do them unconditionally, on schedule, and promptly, for all security updates and if possible all updates period. Don't "prioritize" the way this article and CVSS aa a whole encourages you to. Upstream developers are working and looking at the master branch only, and if a certain component got rewritten, it's entirely possible there's no white-hat attention on the old version ever again. And if you don't have a process—i.e., if you treat CVSS over 9 as a sign you should run around in a panic and figure out something ad hoc, and not care otherwise—the absolute best thing you can do for your security is to fix that.

In the course of writing the paper, we ran 'git log' on a recent Linux kernel release, found something exploitable that had no CVE at all, and developed a working exploit.



Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: