docs(security): treat a fix or PR as disclosure, require private report first#1785
Merged
Conversation
…rt first 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
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Strengthens
SECURITY.mdso it is explicit that a fix is a disclosure, not only a PoC.Two changes:
security@struts.apache.orgfirst and wait for the PMC to triage and agree how the fix is handled, and covers the "found it while working on an unrelated bug/PR" and "when in doubt, report privately" cases.Why
The existing disclosure rules only forbade publishing exploit/PoC code. A well-meaning contributor who opens a public PR that fixes or hints at a suspected vulnerability honestly reads those rules as satisfied — "I'm not posting a PoC, I'm hardening the code" — while the PR itself telegraphs where the weakness is, with a working roadmap, before a fixed release exists.
This brings
SECURITY.md(the human-facing canonical doc) in line with the rule already stated inCLAUDE.md/AGENTS.md: "Never submit a PR that fixes a suspected vulnerability."Scope
Documentation only.
THREAT_MODEL.mdintentionally not changed: it delegates the reporting process toSECURITY.md(§1 "Reporting cross-reference", §15 "additive — does not replace SECURITY.md … reporting process"). The disclosure-channel rule is a reporting-process concern, not a scope/property/adversary statement, so it belongs only inSECURITY.md.🤖 Generated with Claude Code