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 f591c15 feat(security-cve-allocate): title-only allocation recipe
(#110)
f591c15 is described below
commit f591c158f25e0ae5a07aaea9ab024ce5d40bc5ba
Author: Jarek Potiuk <[email protected]>
AuthorDate: Sun May 10 23:49:24 2026 +0200
feat(security-cve-allocate): title-only allocation recipe (#110)
The Vulnogram allocation form accepts a bare title — product /
packageName, CWE, affected versions, summary, and reporter
credits are all easier to set correctly during the Step 6
`security-issue-sync` handoff after the tracker body has settled.
Drop them from the Step 3 paste-into-form recipe (and from the
non-PMC relay message), refresh the scope-label blocker
rationale so it reflects the new model (still surfaced up front
because sync depends on it; no longer because allocation does),
and add an explicit "Allocation is title-only" note that points
the user at where the remaining fields land.
Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>
---
.claude/skills/security-cve-allocate/SKILL.md | 55 +++++++++++++--------------
1 file changed, 27 insertions(+), 28 deletions(-)
diff --git a/.claude/skills/security-cve-allocate/SKILL.md
b/.claude/skills/security-cve-allocate/SKILL.md
index c6a34f9..4d8a9e2 100644
--- a/.claude/skills/security-cve-allocate/SKILL.md
+++ b/.claude/skills/security-cve-allocate/SKILL.md
@@ -254,10 +254,14 @@ Blocker checks — if any fail, stop and surface the
failure:
- **Scope label set.** The CVE record's `product` / `packageName`
fields depend on the scope (`airflow` → `apache-airflow`,
`providers` → `apache-airflow-providers-<name>`,
- `chart` → `apache-airflow-helm-chart`). If no scope label is
- set, stop and ask the user to confirm the scope before allocating
- — it is **much** easier to set the right product at allocation
- time than to correct it after the Vulnogram record has a CVE ID.
+ `chart` → `apache-airflow-helm-chart`). Allocation itself is
+ title-only and does not need the scope label, but the Step 4
+ CVE-JSON regeneration and the Step 6 sync handoff both depend on
+ it — without a scope the product / packageName cannot be mapped
+ and the record-update push that follows will be blocked. Surface
+ it as a blocker here so the user fixes it once, up front, instead
+ of being interrupted mid-flow after the CVE has already been
+ allocated.
- **Not still `needs triage`.** If `needs triage` is still on the
tracker, the valid/invalid decision has not been landed yet —
allocating now would be premature. Surface as a soft warning and
@@ -349,35 +353,30 @@ one copy-paste pass:
<stripped title>
```
-3. Fill in the rest of the form from the tracker body — the key
- fields and where the skill reads them from:
- - **Product**: `<product, derived from scope — see table below>`
- - **CWE**: `<body.CWE if set, else "_No response_ — set during
allocation"`>`
- - **Affected versions**: `<body.Affected versions>`
- - **Summary**: `<body.Short public summary for publish>`
- - **Reporter credits**: `<body.Reporter credited as>`
-4. Click *Allocate*. Vulnogram returns a `CVE-YYYY-NNNNN` ID.
-5. Paste the allocated CVE ID back into this conversation — the
+3. Click *Allocate*. Vulnogram returns a `CVE-YYYY-NNNNN` ID.
+4. Paste the allocated CVE ID back into this conversation — the
skill will pick it up and update the tracker automatically.
````
-Scope → Vulnogram product table: the adopting project's scope labels
-and their CVE product / package-name mappings are defined in
-[`<project-config>/scope-labels.md`](../../../<project-config>/scope-labels.md).
-Read the label off the tracker and look up the matching product /
-`packageName` there.
-
-Note in the recipe which provider / chart / task-sdk is involved
-when the scope is not bare `airflow`, so the user does not have to
-re-infer it from the tracker body at paste time.
+**Allocation is title-only.** Every other CVE-record field —
+product / `packageName`, CWE, affected versions, public summary,
+reporter credits, references — is populated later: Step 4 of this
+skill regenerates the CVE JSON from the tracker body, Step 6 hands
+off to [`security-issue-sync`](../security-issue-sync/SKILL.md) to
+reconcile the surrounding state, and the
+[`vulnogram-api-record-update`](../../../tools/vulnogram/oauth-api/README.md)
+push that follows writes the full record into Vulnogram. Do not
+ask the user to paste those fields into the allocation form — the
+form accepts a bare title and they are easier to set correctly
+during sync, after the tracker body is in its final shape.
**Before printing the recipe**, ask the user *"are you an Airflow
PMC member?"* — a one-line yes/no question. This determines which
of two handoff paths the recipe describes:
- **User is a PMC member** — the recipe is self-service: click the
- URL, paste the stripped title, fill the form, hit *Allocate*,
- paste the allocated `CVE-YYYY-NNNNN` back into this conversation.
+ URL, paste the stripped title, hit *Allocate*, paste the allocated
+ `CVE-YYYY-NNNNN` back into this conversation.
- **User is NOT a PMC member** — the ASF CVE tool will not let them
submit the allocation. Reshape the recipe into a **relay message**
the user posts as a comment on the tracker (``@``-mentioning one
@@ -389,13 +388,13 @@ of two handoff paths the recipe describes:
contains only:
- the clickable allocation URL,
- the stripped title (ready for the Vulnogram form),
- - the derived scope / product / package-name block from Step 2,
- one line: *"Paste the allocated `CVE-YYYY-NNNNN` back here when
done."*
- Do not restate the vulnerability, the assessment history, or the
- handling process in the relay — the PMC member can read the
- tracker for any of that.
+ Do not restate the vulnerability, the assessment history, the
+ scope/product mapping, or the handling process in the relay — the
+ PMC member can read the tracker for any of that, and the
+ product / packageName lands during sync anyway.
The relay message is just markdown — it does not go to Vulnogram
directly. The PMC member reads the message, clicks through, fills
