Add workflows to generate and maintain VEX entries

[ppkarwasz]

This change introduces two GitHub workflows that partially automate the maintenance of the VEX file for Apache Solr by identifying relevant CVEs and assessing their reachability.

• check_cve Scans the components of a given Solr distribution for known CVEs. For each CVE that does not yet have a corresponding VEX entry (and is not already covered by an open PR), the workflow automatically triggers generate_vex with the appropriate parameters.

• generate_vex Analyzes the reachability of a specific CVE using metadata from the callgraph_metadata repository and determines whether the vulnerability can impact Solr.

Together, these workflows reduce the maintenance effort of maintaining the VEX file.

[ppkarwasz]

I have tested both workflows (specifically in the vex-generation-toolset fork of this repo; see, for example, vex-generation-toolset#1 and vex-generation-toolset#2) to validate their behavior.

A few important notes on the current state:

• The workflows depend on data being available in the callgraph metadata repository maintained under the vex-generation-toolset org: https://github.com/vex-generation-toolset/callgraph-metadata. That repo contains call graphs for most Apache Solr 9.10.0 dependencies, but there are gaps (e.g., Scala- and Kotlin-based artifacts and some code-generated artifacts are not currently included).
• We (@openrefactorymunawar and I) are actively maintaining that repository and adding CVE root causes as they are disclosed. At the moment there is a manual review step before inclusion, but we are considering maintaining separate reviewed and unreviewed branches to improve iteration and automation.

As a result of the above, the generate_vex workflow can sometimes fail due to missing metadata: this is an expected limitation at this stage, not a flaw in the workflow definitions themselves.

Since this would be the first upstream deployment of the tooling, it’s likely that users will encounter bugs or limitations. For example, the reachability analysis run in vex-generation-toolset#2 was not able to detect exploitability for CVE-2025-54988 (PR #162) due to the underlying graph data.

Request for feedback:

• Does the project feel comfortable adopting these workflows in the current form given the external data dependency?
• Should we provide guidance or fallback behavior for missing metadata (e.g., skip with warning vs. fail)?
• Are there suggestions for first-class integration of call graph data into the Solr project process or tooling?

Happy to iterate on this based on feedback from the community and reviewers.

[dsmiley]

Overall I love the direction.
It's not clear to me when these GHA workflows should/need to be run?

I think adopting this requires more/better documentation holistically on VEX and the nature of these files/directories in the website repo. Okay to link elsewhere of course but still.

[dsmiley]

purl?

[ppkarwasz]

Yes, we need the Package URL of the vulnerable component to find it in the SBOM.

Vulnerability databases (especially GitHub Advisories) should have that information for each CVE, but the quality of those records varies.

[ppkarwasz]

Hi @dsmiley,

Thank you for the feedback. I'll better document the formats used by the various components and link to them from this PR.