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.
~ David On Thu, Jul 10, 2025 at 9:08 AM Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote: > Hi all, > > I'm happy to share that the VEX initiative I previously discussed with > the PMC on `private@solr` ([1], [2]) has now been approved. Over the > next six months, we'll be working to bring this initiative to life. > > Our goal is to make Vulnerability Exploitability eXchange (VEX) files a > practical reality in the open source ecosystem, starting within the > Apache Software Foundation. > > ### Why VEX? > > As many of you know, the upcoming **Cyber Resilience Act** will require > that: > > > Products with digital elements shall: > > (a) be made available on the market without known exploitable > vulnerabilities; > > For Solr integrators, simply publishing a Software Bill of Materials > (SBOM) is not enough. While SBOMs list all upstream dependencies and can > demonstrate the absence of known vulnerabilities at a specific point in > time, they rarely remain clean for long. In practice, maintaining a > vulnerability-free SBOM could require unscheduled Solr releases every > month or two—diverting valuable volunteer time that could be better > spent elsewhere. > > A more viable alternative is for Solr to demonstrate that it is free of > **exploitable** vulnerabilities. That’s where VEX files come in. > > A VEX file (such as the one Arnout and Jason maintain[3]) allows us to > assert that while a known vulnerability may exist in a dependency, it is > not actually exploitable in Solr. This means: > > * No emergency patch release is necessary. > * The issue can be resolved in the next scheduled release. > * Solr integrators remains compliant with future regulatory requirements. > * Solr retains its reputation as a secure, production-ready solution for > commercial users. > > ### The Challenge > > Unfortunately, creating and maintaining VEX files manually is difficult > and time-consuming. Determining whether a vulnerability is truly > exploitable often requires: > > * Identifying the exact method or code path involved. > * Tracing through multiple layers of dependencies. > * Ensuring reachability and exploitability conditions are met. > > In some cases, the effort may be comparable to that of cutting a patch > release. > > Our initiative aims to **automate** and **streamline** this process, > making VEX generation more efficient and reliable for Solr. If time > permits, we also hope to extend support to other ASF applications used > within Solr, such as Kafka, Hadoop, and ZooKeeper. > > ### Main goals > > Our initiative will develop a set of open source tools, licensed under > the Apache-2.0 License, and published under the vex-generation-toolset > GitHub organization[4]. These tools aim to support VEX generation for > Solr and potentially other ASF projects. The planned components include: > > 1. Java Call Graph Generator – An open source tool derived from > OpenRefactory’s commercial solution to analyze code structure and > generate call graphs. > > 2. Vulnerability-to-Source Mapper – An AI-assisted tool that identifies > the specific class or method responsible for a vulnerability, even when > that detail is missing from the CVE description. > > 3. Reachability Analysis Tool – A component that maps out the call > paths from Solr to the vulnerable code and stores the results in a > format to be defined. > > 4. VEX Report Generator – A tool that integrates the above components > and produces a report to assist Solr maintainers in drafting accurate > VEX statements. > > These tools will be developed by OpenRefactory, but suggestions are > welcome. > > On my end, I will focus on integrating this tooling into ASF > infrastructure generally, and Solr’s project automation specifically. As > some of you know, over the past year we’ve fully automated the release > process for Apache Log4j [5], making it one of the few ASF projects > approved for CI-based releases. > > With your collaboration, I’d like to bring similar automation to > Solr—especially around vulnerability management in third-party > dependencies—but we don't have to stop there. > > Since this is an experimental initiative, some details are still in > flux. However, I’m confident we can refine them as we move forward and > arrive at a solution tailored for Solr that’s reusable by other open > source projects as well. I’ll start by gathering your input here on the > mailing list, and for more security-policy-oriented discussions, on > `security-discuss@a.o`. > > Feel free to reach out to me on ASF Slack with any ideas, questions, or > requests. > > Best regards, > Piotr > > [1] https://lists.apache.org/thread/d0p3rgwf7mhltg2sxxmjz9s15clqffjf > [2] https://lists.apache.org/thread/1hypz5obxf22zc7tnhv668cyvpw799v2 > [3] https://github.com/apache/solr-site/blob/main/vex-input.json > [4] https://github.com/vex-generation-toolset > [5] > https://logging.apache.org/logging-parent/release-instructions-project.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
