I wanted to share an update. I've been learning a lot more about VEX, and been adding more VEX statements using our markdown syntax: https://github.com/apache/solr-site/tree/main/content/solr/vex
I've been creating them using a combination of Googling, LLM, test code based on one of my clients key specific requests. They have been bringing up CVE's in dependencies that their security office is flagging, and then I'm digging into it. So very reactive, and yes, very manual. You can see the current published list here: https://solr.apache.org/security-dependency-cves.html I'm learning that we probably need a process to review the VEX statements as releases are made and dependencies are updated to make sure they are accurate over time. For the immediate future, I'm happy to own that. I've been digging into the OpenVEX format (which is not the one we currently use) as it works with docker scout commands to suppress CVE that are flagged if you give it our vex file. https://github.com/apache/solr-site/pull/204 is the actual code and https://github.com/apache/solr-site/pull/205 is tightening up the versions of solr and a specific jar that Solr uses to produce the OpenVEX format. It's cool to run docker scout with and without our vex file and see the number of CVE's change! In PR 204 you will of course see how I am struggling to figure out how to map specific jars to specific versions of Solr... If anyone has some good ideas, I'm all ears. It's currently a working, but also way to brittle, approach. Eric On 2026/04/20 12:34:58 David Eric Pugh via dev wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
