Hi Vladimir, [Context:
This thread originated from a pre-announcement of an early draft of the VEX Generation Toolset project [1], which proposed generating VEX documents across 17 ASF PMCs and was initially shared on `private@` lists. The final scope of that effort ended up being narrower and focused on Solr. In parallel, Gary and I started producing VEX documents in Commons for CVE-2025-48924 [2], and I used the resulting Commons Text -> Commons Configuration VEX chain to justify the non-exploitability of CVE-2025-48924 in Apache Solr [3]. Now that the Alpha-Omega–funded project details are public, I think it makes sense to continue the discussion on `dev@solr` (Solr arguably has the first and most complete VEX in the ASF so far). I am also Cc’ing `dev@commons`, as the discussion touches shared dependencies.] On 15.12.2025 10:25, Vladimir Sitnikov wrote: >> Piotr: Logging configuration files must come from trusted sources. >> The CVE is not exploitable > > Piotr, sure "logging configuration must come from trusted sources" > is a way better wording, however, in practice, a second CVE like > "arbitrary file overwrite" might allow malicious users overwrite the > logging configuration, and exploit the "unexploitable" SnakeYAML CVE. > > At the same time, a mere presence of vulnerable SnakeYAML on the > classpath creates a gadget which might help attackers. Good point. Vulnerabilities are not isolated, and assessing the impact of a vulnerability in (say) Commons X on Apache Solr requires a broader view. Concretely, we need to show: 1. Reachable call paths from Apache Solr to Commons X. This is something we can already do; I am currently wrapping things up to propose automating this step in Solr via a PR to `solr-site`. 2. All VEX documents produced by dependencies on those reachable call paths. 3. Any remaining VEX documents produced by Solr itself, scoped to the specific Solr version. This makes it clear that we are still early in the VEX journey. Nevertheless, I remain convinced that, with appropriate automation, this approach is significantly less costly than encouraging applications like Solr to cut new releases every time a CVE is disclosed in one of its 400+ dependencies. We have all seen the CVE trend: over 46k CVEs this year, compared to approximately 6.5k in 2015. I suspect many of us share a reluctance to ship a new release solely because Dependabot raised another alert. >> For example all the application that use Log4j Core don't need to >> worry about SnakeYAML vulnerabilities > > I am afraid that "don't need to worry" provides a false sense of security. > > The security review of an application can't rely on Logging's > "unexploitable" conclusion, and they still have to analyze if the > vulnerability is truly unexploitable in their app setup or not. > > I would rephrase that as "if SnakeYAML is only reachable via log4j, > then read CVE-2022-1471 as if it was <<logging configuration must > come from trusted sources>>". > > VEX helps analyze the CVEs, however, it does not reduce the number > of items to review. The app developer would still have to analyze if > the problematic codepath can be reached in their app including > reflection, etc. That makes sense, and it further convinces me that starting with call-path discovery was the right choice for the Alpha-Omega project. With that in place, each CVE in a third-party dependency can be handled as follows: 1. Not reachable: Upgrade to the fixed dependency version at your convenience (e.g., after direct dependencies have done so), without perturbing the release schedule. 2. Reachable but contextually non-exploitable: Examine the call path(s) and dependency-provided VEX documents to determine exploitability in the application's context. 3. Reachable and exploitable: Evaluate whether the impact justifies upgrading before direct dependencies have confirmed compatibility. 4. Log4Shell-class issues: Upgrade immediately. If unit tests pass, users will likely forgive occasional breakage in rarely used functionality. Thanks for the thoughtful comments. Piotr [1] https://github.com/vex-generation-toolset [2] https://lists.apache.org/thread/b1ckyw1fg36v6mh8n6wx5vdsj6gxkdfx [3] https://github.com/apache/solr-site/pull/152 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
