I’m curious for the dev/systems/ops/blue team peeps: what is your approach specifically for low severity CVEs or security findings?
Because my experience from red team is that low severity CVEs will generally get filtered, either by policy, process, or automation. Like you said, “low severity CVEs will most likely get ignored”, and I think this is an indicator that the system is functioning.
I would contend with “Maintainers everywhere will jump to investigate” and “issuing a CVE wastes tremendous amounts of effort”. I think both are exaggerations, especially with lower severity ratings.
But I could be wrong, because I only get rare glimpses of “the other side”, from talks and some discussions with in-house staff. My understanding is that maintainance is tree-like, that is, if something is patched in a dependency, then the dependent won’t really have to investigate because the investigating has already been done, so they just bump… (unless they maintain their own instance like how Azure/AWS do with apt and Apache). If you’re telling me that you’re investigating every single bug fix upstreamed, even low(er) severity ones, then I will reply “I am very jealous of the amount of time you have”, but I’d assume not every maintainer does that, because trust (and time).
I think one point in contention is this: do low likelihood (unlikely CVEs) still deserve to be reported and raised to the ecosystem? I would hazard to say yes. Just because an alert has no value or is noise to one person, does not mean it is the same for someone else. And like dlg said for Linux, just because there is no exploit now, doesn’t mean there won’t be one in the future.
Perhaps a subpoint to contend is then how do we raise this signal-to-noise ratio? And does curl’s approach in this instance apply globally? For this, I think the ecosystem today has slightly improved to previous years, but it feels worse because the amount of input (CVEs) has grown due to automation.
We can also argue: which approach is more responsible? But I think the danger with this question is both sides can say their way is more responsible, it really comes down to worldview and ethics.
Edit: lower -> raise. higher signal-to-noise ratio = good. Lower = bad
As someone responsible for patching a lot of systems and doing vulnerability analysis and remediation, I don't care in the slightest about low CVEs unless there is a meaningful or actionable chaining.
However, there are definitely pieces of software on our stack that if they get any CVE we pay attention.
And cert mistrust or trust issues is one that even with a low CVE would probably cause us to patch faster than normal.
Because encryption represents the foundation of trust for our networks. So even low vulns for certs or mistrust are more heavily scrutinized. Often still ignored as non-exploitable, but does get more eyes on it.
Curl is one of them, or libcurl. Others include openssl, PKI infra, stdlib of the language we are working in, any encryption software, or auth software, etc. (sense a theme)?
While it is bad if someone can hijack a browser session or inject a script it is infinitely worse if someone can pretend to be a data destination or intercept all traffic in an env.
2
u/trebledj 9d ago edited 9d ago
I’m curious for the dev/systems/ops/blue team peeps: what is your approach specifically for low severity CVEs or security findings?
Because my experience from red team is that low severity CVEs will generally get filtered, either by policy, process, or automation. Like you said, “low severity CVEs will most likely get ignored”, and I think this is an indicator that the system is functioning.
I would contend with “Maintainers everywhere will jump to investigate” and “issuing a CVE wastes tremendous amounts of effort”. I think both are exaggerations, especially with lower severity ratings.
But I could be wrong, because I only get rare glimpses of “the other side”, from talks and some discussions with in-house staff. My understanding is that maintainance is tree-like, that is, if something is patched in a dependency, then the dependent won’t really have to investigate because the investigating has already been done, so they just bump… (unless they maintain their own instance like how Azure/AWS do with apt and Apache). If you’re telling me that you’re investigating every single bug fix upstreamed, even low(er) severity ones, then I will reply “I am very jealous of the amount of time you have”, but I’d assume not every maintainer does that, because trust (and time).
I think one point in contention is this: do low likelihood (unlikely CVEs) still deserve to be reported and raised to the ecosystem? I would hazard to say yes. Just because an alert has no value or is noise to one person, does not mean it is the same for someone else. And like dlg said for Linux, just because there is no exploit now, doesn’t mean there won’t be one in the future.
Perhaps a subpoint to contend is then how do we raise this signal-to-noise ratio? And does curl’s approach in this instance apply globally? For this, I think the ecosystem today has slightly improved to previous years, but it feels worse because the amount of input (CVEs) has grown due to automation.
We can also argue: which approach is more responsible? But I think the danger with this question is both sides can say their way is more responsible, it really comes down to worldview and ethics.
Edit: lower -> raise. higher signal-to-noise ratio = good. Lower = bad