One thing that I think sometimes gets forgotten when discussing security patching, CVE's, and upgrades is that the whole point of security patching is to *avoid an incident that creates an unexpected cost* for the company deploying the software. However, every deployment and every upgrade contains a risk of unforeseen consequences and also presents a risk that it will create an incident that creates an unexpected cost.
On Wed, Dec 17, 2025 at 3:46 AM Piotr P. Karwasz <[email protected]> wrote: > 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] > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
