From cf22320e33ec8da5bdb831ed2ee579017adc1dda Mon Sep 17 00:00:00 2001 From: Lukasz Lenart Date: Tue, 14 Jul 2026 20:25:56 +0200 Subject: [PATCH] docs(security): treat a fix or PR as disclosure, require private report first (#1785) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The disclosure rules only forbade publishing exploit/PoC code, so a contributor who opens a public PR that fixes or hints at a suspected vulnerability reads them as satisfied — the fix itself telegraphs the weakness before a fixed release exists. Add a dedicated "Do not disclose through a pull request, commit, or issue" section directing reporters to email security@struts.apache.org first, and extend the PoC rule in Report Quality Rules to state that a fix, patch, or hardening change is a public disclosure in the same way a PoC is. Aligns SECURITY.md with the rule already stated in CLAUDE.md/AGENTS.md. 🤖 Generated by AI Assistant --- SECURITY.md | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 3337c131c..8ba4c4b29 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -52,6 +52,28 @@ The mailing address is: [security@struts.apache.org](mailto:security@struts.apac [The Apache Security Team](http://www.apache.org/security/) +## Do not disclose through a pull request, commit, or issue + +**A fix is a disclosure.** Opening a public pull request, pushing a commit, branch, or +fork, or filing a public Jira/GitHub issue that **fixes, describes, or hints at** a +suspected vulnerability reveals where the weakness is — often with a working roadmap to +exploit it — before a fixed release exists. This holds even if you never attach a +proof-of-concept, and even if you believe the impact is low or you are "just hardening" +the code. + +If you have found, or suspect you have found, a security problem: + +- **Do not** open a public PR, commit, branch, fork, Jira issue, or mailing-list thread + for it. +- **Do** email [security@struts.apache.org](mailto:security@struts.apache.org) first and + wait for the PMC to triage it and agree how the fix will be handled — the fix is + typically prepared privately and landed alongside the advisory and release. + +If you notice a possible security issue while working on an unrelated bug or PR, stop and +email the private list before pushing the change. **When in doubt, treat it as +security-sensitive and email the list** — a private report that turns out to be a +non-issue costs far less than a public change that turns out to be exploitable. + ## Before Reporting Before sending a vulnerability report, run through the following checks. They exist to prevent duplicate reports, public disclosure of untriaged issues, @@ -128,8 +150,9 @@ Do not speculate beyond what can be demonstrated. If severity is uncertain, say - One vulnerability per report. - Keep reproduction steps minimal and self-contained. - Do not include unrelated findings. -- Do not publish exploit details or proof-of-concept code publicly before the Struts project has triaged the issue. **Pushing a PoC to a public GitHub - repository, gist, fork, or branch counts as public disclosure** — even a "test" or throwaway repo. Private repositories are acceptable for sharing a PoC, - but access must be granted individually to each PMC member who will triage the report. +- Do not publish exploit details or proof-of-concept code publicly before the Struts project has triaged the issue. **A fix, patch, or hardening change is a + public disclosure in the same way a PoC is** — see [Do not disclose through a pull request, commit, or issue](#do-not-disclose-through-a-pull-request-commit-or-issue). + **Pushing a PoC to a public GitHub repository, gist, fork, or branch counts as public disclosure** — even a "test" or throwaway repo. Private repositories + are acceptable for sharing a PoC, but access must be granted individually to each PMC member who will triage the report. - Do not send ordinary bugs, usage questions, or generic denial-of-service concerns to the private security list. - If the issue is not a vulnerability in Apache Struts source code, use the appropriate public support or issue channel instead.