SOLR-18193: Restructure security pages and add reporting workflow

.gitignore

@@ -7,3 +7,10 @@ __pycache__
 output
 .idea
 env
+
+# AI Coding Assistants, we only want AGENTS.md checked in
+CLAUDE.md
+.claude/
+.cursor/
+GEMINI.md
+.gemini/

AGENTS.md

@@ -0,0 +1,72 @@
+# AGENTS.md — Apache Solr Website
+
+This file helps AI agents understand the repository structure and workflow.
+
+## What this repo is
+
+Static website for [solr.apache.org](https://solr.apache.org), built with [Pelican](https://getpelican.com/) (Python static site generator). Content is written in Markdown. The build runs inside Docker to ensure a reproducible environment.
+
+## How to build and preview
+
+```bash
+./build.sh -l    # build and serve with live reload at http://localhost:8000
+./build.sh       # one-shot build into output/
+./build.sh -h    # show all options
+```
+
+Docker must be installed. The script auto-builds the image if missing, and auto-rebuilds it if `requirements.txt` is newer than the cached image.
+
+## Key files and directories
+
+| Path | Purpose |
+|---|---|
+| `pelicanconf.py` | Pelican configuration; defines `SOLR_LATEST_RELEASE` and other site-wide variables |
+| `content/pages/` | All site pages as Markdown files |
+| `content/pages/blogposts/` | Blog posts |
+| `themes/solr/templates/` | Jinja2 HTML templates |
+| `themes/solr/static/` | CSS, JS, images |
+| `plugins/` | Local Pelican plugins (Python) |
+| `requirements.in` | Direct Python dependencies (human-editable) |
+| `requirements.txt` | Hash-verified lockfile generated from `requirements.in` — do not edit by hand |
+| `Dockerfile` | Base image pinned by digest; Dependabot tracks it |
+| `.github/dependabot.yml` | Dependabot config for pip, docker, and github-actions ecosystems |
+
+## Updating dependencies
+
+Edit `requirements.in`, then regenerate the lockfile and rebuild the image:
+
+```bash
+./build.sh --lock -b
+```
+
+Or in two steps:
+
+```bash
+./build.sh --lock   # regenerates requirements.txt inside Docker
+./build.sh -b       # rebuilds the Docker image
+```
+
+## Updating Solr release versions
+
+Edit `pelicanconf.py` and bump `SOLR_LATEST_RELEASE`, `SOLR_LATEST_RELEASE_DATE`, and `SOLR_PREVIOUS_MAJOR_RELEASE`. These variables propagate throughout the theme automatically.
+
+## Templates and pages
+
+- Templates use Jinja2. Most pages use the `base.html` template.
+- A page can specify a custom template with `Template: my-template` in its Markdown front matter.
+- The `jinja2content` plugin allows Jinja2 expressions directly inside Markdown pages.
+
+## Branch and deploy model
+
+| Branch | Purpose |
+|---|---|
+| `main` | Staging — auto-deployed to [solr.staged.apache.org](https://solr.staged.apache.org) |
+| `production` | Live site — merge `main` → `production` to publish |
+
+Never commit directly to `production`. Always go through `main` (and a PR).
+
+## CI
+
+- Pull requests: Pelican build only (no publish), defined in `.github/workflows/pr-build-pelican.yml`
+- Push to `main`/`production`: full build + publish, defined in `.github/workflows/build-pelican.yml`
+- All GitHub Actions refs are pinned to commit SHAs and tracked by Dependabot.

build.sh

@@ -182,4 +182,4 @@ else
   echo "Building Solr site locally."
   echo "To build and serve live edits locally, run this script with -l argument. Use -h for help."
   $DOCKER_CMD sh -c "$PELICAN_CMD $*"
-fi
+fi

content/pages/security-dependency-cves.md

@@ -0,0 +1,24 @@
+Title: Solr™ CVE Status for Dependencies
+URL: security-dependency-cves.html
+save_as: security-dependency-cves.html
+template: security-dependency-cves
+
+Apache Solr depends on many third-party libraries. Security scanners routinely flag CVEs in
+those libraries, but a CVE in a dependency does not automatically mean Solr is vulnerable —
+it depends on whether Solr actually exercises the affected code path in a way that can be exploited.
+
+We publish our assessment of dependency CVEs in a machine-readable
+**[VEX (Vulnerability Exploitability eXchange)](https://cyclonedx.org/capabilities/vex/)** file.
+VEX is an open standard that lets vendors state explicitly whether a CVE applies to their product,
+and why. A number of formats are under active development, including
+[CycloneDX](https://cyclonedx.org/capabilities/vex/) and
+[CSAF](https://github.com/oasis-tcs/csaf/blob/master/csaf_2.0/prose/csaf-v2-editor-draft.md#45-profile-5-vex).
+We currently publish in CycloneDX 1.4 JSON format.
+
+If your scanner supports VEX, download the file below and point your scanner at it to automatically
+suppress known non-applicable findings. If your scanner does not yet support VEX, you can use the
+table on this page to manually triage flagged CVEs.
+
+We encourage feedback on VEX and tool support — join the discussion at
+[security-discuss@community.apache.org](mailto:security-discuss@community.apache.org)
+or contact [security@apache.org](mailto:security@apache.org).

content/pages/security-reporting.md

@@ -0,0 +1,255 @@
+Title: Solr™ Vulnerability Reporting Procedure
+URL: security-reporting.html
+save_as: security-reporting.html
+template: security-reporting
+
+This page documents the procedure for reporting a security vulnerability in Apache Solr and
+explains what happens after a report is submitted. It also provides canned email templates
+for PMC members to use when responding to reports.
+
+Apache Solr is maintained by volunteers. The PMC will make every effort to respond promptly,
+but cannot guarantee specific response times. We appreciate your patience and your contribution
+to the security of the project.
+
+If you have concerns about how the project team is handling a report, you may also contact
+[security@apache.org](mailto:security@apache.org) directly.
+
+<h2 id="incident-response-plan">Incident Response Plan <a class="headerlink" href="#incident-response-plan" title="Permanent link">¶</a></h2>
+
+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. If you have questions to these procedures,
+feel free to use our [public mailing lists](community.html).
+
+<h2 id="before-you-report">Before You Report <a class="headerlink" href="#before-you-report" title="Permanent link">¶</a></h2>
+
+Ensure you have tested against a [supported Solr version](https://solr.apache.org/downloads.html)
+with both **authentication** and **authorization** properly configured.
+Solr's admin level APIs are designed to be used only by authenticated and trusted administrators.
+
+<h2 id="submission-rules">Submission Rules <a class="headerlink" href="#submission-rules" title="Permanent link">¶</a></h2>
+
+A valid security report to [security@solr.apache.org](mailto:security@solr.apache.org) must:
+
+1. **Be sent as plaintext** — no zip file attachments, no links to Google Docs, Dropbox, or similar services
+2. **Cover exactly one vulnerability** — if you have multiple findings, send one email per issue
+3. **Include step-by-step reproduction steps** — scanner output or LLM generated reports are not sufficient by themselves.
+4. **Demonstrate the issue with authentication and authorization enabled** — running Solr
+   without authentication is a misconfiguration, not a vulnerability
+5. **Target a [supported Solr version](https://solr.apache.org/downloads.html)** — reports
+   against unsupported versions will not be accepted
+
+<h2 id="workflow">Workflow <a class="headerlink" href="#workflow" title="Permanent link">¶</a></h2>
+
+<pre class="mermaid">
+flowchart TD
+    A["`**Submit security report**
+  *Plaintext · one issue*
+  *repro steps · auth enabled*
+  security@solr.apache.org`"]
+
+    D["`**PMC triage**
+  *up to 7 days*`"]
+
+    E["`**Rejected**
+  *No repro / no auth*
+  *zip or link / multiple issues*`"]
+
+    F["`**Needs changes**
+  *PMC requests clarification*`"]
+
+    G["`**Accepted**
+  *ACK email + private JIRA*
+  *within 7 days*`"]
+
+    I["`**Full investigation**
+  *up to 90 days*`"]
+
+    J["`**Won't fix**
+  *Reporter notified*`"]
+
+    K["`**Fix & coordinated disclosure**
+  *CVE published*
+  *reporter credited in advisory*`"]
+
+    A --> D
+    D -->|rejected| E
+    D -->|needs changes| F
+    D -->|accepted| G
+    F -->|revise & re-send| A
+    G --> I
+    I -->|not confirmed| J
+    I -->|confirmed| K
+
+    classDef submit    fill:#eae6f5,stroke:#9b93d0,color:#3d3a6b
+    classDef process   fill:#fdf4e8,stroke:#c8a86b,color:#5a4520
+    classDef rejected  fill:#fde8e8,stroke:#d08080,color:#7a2020
+    classDef changes   fill:#fdefd8,stroke:#d4a060,color:#7a4010
+    classDef accepted  fill:#dff5ec,stroke:#6dbfa0,color:#1a5a40
+    classDef wontfix   fill:#fde8e8,stroke:#d08080,color:#7a2020
+    classDef disclosure fill:#f5f0e0,stroke:#b8ad80,color:#4a4020
+
+    class A submit
+    class D,G,I process
+    class E rejected
+    class F changes
+    class J wontfix
+    class K disclosure
+</pre> 
+
+<h2 id="what-to-expect">What to Expect <a class="headerlink" href="#what-to-expect" title="Permanent link">¶</a></h2>
+
+| Step | Who | Timeframe |
+|------|-----|-----------|
+| Initial triage / acknowledgment | PMC volunteers | Up to 7 days |
+| Full investigation | PMC volunteers | Up to 90 days |
+| CVE ID allocation | PMC + ASF Security Team (CNA) | During fix development |
+| Fix + CVE publication | PMC + ASF Security Team | Coordinated with you, the reporter |
+| Credit in advisory | PMC | At public disclosure |
+
+Public disclosure follows the [ASF standard process](https://www.apache.org/security/committers.html) and is announced on the
+[oss-security mailing list](https://oss-security.openwall.org/wiki/mailing-lists/oss-security).
+
+# For the PMC
+
+The following section documents the internal triage process and provides email templates for responding to incoming reports.
+
+<h2 id="canned-responses">Canned Email Responses <a class="headerlink" href="#canned-responses" title="Permanent link">¶</a></h2>
+
+The following templates are provided for PMC members responding to incoming reports.
+Click each entry to expand and view the template.
+
+<details>
+<summary>Response A: Acknowledgment — report received and under review</summary>
+<pre>
+Thank you for your security report.
+
+We have received your report and created a private issue to track it.
+The Solr PMC will review your report and aim to update you within 30 days.
+We will keep you informed through this email thread.
+
+Please do not discuss this report on public channels (mailing lists,
+GitHub, social media) until we have coordinated public disclosure with you.
+
+If you have additional information, please reply to this email.
+
+Apache Solr Security Team
+security@solr.apache.org
+https://solr.apache.org/security.html
+</pre>
+</details>
+
+<details>
+<summary>Response B: Reject — scanner output without reproduction steps</summary>
+<pre>
+Thank you for contacting the Solr security team.
+
+We are unable to process reports that consist solely of scanner tool output
+without a demonstrated reproduction of the vulnerability in Apache Solr.
+
+Scanner reports list dependency CVEs that are often not applicable to how
+Solr uses those libraries. Before filing a security report, please:
+
+1. Check https://solr.apache.org/security-dependency-cves.html — we publish
+   a VEX file listing CVEs already assessed as not exploitable in Solr.
+2. Verify the issue is actually exploitable in a properly configured Solr
+   instance (with authentication and authorization enabled).
+3. Write step-by-step reproduction steps that demonstrate the impact on
+   Solr specifically.
+
+For dependency upgrade discussions, the public Solr users list is the
+right venue: users@solr.apache.org
+
+Please read https://solr.apache.org/security-reporting.html for the full process.
+
+Apache Solr Security Team
+</pre>
+</details>
+
+<details>
+<summary>Response C: Reject — multiple distinct vulnerabilities in one email</summary>
+<pre>
+Thank you for your security report.
+
+Your email appears to describe several separate potential vulnerabilities.
+To allow each issue to be tracked, fixed, and disclosed independently,
+please re-submit each as a separate email to security@solr.apache.org.
+
+Each email should cover exactly one vulnerability with:
+  - A clear description of the issue
+  - Step-by-step reproduction instructions
+  - The Solr version tested
+  - The impact and attack scenario
+
+We will begin reviewing each issue once we receive the separate reports.
+
+Please read https://solr.apache.org/security-reporting.html for the full process.
+
+Apache Solr Security Team
+</pre>
+</details>
+
+<details>
+<summary>Response D: Reject — report sent as zip file or external link</summary>
+<pre>
+Thank you for your security report.
+
+For security reasons, the Solr PMC does not open zip file attachments
+or follow external links (Google Docs, Dropbox, etc.) in security reports.
+
+Please re-send your report as plaintext in the body of an email to
+security@solr.apache.org, including:
+
+  - Description of the vulnerability
+  - Step-by-step reproduction instructions
+  - Solr version and configuration tested
+  - Expected vs. actual behavior
+  - Any relevant log output, pasted directly into the email
+
+We look forward to reviewing your report once re-submitted in plaintext.
+
+Please read https://solr.apache.org/security-reporting.html for the full process.
+
+Apache Solr Security Team
+</pre>
+</details>
+
+<details>
+<summary>Response E: Reject — no authentication configured or behavior within expected role</summary>
+<pre>
+Thank you for your security report.
+
+After reviewing your report, we are unable to treat this as a security
+vulnerability due to either of the following reasons:
+
+  a) The behavior requires Solr to be running without authentication.
+     Solr is not designed for unauthenticated operation in any networked
+     environment. Running without authentication is a misconfiguration,
+     not a Solr vulnerability.
+
+  b) The action performed was permitted by the role used in your test.
+     A vulnerability requires either that the action exceeded what the
+     role should allow, or that it should never be permitted for any role.
+
+If you believe our assessment is incorrect, please reply with details
+explaining why the behavior should not be possible under your tested
+configuration and role.
+
+Please read https://solr.apache.org/security-reporting.html for the full process.
+
+Apache Solr Security Team
+</pre>
+</details>
+
+<h2 id="pmc-process">After Acceptance: PMC Process <a class="headerlink" href="#pmc-process" title="Permanent link">¶</a></h2>
+
+Once a report passes initial triage, the PMC follows these steps:
+
+1. Create a **private JIRA issue** with the appropriate security level (not publicly visible)
+2. Send the **acknowledgment email** to the reporter (Response A above)
+3. PMC coordinates the investigation through private channels
+4. When a fix is ready, request a **CVE ID from the ASF Security Team**, via the CVE portal
+5. **Notify the reporter** of the chosen fix and planned disclosure date
+6. **Publish the fix release**, then publish the CVE advisory on the security page
+7. The ASF Security Team announces the advisory on **oss-security@lists.openwall.com**
+8. **Update security-news** page with the new CVE entry and close the JIRA issue