Hi Piotr, I've a few questions below, but don't read any of those as casting doubt on the overall idea. By and large, this all sounds great! I'd be happy to review them if you're still willing to implement.
Questions: 1. You mention towards the end of your email the idea of migrating the VEX entries to Markdown (possibly with YAML). Is that a popular format for VEX files and tooling? Do we lose anything by migrating away from JSON, or is there no real issue there? 2. Do the VEX entries themselves contain the data necessary to generate the website features you proposed. Maybe I'm just missing something, but at a glance I'm not seeing some of the data in the VEX file that it seems like you'd need for the website: e.g. Solr version information? Best, Jason On Tue, Jul 22, 2025 at 10:19 AM Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
