SOLR-18193: Restructure security pages and add reporting workflow

[janhoy]

What changed and why

The single security.html page has been split into three focused pages sharing a common subnav:

Page	URL	Purpose
Security	security.html	Hub page: report guidance, scanner dos/don'ts, 5 recent CVEs
Vulnerability Reporting Procedure	security-reporting.html	PMC procedure, workflow diagram, canned email responses
CVE Status for Dependencies	security-dependency-cves.html	VEX explanation, full dependency CVE table, VEX download

A new security-news.html page provides the full paginated history of CVE advisories (previously
inlined on security.html), accessible as a sub-tab of the main News section.

Content preserved from the original page

All substantive content from the original security.html has been carried over. Check the diff for content that have been removed and make a comment if you feel we have lost something important.

New content requiring review

The following content is entirely new and was not on the original page. Please review carefully:

1. Canned email response templates (Responses A–E) on security-reporting.html — these are
   intended for PMC members to copy-paste when replying to incoming reports. Review tone, wording,
   and whether any scenarios are missing or handled incorrectly.

2. Workflow diagram (security-vuln-process.png) — a draft flow diagram is included;
   Verify the flow accurately reflects how the PMC operates. An SVG version of this diagram
   can also be checked into the repo.

3. Stated timeframes — the page now publicly commits to "up to 7 days" for initial triage
   and "up to 30 days" for investigation. Confirm whether we are comfortable with these being on
   the public website (they are framed as best-effort, not guarantees).

4. ASF Security Team as CNA — explicitly stated as the body that allocates CVE IDs.

Technical changes

• combined_posts plugin extended with SecurityNewsGenerator to produce security-news.html
• Markdown toc extension configured with permalink=True globally (adds ¶ hover anchors to
  all page headings site-wide — verify no unintended visual regressions on other pages)
• posts.html subnav gains a "Security News" tab

Screenshots:

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Restructures the Solr security content into a hub page plus dedicated sub-pages for security advisories, dependency CVE/VEX status, and vulnerability reporting workflow.

Changes:

• Refactors security.html into a hub with “recent advisories” + links to new pages.
• Adds new pages/templates for security news history, dependency CVE/VEX table + download, and a reporting procedure page.
• Extends the Pelican generator to produce paginated security-news*.html, and updates navigation.

Reviewed changes

Copilot reviewed 13 out of 14 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
themes/solr/templates/security.html	Converts security page into a subnav-based hub, shows 5 recent advisories, links to new pages
themes/solr/templates/security-reporting.html	Adds reporting page wrapper (subnav + styling) for markdown-driven content
themes/solr/templates/security-news.html	Adds a paginated “Security News” listing template (with RSS link)
themes/solr/templates/security-dependency-cves.html	Adds dependency CVE/VEX page template with VEX download button + CVE table
themes/solr/templates/posts.html	Adds “Security News” tab to the news subnav
plugins/combined_posts/init.py	Adds SecurityNewsGenerator to build paginated security news pages
pelicanconf.py	Enables markdown TOC permalinks with headerlink class + title
content/pages/security.md	Rewrites security page copy to match new structure and link out to sub-pages
content/pages/security-reporting.md	Adds full vulnerability reporting procedure, workflow figure, timeline table, canned responses
content/pages/security-dependency-cves.md	Adds VEX explanation prose for the dependency CVE status page
SOLR_SECURITY_WEBSITE_PLAN.md	Adds an implementation plan / design notes for the security site restructuring
CLAUDE.md	Adds repository guidance for Claude Code usage
.claude/settings.local.json	Adds Claude local tool permissions configuration

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[janhoy]

Pending discussion whether we want to open a private JIRA for each accepted report, or just use the mail thread for tracking purposes (and reminder emails from ASF security).

[gus-asf]

This perhaps should be thought of in terms of an "incident response plan" I just participated in a presentation/discussion about such things, but need to work late tonight. I'll definitely try to look at this PR this weekend

[janhoy]

Same comment as elsewhere pending our decision as to whether open a private JIRA for each in-flight vulnerability report.

[epugh]

I think this reworking is great. The security-vuln-process.png looks awesome... I did have luck in using Mermaid in the Ref Guide in this unmerged PR apache/solr#2783 to generate diagrams from plain text. Which is nice in editing it.

One thought, should some of this "process" related documentaiton just be added to the Ref Guide? Would that reduce the burndon in maintaining any of this?

[janhoy]

I think this reworking is great. The security-vuln-process.png looks awesome... I did have luck in using Mermaid in the Ref Guide in this unmerged PR apache/solr#2783 to generate diagrams from plain text. Which is nice in editing it.

Yea, my plan is to check in the SVG as the editable artifact.

One thought, should some of this "process" related documentaiton just be added to the Ref Guide? Would that reduce the burndon in maintaining any of this?

I think ref-guide is product, website is process, not? But feel free to suggest something.

[gus-asf]

I think this reworking is great. The security-vuln-process.png looks awesome... I did have luck in using Mermaid in the Ref Guide in this unmerged PR apache/solr#2783 to generate diagrams from plain text. Which is nice in editing it.

One thought, should some of this "process" related documentaiton just be added to the Ref Guide? Would that reduce the burndon in maintaining any of this?

The web site seems like the right place for this. One would not normally open up a ref guide to find out how the project wants to handle security stuff.

[gus-asf]

Suggested change

	## CVEs in Dependencies Detected by Scanners
	## Incident Response Plan
	All Apache projects follow the process [outlined by the Apache Software Foundation](https://www.apache.org/security/committers.html). Although this is not specifically labeled as an IRP, it covers most of the key topics including how to report, who's responsible, where to discuss the issue privately and the appropriate means, tools and venues for disclosing the CVE and the fix. The [reporting procedure page](security-reporting.html) further refines that policy. If you feel there is ambiguity or conflict between these pages, or need clarifications feel free to mail the [public mailing lists](community.html) to discuss it (**do not** mail security@solr.apache.org)
	## CVEs in Dependencies Detected by Scanners

[janhoy]

A problem with the previous security page was that it used way too many words to describe things, and had too much non-essential information right there on the main security page.

Counter-suggestion:

On the security-reporting page, remove the sentence

"For PMC members, the ASF provides detailed committer guidance on vulnerability handling.

And insert an IRP paragraph instead. But make it much shorter than your original:

## Incident Response Plan

Apache Solr follows the [Apache Software Foundation's security process](https://www.apache.org/security/committers.html),
which covers reporting, responsibility, private discussion, and CVE disclosure in detail. 
The rest of this page details this plan for the Solr project.

[gus-asf]

I think it is important to direct questions to the lists, but otherwise this looks fine

[gus-asf]

Overall this is a fabulous improvement. Few suggestions.

[janhoy]

I think this reworking is great. The security-vuln-process.png looks awesome... I did have luck in using Mermaid in the Ref Guide in this unmerged PR apache/solr#2783 to generate diagrams from plain text. Which is nice in editing it.

I took your lead here and converted the diagram (erhm, not me but Claude) into a mermaid diagram, rendered by a JS plugin. Also, the diagram took a lot of vertical space, so it is now simplified to not show every single step, but the main branches. And it's editable as mermaid source directly in security-reporting.md source file.

[epugh]

I think ref-guide is product, website is process, not? But feel free to suggest something.

I've sometimes wished our Developer Docs were in the Ref Guide, but maybe that is metrying to jam too much into one thing. Maybe the "How to report security" should be in the Developer Docs too. Except then no one will see them.

So... I think my tl;dr; is that yeah, this PR looks great and moves us forward!