(struts) 01/01: docs: frame CVE-at-release-time as PMC practice, not a rule

[lu...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

lukaszlenart pushed a commit to branch docs/cve-timing-practice-not-rule
in repository https://gitbox.apache.org/repos/asf/struts.git

commit b4b03fbc039e0e5cbf189c22faf76995fa222cdd
Author: Lukasz Lenart <lu...@apache.org>
AuthorDate: Sat Sep 12 09:06:11 2026 +0200

    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 <no...@anthropic.com>
    Claude-Session: https://claude.ai/code/session_0172CuA7muy9poSod942s6AP
---
 .claude/skills/creating-security-bulletins/SKILL.md |  2 +-
 .claude/skills/triaging-security-reports/SKILL.md   | 12 +++++++-----
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/.claude/skills/creating-security-bulletins/SKILL.md b/.claude/skills/creating-security-bulletins/SKILL.md
index 3d83e99b4..9d50c5649 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)
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. |