Hi all, We ran out of time to cover this in today’s meeting, so I wanted to follow up on the mailing list.
TL;DR: I would greatly appreciate reviews of these three PRs: [1], [2], and [3]. Over the past months I’ve been vexing (pun intended 🙂) the Solr community about improving how we maintain Solr’s VEX file. For anyone new to the term: a VEX (Vulnerability Exploitability eXchange) document is a machine-readable statement describing whether a vulnerability in a third-party dependency used by Solr is actually *exploitable* in Solr or not. In practice, most reported dependency CVEs turn out to be *not* exploitable, yet they still generate user questions such as: - “Please upgrade libfoo to 1.2.3 to remove CVE-2027-1234.” - “When will Solr release a version that remediates CVE-2027-1234?” Answering these repeatedly consumes maintainer time that could be better spent elsewhere. Solr was one of the first OSS projects to publish VEX information back in 2023 ([4]), but today that file is maintained manually. In December we completed an Alpha-Omega funded project delivering a toolset that can automatically determine whether a vulnerable method is *reachable* from an application and, if so, provide the call paths. While this does not fully decide exploitability, it drastically reduces the work required to make that assessment. We described the toolset at FOSDEM ([5]), and I also prepared a short deck for today’s meeting ([6]) describing the proposed Solr integration. To start integrating this into Solr, I’m proposing: 1. Generate SBOMs for Solr releases PR [1] adds SBOM generation during the Solr build. These SBOMs are used as inputs for reachability analysis. 2. Automatically propose VEX updates PR [2] adds a workflow to solr-site that consumes pre-generated metadata (enriched CVEs and call graphs) and opens PRs against Solr’s VEX file whenever new vulnerabilities appear. 3. Make VEX information more useful to humans PR [3] reorganizes the Security pages so users can easily see: - Which CVEs affect supported Solr versions - Whether they are exploitable or not - How to remediate them If you could take a look at PRs [1], [2], and [3] and share any feedback, that would be greatly appreciated. Also, if you run into user questions about the exploitability of specific CVEs, feel free to ping me (ASF id: pkarwasz, GitHub id: ppkarwasz). Thanks for being the test subjects for the VEX Generation Toolset: you more or less brought this on yourselves by being one of the few projects that actually publishes VEX already! 🙂 Best regards, Piotr References: [1] https://github.com/apache/solr/pull/3929 [2] https://github.com/apache/solr-site/pull/163 [3] https://github.com/apache/solr-site/pull/153 [4] https://solr.apache.org/security.html#vex [5] https://fosdem.org/2026/schedule/event/NLCRCU-integrating-vex-into-oss/ [6] https://docs.google.com/presentation/d/1wKS_p__cJi_mgSvaudF0kzdjayEsvu4vvWNQnTB9xSA/edit?usp=sharing --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
