I've revamped (and scaled back) the initial work in https://github.com/apache/solr-site/pull/153 that Piotr did and have merged it so you can see it in staging:
https://solr.staged.apache.org/security-dependency-cves.html Click the title to see a HTML view. Here is an example of one with both structured data and freeform data: https://solr.staged.apache.org/vex.html#cve-2024-51504 Now each VEX file is maintained as a markdown file in https://github.com/apache/solr-site/tree/main/content/solr/vex and we are building both a html view and a CycloneDX 1.6 based VEX file that can be downloaded by security scanners. I am hoping that as we receive reports of various CVEs in our dependencies, that we can use this to assess the vulnerablity of Solr with the specific dependencies and communicate it out to the community. I know that this remains a rather manual process, but at least we can take the groundwork already done with using VEX and expand on it. On 2026/06/06 12:46:13 Eric Pugh wrote: > I had a nice chat with Piotr last week about his work. I've updated his > draft PR to take into account the recent refactoring work that was done on > the security pages. > > I'm working on finishing the spike to move to just using the markdown files > to power both the vex formatted json files that we provide to security > scanners AND to generate the html. > > My goal is to get something that is potentially committable that we could use > to manage and publish the VEX files on a regular basis. I'm still kind of > sussing out how popular VEX files are, and how much effort as a project we > need to put in to producing and managing them! > > On 2025/08/06 13:48:20 "Piotr P. Karwasz" wrote: > > Hi all, > > > > On 22.07.2025 16:18, Piotr P. Karwasz wrote: > > > Proposal > > > -------- > > > > > > To address these issues, I'd like to propose the following improvements. > > > I’d be happy to volunteer to implement them (pending feedback and > > > approval): > > > > > > 1. Add a Support Matrix Table > > > This table would clarify: > > > - Which release lines are actively accepting security reports, and > > > which are not. > > > - Which versions will consistently receive security-related metadata > > > (VEX, advisories), and which are covered on a best-effort basis. > > > - Which versions will receive actual security fixes. (While newer > > > versions may always serve as security updates for multiple older > > > versions, the associated upgrade risk varies: upgrading from 9.9.0 to > > > 9.9.1 does not offer the same risk as upgrading from 8.11.4 to 9.9.1) > > > > > > 2. Add a Version-Specific CVE Overview > > > For each minor version within 9.x add a concise table that: > > > - Lists only vulnerabilities contained (directly or via dependencies) > > > in that minor version. > > > - Separates CVEs that affect Solr from those that don’t—so users can > > > quickly identify and dismiss false positives generated by their security > > > scanners. > > > > > > 3. Move 8.x Vulnerabilities to a Separate Page > > > Since 8.x is EOL, displaying its vulnerabilities separately—with a > > > clear note about its support status—could help clarify expectations for > > > users still on older versions. > > > > > > 4. Create a Flat CVE Reference Page (Sorted by CVE ID) > > > A separate page listing all known CVEs (both affecting and not > > > affecting Solr) sorted by CVE ID would help users look up specific > > > advisories without needing to correlate by date or release. > > > > To illustrate the proposal, I’ve submitted PR apache/solr-site#153 [1], > > which adds a small `vex.html` page and the Pelican extensions needed to > > generate it from Markdown files with a YAML front matter. > > > > The prototype implements: > > - The version-specific *CVE overview* described in (2) above. > > - The flat *CVE reference page* from (4). > > > > The PR is in draft mode pending your feedback. If you can indicate which > > HTML page these elements should ultimately appear on, I can move them to > > their final location. > > > > At present, the security page feels crowded, as it contains: > > > > 1. Information on how to report security issues > > (I really appreciate the section on “reporting” vulnerabilities found > > by scanners, to prevent vulnerability disclosures bouncing back to > > you). > > > > 2. Information on how to use the VEX file. > > > > 3. The list of vulnerabilities. > > > > 4. A separate list of VEX statements. > > > > I’m wondering whether it would be clearer to split this content into > > dedicated pages, leaving `security.html` as an overview with links to > > the right section: > > > > - `security/reporting.html` – guidance for reporting issues. > > > > - `security/documents.html` – information on VEX and other documents (I > > also note the absence of SBOMs for Solr). > > - `security/cves.html` – the summary tables and per-CVE articles from > > the PR. > > > > What do you think? > > > > Piotr > > > > References: > > [1] https://github.com/apache/solr-site/pull/153 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
