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
