Hacker News new | ask | show | jobs
by gulbanana 992 days ago
Both of those things are true. Many CVEs are unimportant, but serious security vulnerabilities do exist, and are very hard to avoid entirely when writing C.
2 comments

The CVE severity scores kind of make sense in absolute (Daniel's post clearly shows that this isn't always the case) but many companies have an inelastic, inflexible, unthinking approach to them which really frustrates our effort to prioritize actually relevant stuff.

A CVSS 10 on a log4j library sitting unused in a folder, shipped with an app that isn't even running, should not have prio over an unauthenticated RCE on an internet-facing service without even a WAF in front of it. But hey, that's only a 9.2. Try having this discussion with an auditor. (I don't want to lump all auditors together - I have ~12 years of collaboration with them and met some excellent ones - typically the ones we lose after a short time because they're wasted on us. And then there are those who just want to see a documented risk acceptance and will happily tolerate some criminally insecure or stupid shit).

> And then there are those who just want to see a documented risk acceptance and will happily tolerate some criminally insecure or stupid shit

The job of an auditer isn't to make you secure, its to make sure you aren't lying about implementing your security policies. If your policies are stupid, all they are going to do is ensure you follow your stupid policies.

And as much as c sucks, very serious vulns still exist even when using memory safe languages. There is no magic way to prevent all security issues.
Even memory safe languages do not technically eliminate all memory issues but they significantly reduce the amount of code you need to audit for memory issues.

You have no magical way of removing all memory security issues but you can definitely reduce the chance of one occurring by picking one of those memory safe languages.

The less time you have to spend on checking every piece of code memory allocations the more time you can spend on checking business logic for logical errors.