Hi all,
While working on VEX statements for the current Apache Solr release, I
noticed that the existing security page contains a lot of valuable
information—but it may be hard for users to quickly identify what's
relevant to them.
Some pain points I encountered:
- The page lists the 15 most recent CVEs affecting Solr or exploitable
third-party dependencies. This limit feels somewhat arbitrary. At the
moment, it includes all CVEs impacting Solr 9.x, but as new issues are
disclosed, relevant ones could drop off, potentially hiding important
information from users.
- For users of a specific version (e.g., 9.8.1), it's not immediately
obvious which vulnerabilities apply to them.
- It's great that older versions (as far back as 5.x) are still
evaluated against new security reports. However, it's not clear whether
a version has been explicitly marked as `not_affected`, or simply not
assessed.
- VEX justifications must be brief and don't allow Markdown formatting,
which makes it difficult to provide full reasoning or enough context for
users to independently verify the `not_affected` status.
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.
Metadata Organization
---------------------
After reviewing how Pelican handles content, it appears that all of the
proposed enhancements could be automatically generated from structured
source files—similar to those already present in the
`content/solr/security` directory.
Specifically, using Markdown files with YAML front matter would align
well with Pelican’s capabilities. This format is already used for the
current CVE descriptions and would require little to no change to
existing workflows.
The main improvement would be for the VEX entries, which are currently
stored as JSON. Migrating them to Markdown with YAML front matter would
make them easier to maintain, more human-readable, and better suited for
generating richer output formats (tables, filters, etc.) directly within
the static site.
What do you think?
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
