This is an automated email from the ASF dual-hosted git repository.
lukaszlenart pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/struts.git
The following commit(s) were added to refs/heads/main by this push:
new 2d36231cd docs: frame CVE-at-release-time as PMC practice, not a rule
(#1917)
2d36231cd is described below
commit 2d36231cdea28699be9d169d981a6e58f580d419
Author: Lukasz Lenart <[email protected]>
AuthorDate: Sat Sep 12 09:16:57 2026 +0200
docs: frame CVE-at-release-time as PMC practice, not a rule (#1917)
* docs: frame CVE-at-release-time as PMC practice, not a rule
Both security skills stated that a CVE is requested only after the fixed
release is out, phrased as a hard constraint. It is a PMC practice / silent
consensus, not an ASF rule — ASF permits allocating a CVE earlier and
sharing
the id with the reporter. Reword triaging-security-reports and
creating-security-bulletins accordingly, and soften the matching red-flag
and
common-mistake lines, while keeping the guidance that a triage reply must
not
commit the project to CVE timing.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_0172CuA7muy9poSod942s6AP
* docs: link the ASF committer security process from the CVE section
Keep a reference to https://www.apache.org/security/committers.html next to
the CVE guidance, so the authority behind our CVE-timing practice is one
click
away when a report raises a case the skill does not cover.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_0172CuA7muy9poSod942s6AP
---------
Co-authored-by: Claude Opus 4.8 <[email protected]>
---
.claude/skills/creating-security-bulletins/SKILL.md | 4 +++-
.claude/skills/triaging-security-reports/SKILL.md | 12 +++++++-----
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/.claude/skills/creating-security-bulletins/SKILL.md
b/.claude/skills/creating-security-bulletins/SKILL.md
index 3d83e99b4..4e9d67e4c 100644
--- a/.claude/skills/creating-security-bulletins/SKILL.md
+++ b/.claude/skills/creating-security-bulletins/SKILL.md
@@ -81,7 +81,7 @@ Two traps in applying it:
## CVE placeholder
-CVEs are requested **after** the fixed release is out and accepted. Until then
the row carries a placeholder that cannot be mistaken for a real identifier:
+By our practice, the CVE is requested around the fixed release rather than at
triage — but this is a PMC choice, not an ASF requirement (ASF permits
allocating earlier and sharing the id with the reporter). Until one is
assigned, the row carries a placeholder that cannot be mistaken for a real
identifier:
```
CVE-YYYY-NNNNN (to be assigned before publication)
@@ -91,6 +91,8 @@ Never leave a cloned page's real CVE in place. Never invent a
well-formed-lookin
One CVE per independently fixable issue — separate fixes get separate
bulletins and separate CVEs, per [CNA rules
4.1.10](https://www.cve.org/ResourcesSupport/AllResources/CNARules).
+For the full ASF process behind CVE handling — reserving, timing, and sharing
an id with the reporter (steps 7–9) — see the [ASF committer security
process](https://www.apache.org/security/committers.html). Consult it if
anything here is unclear or a report raises a case our practice doesn't cover.
+
## The disclosure budget
**The budget covers every prose section — `Problem`, `Backward compatibility`,
and `Workaround` alike.** `Problem` is the section authors guard; `Backward
compatibility` is the one that leaks, because describing what changed about the
fixed behaviour describes the defect. A note saying which inputs are handled
differently now points straight at the code path that was rewritten. Apply the
table below to all three sections, and write the BC note in terms of what an
application might *obser [...]
diff --git a/.claude/skills/triaging-security-reports/SKILL.md
b/.claude/skills/triaging-security-reports/SKILL.md
index 23995a0e8..1b1df2a3e 100644
--- a/.claude/skills/triaging-security-reports/SKILL.md
+++ b/.claude/skills/triaging-security-reports/SKILL.md
@@ -93,9 +93,11 @@ Once you *have* been asked:
doesn't already exist (it often does) and that you intend to actually do it.
Beyond that, a triage
reply does not get to settle **severity ratings, bulletins, CVE requests,
fix versions, or
timelines** — those are the PMC's, and a reply that states one has made the
decision on their
- behalf. A CVE especially: it is requested once the fixed release is out,
never at triage (see
- [`creating-security-bulletins`](../creating-security-bulletins/SKILL.md)).
When the reporter asks
- for one of these, say the decision comes later and report the question to
the user; do not answer it.
+ behalf. A CVE especially: our practice is to allocate it around release time
and publish it with
+ the bulletin, but that timing is the PMC's call (ASF actually permits
allocating earlier and
+ sharing the id with the reporter — see
[`creating-security-bulletins`](../creating-security-bulletins/SKILL.md)),
+ so a reply must not promise a CVE or its timing. When the reporter asks for
one of these, say the
+ decision comes later and report the question to the user; do not answer it.
- Acknowledge anything the reporter got right (e.g. correct CVE-fix
verification) — it builds the relationship and signals you actually read it.
- Keep it private: no public issue, PR, Jira, or list thread before triage.
Never open a PR that is itself the security fix (see
[`CLAUDE.md`](../../../CLAUDE.md)).
@@ -109,7 +111,7 @@ Once you *have* been asked:
- Promising a fix/warning "we'll add" without checking it isn't already there.
- Writing "not a vulnerability in the default configuration" → reframe as
vuln-or-not + operator responsibility.
- About to create a reply draft that nobody asked for — the verdict is the
deliverable, the draft is a separate task.
-- About to write a severity rating, a bulletin, a fix version, or a CVE into a
reply as though it were decided — it isn't yours to decide.
+- About to write a severity rating, a bulletin, a fix version, or a CVE (or
its timing) into a reply as though it were decided — it isn't yours to decide.
## Common Mistakes
@@ -123,4 +125,4 @@ Once you *have* been asked:
| "Not a vuln in default config" | Either it's a vuln or it's operator-owned
opt-in. The default-config hedge muddies both. |
| "Triage is done, so drafting the reply is the next step" | Triage ends at
the assessment. Replying is a separate task the user starts. |
| "A draft is harmless — it isn't sent" | The draft is the artifact. Creating
it unasked decides for the user that the project is ready to answer. |
-| "The reporter asked about a CVE, so I should answer it" | Report the
question to the user. Answering it commits the project to a process decision
that isn't yours. |
+| "The reporter asked about a CVE, so I should answer it" | Report the
question to the user. CVE timing is a PMC choice (not a fixed rule), so
answering it commits the project to a process decision that isn't yours. |
