Thanks Piotr for updating me. I am brainstorming for a client what having a
long term support version of Solr might look like (more to come on that for the
community), and as we were discussing "what would the work look like (back
porting of CVE fixes etc) I suggested that having VEX files being created could
be in the scope of the work. This would make it part of someone 's day job to
product VEX files as part of their LTS work, which might help get this
initiative moving!
I suspect that there is a bit of chicken and egg.. Until security teams will
sign off on "no issue here" based on a VEX file, then impetus to produce them
will be limited. Do we know that VEX files are accepted by security teams in
liue of actual changes? I don't have a sense of if these files are becoming
"commonly used by industry" or if it's still something you are inventing.
This may be an interesting topic to workshop together at C/C in Glasgow in the
fall if you are there btw.
Eric
On Wednesday, April 15, 2026 at 09:43:30 AM EDT, Piotr P. Karwasz
<[email protected]> wrote:
Hi Eric,
I took a little pause from my self-appointed "Vexator-in-chief" position
after FOSDEM, but I am returning to the subject these days.
We have a fully working prototype automation:
https://github.com/vex-generation-toolset
which can be integrated into Solr via some additional workflows in
solr-site:
https://github.com/apache/solr-site/pull/163
The automation still has a lot of rough edges to smooth out, but it can
already create PRs like these:
https://github.com/vex-generation-toolset/solr-site/pull/1
https://github.com/vex-generation-toolset/solr-site/pull/2
Those are admittedly far from being as detailed as a handcrafted one:
https://github.com/apache/solr-site/pull/152
Beyond the limitations of the toolchain, however, the main challenge for
keeping the VEX file up to date is maintainer time. Since there are many
topics more interesting than assessing the impact of low- and
moderate-severity vulnerabilities on Solr, the automation must surface
the right level of detail to let maintainers quickly review a PR. It
also needs a low false-positive rate, which can only be achieved by
testing against each CVE as it appears.
One could argue that we should send all the details to an LLM for
evaluation these days, but security is too serious a topic to risk
hallucinations.
If anyone is available to review the two PRs above from the perspective
of what data is useful and what is not, I would be happy to put more
work into the VEX Generation Toolset.
The callgraph-metadata database [1], which contains all the data needed
to determine the reachability of a vulnerability, is currently
configured to track CVEs in the dependencies of Solr 9.10.0. I will
update it to follow Solr 10.0.0 shortly.
One related note: my PR to generate an SBOM for Solr from within the
build was closed due to inactivity:
https://github.com/apache/solr/pull/3929
Piotr
[1] https://github.com/vex-generation-toolset/callgraph-metadata
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
