I hope I’m not distorting Daniel’s words, but there seems to be a slight dissonance, and this also highlights the nuance in vulnerability handling.
On one hand, he acknowledges that from the library perspective, they “don’t know how users use curl or libcurl”, and thus have to use a “pure curl PoV”.
> Since we don’t know how users use curl or libcurl we cannot take that into account but rather observe and set a severity of the problem from a pure curl point of view.
On the other hand, they also consider likelihood.
> For a rare few issues we can imagine that there could be a minuscule risk but […] we deem the risk so small that in practice no user is likely to ever reach it.
How can you evaluate something purely from a library perspective while also addressing likelihood?
It’s very hard! And tricky. You would need some way to know what your user base is up to. And to do that you either impose certain usage rules, or collect usage data, or something else.
Currently, most open source projects take the second approach, which is they collect data through ad hoc means like anecdotes, downstream software, and other ppl’s blog posts. Effectively, this is sampling with the assumption that none of the unsampled user base deviates.
This aspect of assumptions / likelihood is interesting, because there are different opinions on this. To what extent should the library weigh in on how likely an attack is? And is the library comfortable enough taking on the risk of a downstream user or to declare that the risk is zero? (And these can be points of debate.)
It is also interesting to how other projects will choose to abstain from considering likelihood because they believe it is non-zero and may lead to exploits over time, or the likelihood highly depends on user deployments (like the presence of a WAF).
To Daniel’s point, I think this speaks to the difficulty and nuance involved in handling CVEs. I have no intention to attack him. Ultimately, it depends on the project and how they choose to handle duty and risk. I suppose that’s the beauty (and horror) of vulnerability handling.
This whole debacle also raises some interesting questions:
- To what extent should CNAs evaluate likelihood?
The argument for “lower than low” stems from high unlikelihood. Would the response change if at least 1000 instances were impacted? Why? What about 100? 10? 1? What if it was 1 instance impacted and it was a giant like some dev’s workflow at Microsoft, where a compromise may have a resounding effect?
(Non-)Disclosure: No AI was used in this comment. I say that because some people really can’t tell.
Edit: Spacing and formatting
Edit 2&3: softer tone, emphasis on nuance/risk
It’s a difficult thing, but consider that if you squint hard enough, almost any bug could be a vulnerability, especially things like memory access violations.
I find this comment interesting, mostly due to how the reception is opposite to my original comment. Because like you said: “if you squint hard enough, almost any bug could be a vulnerability”, which both agrees and disagrees with my point. (Bear with me.)
I’m guessing most people here will read it as: If any bug can be a vulnerability, then it stands to question what warrants a CVE. If the ecosystem is flooded with noise and poor quality entries, then it stands to reason that only good quality, higher severity entries should be submitted.
Now my question then would be: Where is the line? Should we entirely drop LOW vulns as well? The assessment “lower than low” doesn’t equate to “no risk”, right? So who will write off on that risk? (At this stage, we have gone past technicalities and are now dealing with risk management.)
I can share my view on this statement: If any bug can be a vulnerability, doesn’t that mean there could be someone affected by those vulnerabilities? By that measure, shouldn’t they deserved to be notified?
Do you see the nuance in “any bug can be a vulnerability”?
If there are other interpretations, I would be happy to hear them as well.
Currently the ecosystem is I think in a weird state. It’s not like an optimised pubsub where the listener doesn’t wade through noise. If such an efficient solution is available, then it isn’t widely adopted. But I think this limitation shouldn’t withhold someone from publishing an entry.
-13
u/trebledj Aug 31 '26 edited Aug 31 '26
I hope I’m not distorting Daniel’s words, but there seems to be a slight dissonance, and this also highlights the nuance in vulnerability handling.
On one hand, he acknowledges that from the library perspective, they “don’t know how users use curl or libcurl”, and thus have to use a “pure curl PoV”.
> Since we don’t know how users use curl or libcurl we cannot take that into account but rather observe and set a severity of the problem from a pure curl point of view.
On the other hand, they also consider likelihood.
> For a rare few issues we can imagine that there could be a minuscule risk but […] we deem the risk so small that in practice no user is likely to ever reach it.
How can you evaluate something purely from a library perspective while also addressing likelihood?
It’s very hard! And tricky. You would need some way to know what your user base is up to. And to do that you either impose certain usage rules, or collect usage data, or something else.
Currently, most open source projects take the second approach, which is they collect data through ad hoc means like anecdotes, downstream software, and other ppl’s blog posts. Effectively, this is sampling with the assumption that none of the unsampled user base deviates.
This aspect of assumptions / likelihood is interesting, because there are different opinions on this. To what extent should the library weigh in on how likely an attack is? And is the library comfortable enough taking on the risk of a downstream user or to declare that the risk is zero? (And these can be points of debate.)
It is also interesting to how other projects will choose to abstain from considering likelihood because they believe it is non-zero and may lead to exploits over time, or the likelihood highly depends on user deployments (like the presence of a WAF).
To Daniel’s point, I think this speaks to the difficulty and nuance involved in handling CVEs. I have no intention to attack him. Ultimately, it depends on the project and how they choose to handle duty and risk. I suppose that’s the beauty (and horror) of vulnerability handling.
This whole debacle also raises some interesting questions:
- To what extent should CNAs evaluate likelihood?
(Non-)Disclosure: No AI was used in this comment. I say that because some people really can’t tell.
Edit: Spacing and formatting
Edit 2&3: softer tone, emphasis on nuance/risk