This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow-steward.git
The following commit(s) were added to refs/heads/main by this push:
new 5aa3d7c feat(skills): security-issue-sync — propose courtesy reply to
CVE reviewer when addressing a record comment (#295)
5aa3d7c is described below
commit 5aa3d7c3d9d706ead6ec9a1ff0cd4c7a252caef7
Author: Jarek Potiuk <[email protected]>
AuthorDate: Tue May 26 04:11:27 2026 +0200
feat(skills): security-issue-sync — propose courtesy reply to CVE reviewer
when addressing a record comment (#295)
When a reviewer (e.g. an ASF Security PMC member) leaves a comment
on a CVE record via Vulnogram, the comment arrives as a "Comment
added on <CVE-ID>" Gmail notification. Sync already maps the comment
to a body-field update + JSON re-push, but the reviewer has no
signal that the record changed — Vulnogram does not auto-notify
reviewers of record updates. Without a courtesy reply, the comment
can sit unresolved for days simply because the reviewer has no
reason to re-open the Vulnogram UI.
This adds a paragraph in Step 1e (and a pointer in the matching
Step 2b table row) telling sync to propose a short courtesy Gmail
draft on the reviewer's notification thread after the body-update
lands, closing the round-trip visibility loop. The draft uses the
same backend selection as the reporter-draft path in Step 5d and
is always a draft — never sent.
Restricted to comments that mapped to a body-field update;
judgement-call comments (severity/CVSS, out-of-scope challenges,
free-form rewrites) stay on the existing "surface verbatim for
human resolution" path because a "please re-review" ping is not
the right shape there.
Generated-by: Claude Code (Opus 4.7)
---
.claude/skills/security-issue-sync/SKILL.md | 38 ++++++++++++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/.claude/skills/security-issue-sync/SKILL.md
b/.claude/skills/security-issue-sync/SKILL.md
index 571bf98..cbdf068 100644
--- a/.claude/skills/security-issue-sync/SKILL.md
+++ b/.claude/skills/security-issue-sync/SKILL.md
@@ -732,7 +732,7 @@ update, label change, or next-step recommendation in Step 2:
| Advisory message sent to `[email protected]` / `<users-list>` but archive
URL not yet visible | No-op transition; **do not** flip the `fix released →
announced` labels here. The label flip is part of the combined "archive URL
captured" apply above and only fires when the archive URL is confirmed live on
`lists.apache.org` (this is the load-bearing real-world signal that the
advisory actually shipped — a `[VOTE]/[ANNOUNCE]` mail thread in flight without
an archived URL is ambiguous). |
| Project-board column drifted from the issue's label-derived state (e.g. a
tracker carries `pr merged` but is still in the `PR created` column on [Project
2](<project-board-url>), or `announced` + *Public advisory URL* body field
populated but the column is still `Fix released`) | Propose moving the project
item to the correct column per the mapping table in Step 2b. The board is the
primary security-team overview surface; a stale column hides ownership handoffs
from the team at a glance. |
| `announced` label set and CVE record on `cveprocess.apache.org` now reports
state PUBLISHED (checked via `curl -s
https://cveprocess.apache.org/cve5/<CVE-ID>.json` / the ASF CVE tool API, or an
explicit release-manager comment on the issue stating the Vulnogram push is
done) | Propose closing the issue. Do not update any labels. This is the
terminal transition. |
-| CVE record has open **review comments / reviewer proposals** (detected via
the Gmail-search path in Step 1e — reviewer-comment notifications from
Vulnogram land on `<security-list>` with the CVE ID in the subject line; the
`cveprocess.apache.org/cve5/<CVE-ID>.json` endpoint is behind ASF OAuth and is
not readable from this skill's context, so Gmail is the load-bearing signal
source). | Surface each open review comment in Step 2a with **clickable links**
to the Gmail thread and to the C [...]
+| CVE record has open **review comments / reviewer proposals** (detected via
the Gmail-search path in Step 1e — reviewer-comment notifications from
Vulnogram land on `<security-list>` with the CVE ID in the subject line; the
`cveprocess.apache.org/cve5/<CVE-ID>.json` endpoint is behind ASF OAuth and is
not readable from this skill's context, so Gmail is the load-bearing signal
source). | Surface each open review comment in Step 2a with **clickable links**
to the Gmail thread and to the C [...]
| The referenced `<upstream>` PR has been opened but is still in `open` state
| Propose `pr created` label; update the *"PR with the fix"* body field with
the PR URL. |
| The referenced `<upstream>` PR moved to `merged` | Propose swapping `pr
created` → `pr merged`; update milestone to the shipping release if now known.
**Also**: check whether all six mandatory CVE body fields are populated (*CWE*,
*Affected versions*, *Severity*, *Reporter credited as*, *Short public summary
for publish*, *PR with the fix*). If any is empty / `_No response_`, propose
posting (or PATCH-updating) the *Remediation-developer fill-fields comment* per
[the dedicated bullet i [...]
| The *"PR with the fix"* body field has at least one PR URL **and** the
*"Remediation developer"* body field is missing the PR author's name (or is
`_No response_`) | Propose appending the PR author's display name (`gh pr view
<N> --repo <upstream> --json author --jq '.author.name // .author.login'`) to
the *"Remediation developer"* body field. **Append, never overwrite** — manual
edits (co-authors added by the triager, name spelling corrections, "Anonymous"
overrides) must survive subs [...]
@@ -913,6 +913,42 @@ user knows what the release manager still needs to do in
Vulnogram after the body update lands (resolving the comment is
a Vulnogram UI action that sync cannot drive).
+**Also propose a courtesy reply to the reviewer on their
+notification thread.** Vulnogram does not actively notify
+reviewers when a CVE record's description is updated — the
+reviewer's natural workflow is to check the Gmail thread of
+their original *"Comment added on `<CVE-ID>`"* notification
+for a reply. After the body-update + JSON re-push lands, the
+reviewer's comment can sit unresolved for days simply because
+they have no signal that the record changed. A short courtesy
+draft on the notification thread closes the loop:
+
+- **To:** the reviewer's `@apache.org` address (the `From:`
+ of the original notification).
+- **Cc:** `<security-list>` (so the security team thread
+ carries the round-trip), plus `[email protected]` when
+ the original notification CC'd it.
+- **Subject:** `Re: <original notification subject>`
+ (typically `Re: Comment added on <CVE-ID>`).
+- **Body shape:** one paragraph acknowledging what was
+ changed in response, the CVE-tool URL, and one line asking
+ the reviewer to re-review when they have a moment. Same
+ backend selection as the reporter-draft path in Step 5d
+ (`claude_ai_mcp` default, `oauth_curl` opt-in). Always a
+ draft — never sent.
+
+Restrict this draft to comments that mapped cleanly to a
+body-field update (the mapping table above). Comments that
+need human judgement (severity/CVSS, out-of-scope challenges,
+free-form rewrites) get surfaced verbatim per the existing
+rule; no automated draft applies there — their resolution is
+a security-team conversation, not a *"please re-review"* ping.
+
+Without this, the framework's *"address the comment via body
+update"* contract is complete from sync's side but
+operationally incomplete from the reviewer's side; the
+courtesy reply is what makes the round-trip visible.
+
**Do not try to edit the CVE record from this skill.** Writes to
`cveprocess.apache.org` itself stay with the release manager.
Reviewer proposals that cannot be expressed as a body-field
