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 <[email protected]> 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 <[email protected]> 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. |
