Hi David,
W dniu 21.07.2025 o 00:28, David Smiley pisze:
I'm grateful for those involved in this initiative. I've spent time being
responsible for remediating **non-exploitable** vulnerabilities, which is a
waste of time plaguing our industry.
I completely agree. Addressing non-exploitable vulnerabilities also
drains valuable resources from Open Source volunteers.
The idea for this project actually came from user requests such as:
“Please upgrade `libfoo` to version `1.2.3` to fix CVE-2026-1234”
“When will `libbar` with the fix for CVE-2026-1234 be released?”
As a library maintainer, I found these kinds of questions frustrating:
users could simply upgrade the dependency themselves. I’ve even voted
against one release that included only dependency bumps with no code
changes: let's not enable this kind of expectations.
However, a conversation last year with the Apache Kafka team [1] shifted
my perspective. I realized:
- OSS *application* developers don’t have the option to ask users to
upgrade binaries distribution archives manually.
- The presence of CVEs, even non-exploitable ones, in transitive
dependencies can actually discourage adoption of a library. Ironically,
it's often “preferable” (from a CVE-handling perspective) to use
internal, unaudited parsers than high-quality third-party libraries that
happen to have CVEs.
In the Kafka case, we discovered that the SnakeYAML CVEs were already
non-exploitable within Jackson. So Log4j wouldn't even need to rely on
the “we only parse trusted configuration files” argument.
This is how we started this initiative: to save the time of downstream
OSS projects from handling non-exploitable vulnerabilities.
Once this project is over I would love to see security engineers
contributing VEX-es upstream to save their colleagues in other
companies/projects precious time (regardless if it is paid or
volunteered time).
Piotr
[1] https://lists.apache.org/thread/khm0jn9f0vgp30pfyoy6jc0qy46sbklp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
