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 e011c5a docs(security): align process/roles/README with post-2026
sync-driven RM close-out (#274)
e011c5a is described below
commit e011c5a18f18dad5c448080147ab6b8ac784510c
Author: Jarek Potiuk <[email protected]>
AuthorDate: Mon May 25 12:53:18 2026 +0200
docs(security): align process/roles/README with post-2026 sync-driven RM
close-out (#274)
* docs(security): align process/roles/README with post-2026 sync-driven RM
close-out
Recent sync-skill changes (#202, #222, #225, #255) shifted Vulnogram
REVIEW -> PUBLIC, JSON re-push, board move, and tracker close from RM
hand-clicks to sync automation. The reference docs still described the
pre-2026 flow; this brings them back in sync.
- process.md Step 12: document the two-stage hand-off gate (six
mandatory body fields populated + CVE record state REVIEW) and the
Remediation-developer fill-fields comment that fires when either
gate fails. RM hand-off comment now only fires when both gates clear.
- process.md Step 13: rewrite RM checklist as three single-click
Vulnogram actions (REVIEW -> READY, send advisory, stop). Drop the
stale "REVIEW (then READY)" phrasing -- REVIEW is set by sync.
- process.md Step 14: rename to "Capture the public advisory URL and
close out" and list the eleven actions of sync's combined apply
(URL capture, short-summary extraction, label flips, JSON re-push,
READY -> PUBLIC via OAuth API, board move, tracker close, board
archive, conditional milestone close, wrap-up comment).
- process.md Step 15: collapse to "RM verifies the close-out landed"
-- the RM has no remaining manual work; just receives a
purely-informational timeline marker.
- process.md Mermaid diagram + label-lifecycle table + label
reference table updated to match.
- roles.md "Handoff from the remediation developer": mention the
fill-fields comment they may receive when six mandatory fields
are incomplete.
- roles.md "Sending the advisory": replace with the three-step
Vulnogram clickflow matching process.md Step 13.
- roles.md "Capturing the public archive URL and closing out":
list the sync-driven combined apply.
- roles.md "Publishing the CVE and closing the issue": now
"Nothing to do".
- roles.md RM "Tools you use most": drop stale Vulnogram-paste
language.
- README.md: "Eight skills" -> "Nine skills ... plus one read-only
supporting skill". Split skills table into "Lifecycle skills" (9)
and "Supporting tools" (1), adding security-tracker-stats-dashboard.
Generated-by: Claude Code (Opus 4.7)
* docs(security): fix Step 14 link — oauth-api/README.md, not
vulnogram-api/SKILL.md
`vulnogram-api-record-publish` is documented in
`tools/vulnogram/oauth-api/README.md`; the previous commit linked a
non-existent `tools/vulnogram/vulnogram-api/SKILL.md`. Caught by
lychee.
Generated-by: Claude Code (Opus 4.7)
---
docs/security/README.md | 15 +++-
docs/security/process.md | 206 +++++++++++++++++++++++++++++++++--------------
docs/security/roles.md | 100 ++++++++++++++++-------
3 files changed, 229 insertions(+), 92 deletions(-)
diff --git a/docs/security/README.md b/docs/security/README.md
index 3307f0d..d514e72 100644
--- a/docs/security/README.md
+++ b/docs/security/README.md
@@ -4,6 +4,8 @@
- [Security workflow skill family](#security-workflow-skill-family)
- [Skills](#skills)
+ - [Lifecycle skills](#lifecycle-skills)
+ - [Supporting tools](#supporting-tools)
- [Deep documentation](#deep-documentation)
- [Adopter contract](#adopter-contract)
- [Cross-references](#cross-references)
@@ -17,8 +19,9 @@
End-to-end automation for an ASF project's security-issue handling
process — from inbound report on the project's `security@` mailing
-list through to a published CVE record on `cve.org`. Eight skills
-that compose into the canonical 16-step lifecycle.
+list through to a published CVE record on `cve.org`. Nine skills
+that compose into the canonical 16-step lifecycle, plus one
+read-only supporting skill for tracker-stats dashboards.
Why a framework skill family? The 16-step process exists across
the foundation; every project's security team runs essentially
@@ -30,6 +33,8 @@ and reuse the skills verbatim.
## Skills
+### Lifecycle skills
+
| Skill | Purpose |
|---|---|
|
[`security-issue-import`](../../.claude/skills/security-issue-import/SKILL.md)
| Import new reports from `<security-list>` into `<tracker>`. |
@@ -42,6 +47,12 @@ and reuse the skills verbatim.
|
[`security-issue-deduplicate`](../../.claude/skills/security-issue-deduplicate/SKILL.md)
| Merge two trackers describing the same root-cause vulnerability. |
|
[`security-issue-invalidate`](../../.claude/skills/security-issue-invalidate/SKILL.md)
| Close a tracker as invalid with a polite-but-firm reporter reply. |
+### Supporting tools
+
+| Skill | Purpose |
+|---|---|
+|
[`security-tracker-stats-dashboard`](../../.claude/skills/security-tracker-stats-dashboard/SKILL.md)
| Generate a self-contained HTML dashboard of `<tracker>` repo statistics
(lifecycle bands, opened-vs-untriaged backlog, mean time to triage / first
response / fix). Read-only — never modifies tracker state. |
+
## Deep documentation
- [**`process.md`**](process.md) — the 16-step lifecycle with
diff --git a/docs/security/process.md b/docs/security/process.md
index 7f482cb..cc9ef2e 100644
--- a/docs/security/process.md
+++ b/docs/security/process.md
@@ -17,8 +17,8 @@
- [Step 11 — PR merged](#step-11--pr-merged)
- [Step 12 — Fix released](#step-12--fix-released)
- [Step 13 — Send the advisory](#step-13--send-the-advisory)
- - [Step 14 — Capture the public advisory
URL](#step-14--capture-the-public-advisory-url)
- - [Step 15 — Publish the CVE record and close the
issue](#step-15--publish-the-cve-record-and-close-the-issue)
+ - [Step 14 — Capture the public advisory URL and close
out](#step-14--capture-the-public-advisory-url-and-close-out)
+ - [Step 15 — RM verifies the close-out
landed](#step-15--rm-verifies-the-close-out-landed)
- [Step 16 — Credit corrections](#step-16--credit-corrections)
- [Label lifecycle](#label-lifecycle)
- [State diagram](#state-diagram)
@@ -63,8 +63,8 @@ flowchart TD
S11[11. PR merged]
S12[12. Fix released]
S13[13. Send advisory]
- S14[14. Capture public archive URL]
- S15[15. Publish CVE + close issue]
+ S14[14. Sync close-out at archive URL]
+ S15[15. RM verifies close-out]
S16[16. Credit corrections]
S1 --> S2
@@ -296,62 +296,146 @@ patch release) or weeks (a regular project-cadence
release).
When the release containing the fix ships to users (PyPI / Helm
registry / equivalent),
[`security-issue-sync`](../../.claude/skills/security-issue-sync/SKILL.md)
-detects the release version on the next run and proposes the
-`pr merged` → `fix released` swap, which is the hand-off cue from
-remediation developer to release manager. The same pass proposes
-posting a one-shot **release-manager hand-off comment** with a
-numbered checklist (Steps 13–15 from the RM's perspective) and
-links to the paste-ready CVE JSON, the Vulnogram `#source` and
-`#email` tabs, and canned-response templates.
+detects the release version on the next run and — provided a
+**two-stage gate** is clear — proposes the `pr merged` →
+`fix released` swap (and the assignee swap from remediation
+developer to release manager) plus a one-shot
+**release-manager hand-off comment** with a numbered checklist
+of the three RM actions (REVIEW → READY, send advisory, sync
+closes the rest) and links to the Vulnogram `#source` and
+`#email` tabs.
+
+The two gates:
+
+1. **Mandatory body fields populated.** Six fields must be
+ non-empty and non-`_No response_`: *CWE*, *Affected versions*,
+ *Severity*, *Reporter credited as*, *Short public summary for
+ publish*, *PR with the fix*. The same check fires earlier, at
+ the `pr created` → `pr merged` transition (Step 11), so the
+ remediation developer is nudged to fill fields as soon as the
+ PR merges.
+2. **CVE record state is `REVIEW`.** Sync pushes the regenerated
+ CVE JSON to Vulnogram in the same pass (see *State
+ auto-promote* in the sync skill); the generator emits
+ `state = "REVIEW"` once Stage 1 is clear, and Vulnogram
+ accepts the field verbatim. Sync then verifies the saved
+ state.
+
+If either gate fails, sync instead posts (or PATCH-updates) a
+*Remediation-developer fill-fields comment* @-mentioning the
+remediation developer with the specific blocker (which fields
+are missing, or that the state is still `DRAFT` after the push).
+The tracker stays assigned to the remediation developer and the
+RM hand-off comment is **not** posted on this run — the RM never
+sees a hand-off while the record is in `DRAFT`. A later sync run
+that finds both gates clear proceeds with the hand-off.
### Step 13 — Send the advisory
-The release manager fills the remaining CVE fields:
-
-* CWE — see [cwe.mitre.org](https://cwe.mitre.org/data/index.html);
-* affected versions (`0, < <version released>`);
-* short public summary;
-* severity score per the
- [ASF severity rating](https://security.apache.org/blog/severityrating)
- (lazy consensus during discussion; voting if there's disagreement;
- RM has the final say to keep the announcement on schedule);
-* references — `patch` PR URL on `<upstream>`;
-* credits — `reporter`, `remediation developer`.
-
-The RM generates the description, sets the CVE to REVIEW (then
-READY), and sends the announcement emails from the project's CVE
-tool. Apply `announced - emails sent`, remove `fix released`. **The
-issue stays open** at this point — it closes only at Step 15.
-
-### Step 14 — Capture the public advisory URL
+By the time the release manager receives the hand-off comment,
+every mandatory CVE body field is already populated on the
+tracker (Step 12's gate), the CVE JSON has been pushed to
+Vulnogram, and the record is in `REVIEW` state. The RM's job is
+the three-step checklist in the hand-off comment, all of it
+single clicks in Vulnogram — **no shell commands, no JSON
+paste**:
+
+1. **Address reviewer feedback (if any) and promote to `READY`.**
+ Open the record's `#source` tab. If the CVE reviewer has
+ posted comments, work through them on the same thread; when
+ the thread is clear, change the **State** dropdown from
+ `REVIEW` to `READY` and save. Most CVEs go through `REVIEW`
+ with no reviewer comments — in that case the `REVIEW → READY`
+ flip is immediate.
+2. **Preview and send the advisory email.** Open the `#email`
+ tab. The page renders the exact advisory email that will go
+ out. Verify the recipients (`<users-list>` and
+ `<announce-list>`) and the body, then click **Send Email**.
+ This is the only manual send action.
+3. **Stop.** Sync drives the rest at the archive-URL trigger
+ (Step 14). The RM does not paste JSON anywhere, does not
+ click `READY → PUBLIC`, does not close the tracker.
+
+The severity score follows the
+[ASF severity rating](https://security.apache.org/blog/severityrating)
+(lazy consensus during discussion; voting if there's
+disagreement; the RM has the final say to keep the announcement
+on schedule). The RM may still need to adjust body fields before
+sending if reviewer feedback prompts it; the regenerated JSON is
+re-pushed automatically by the next sync.
+
+Sync does not flip `fix released → announced - emails sent` at
+this step; that label transition fires at Step 14 along with the
+rest of the post-advisory close-out. **The issue stays open** at
+this point — it closes at Step 14.
+
+### Step 14 — Capture the public advisory URL and close out
Once the announcement is archived on the users@ list, the next
-`security-issue-sync` run finds the URL, populates the *Public
-advisory URL* body field (a dedicated field on the issue template —
-never reuse the *"Security mailing list thread"* field), regenerates
-the CVE JSON attachment (now carrying a `vendor-advisory` reference),
-and adds the `announced` label. The same pass proposes a one-shot
-**publication-ready notification comment** for the release manager.
-
-Until *Public advisory URL* is populated, the sync skill will not
-propose `announced` — publishing a CVE with an empty
-`vendor-advisory` reference would leak a broken record into
-`cve.org`.
-
-### Step 15 — Publish the CVE record and close the issue
-
-The release manager opens the project's CVE tool's `#source` view at
-`https://cveprocess.apache.org/cve5/<CVE-ID>#source`, copies the
-latest CVE JSON attachment from the tracker (the one regenerated in
-Step 14), pastes it into the form, saves, and moves the record from
-READY to PUBLIC — propagating to [`cve.org`](https://cve.org). Then
-closes the tracker (no label updates). `security-issue-sync`
-follows the close with an `archiveProjectV2Item` mutation so the
-closed tracker leaves the active board (see
-[`tools/github/project-board.md` — *Archive a board
item*](../../tools/github/project-board.md#archive-a-board-item--terminal-state-cleanup)).
-
-A tracker that sits on `announced` for more than a day or two is a
-signal to ping the RM.
+`security-issue-sync` run detects the archive URL and fires a
+**single combined apply** that drives the entire post-advisory
+close-out — there is no separate RM "publish + close" step. In
+one pass sync:
+
+1. Populates the *Public advisory URL* body field (a dedicated
+ field on the issue template — never reuses the *"Security
+ mailing list thread"* field).
+2. **Extracts the short public summary** from the archived
+ advisory email body (the prose between the CVE header and the
+ *Affected version range* block) and writes it back to the
+ *Short public summary for publish* body field so the
+ tracker's summary matches what actually shipped.
+3. Flips the tracker labels: adds `announced - emails sent` and
+ `announced`, removes `fix released`.
+4. Regenerates the CVE JSON attachment — the generator picks up
+ the new short summary as `descriptions[].value` and the URL
+ as a `vendor-advisory` reference, and now emits
+ `state = "PUBLIC"`.
+5. Re-pushes the regenerated JSON to the Vulnogram record over
+ the OAuth API.
+6. Moves the Vulnogram record `READY → PUBLIC` via
+ [`vulnogram-api-record-publish`](../../tools/vulnogram/oauth-api/README.md)
+ — the CNA-feed dispatch to [`cve.org`](https://cve.org),
+ formerly a manual UI click but now driven by sync since the
+ archive URL is the real-world signal that the advisory has
+ shipped.
+7. Moves the project-board column to `Announced`.
+8. Closes the tracker as `completed`.
+9. Archives the tracker from the `Announced` column via the
+ `archiveProjectV2Item` GraphQL mutation (see
+ [`tools/github/project-board.md` — *Archive a board
item*](../../tools/github/project-board.md#archive-a-board-item--terminal-state-cleanup)).
+10. **If every sibling on the tracker's milestone is also closed
+ at that moment**, closes the milestone too.
+11. Posts a purely-informational *wrap-up comment* tagging the
+ RM as a timeline marker that the lifecycle is complete. No
+ manual asks — everything actionable was already taken care
+ of by the steps above.
+
+Until *Public advisory URL* is populated, the sync skill will
+not propose `announced` or any of the downstream steps —
+publishing a CVE with an empty `vendor-advisory` reference would
+leak a broken record into `cve.org`.
+
+When the OAuth session is not available (no credentials, expired
+cookie, transient HTTP error), the JSON re-push and the
+`READY → PUBLIC` advance and the tracker close all defer to the
+next sync that resolves the push issue; the manual-paste variant
+of the publication-ready notification comment is posted in that
+case explaining the deferral.
+
+### Step 15 — RM verifies the close-out landed
+
+There is no manual close step. The release manager's last
+post-Send-Email action is **none** — sync at Step 14 closes the
+tracker, moves the Vulnogram record to PUBLIC, archives the
+board item, and (conditionally) closes the milestone. The RM
+receives the wrap-up comment as a timeline event marker.
+
+A tracker that sits on `announced - emails sent` without
+`announced` for more than a day or two is a signal that sync
+did not see the advisory in the `<users-list>` archive yet
+(propagation lag, search-engine miss); re-run sync or wait for
+the next scheduled pass.
### Step 16 — Credit corrections
@@ -382,9 +466,9 @@ flowchart TD
D -->|step 10: public PR opened| E[pr created]
E -->|step 11: PR merges| F[pr merged]
F -->|step 12: release ships| G[fix released]
- G -->|step 13: advisory sent| H[announced - emails sent]
- H -->|step 14: archive URL captured| J[announced]
- J -->|step 15: RM moves CVE to PUBLIC + close| Z([issue closed])
+ G -->|step 13: RM sends advisory| H[announced - emails sent]
+ H -->|step 14: sync close-out at archive URL| J[announced + closed]
+ J -->|step 15: RM timeline marker| Z([issue closed])
classDef closed fill:#f8d7da,stroke:#842029,color:#000;
classDef done fill:#d1e7dd,stroke:#0f5132,color:#000;
@@ -418,9 +502,9 @@ labels the adopting project defines.
| `cve allocated` | A CVE has been reserved for the issue. Allocation itself
is PMC-gated (only the adopting project's PMC members can submit the CVE-tool
allocation form); a non-PMC triager relays a request to a PMC member via the
[`security-cve-allocate`](../../.claude/skills/security-cve-allocate/SKILL.md)
skill. | 6 | never |
| `pr created` | A public fix PR has been opened on `<upstream>` but has not
yet merged. | 10 | 11 (replaced by `pr merged`) |
| `pr merged` | The fix PR has merged into `<upstream>`; no release with the
fix has shipped yet. | 11 | 12 (replaced by `fix released` when the release
ships) |
-| `fix released` | A release containing the fix has shipped to users; advisory
has not been sent yet. | 12 | 13 (replaced by `announced - emails sent`) |
-| `announced - emails sent` | The public advisory has been sent to the
project's announce and users mailing lists (see `<project-config>/project.md →
Mailing lists`). The issue **stays open** after this label is applied; closing
is gated on the RM completing Step 15. | 13 | never (stays on the issue after
closing for audit history) |
-| `announced` | The public advisory URL has been captured in the tracking
issue's *Public advisory URL* body field and the attached CVE JSON has been
regenerated so its `references[]` now carries the `vendor-advisory` URL. The
tracking issue is waiting for the release manager to copy the CVE JSON into the
project's CVE tool, move the record to PUBLIC, and close the issue (Step 15).
No label changes at close — the issue closes with `announced` still set. | 14 |
never (stays on the issue a [...]
+| `fix released` | A release containing the fix has shipped to users; advisory
has not been sent yet. Gated on the two-stage check (six mandatory body fields
populated + CVE record state `REVIEW`). | 12 | 14 (replaced by `announced -
emails sent` at the archive-URL combined apply) |
+| `announced - emails sent` | The public advisory has been sent to the
project's announce and users mailing lists (see `<project-config>/project.md →
Mailing lists`). The issue **stays open** after this label is applied; closing
happens at Step 14 once sync sees the advisory archived on `<users-list>`. | 14
(combined apply with `announced`) | never (stays on the issue after closing for
audit history) |
+| `announced` | The public advisory URL has been captured in the tracking
issue's *Public advisory URL* body field and the attached CVE JSON has been
regenerated so its `references[]` now carries the `vendor-advisory` URL. The
Vulnogram record has been moved to PUBLIC and the tracker has been closed and
archived from the board — all in the same Step 14 combined apply. No label
changes at close — the issue closes with `announced` still set. | 14 | never
(stays on the issue after closing) |
| `wontfix` / `invalid` / `not CVE worthy` / `duplicate` | Closing
dispositions for reports that are not valid or not CVE-worthy. | 5 / 6 | — |
The [`security-issue-sync`](../../.claude/skills/security-issue-sync/SKILL.md)
diff --git a/docs/security/roles.md b/docs/security/roles.md
index 7f1ae53..2ac6100 100644
--- a/docs/security/roles.md
+++ b/docs/security/roles.md
@@ -23,7 +23,7 @@
- [For release managers — Steps 12–15](#for-release-managers--steps-1215)
- [Handoff from the remediation
developer](#handoff-from-the-remediation-developer)
- [Sending the advisory](#sending-the-advisory)
- - [Capturing the public archive URL](#capturing-the-public-archive-url)
+ - [Capturing the public archive URL and closing
out](#capturing-the-public-archive-url-and-closing-out)
- [Publishing the CVE and closing the
issue](#publishing-the-cve-and-closing-the-issue)
- [Post-release credit corrections](#post-release-credit-corrections)
- [Tools you use most](#tools-you-use-most-2)
@@ -295,9 +295,17 @@ tests manually before asking for review. Once approved,
re-open the PR in
Once the `<upstream>` PR merges, `security-issue-sync` moves the tracker
from `pr created` to `pr merged` and sets the milestone of the release the
-fix will ship in. The tracker then waits for the release train. When the
-release ships, sync swaps `pr merged` → `fix released` and the tracker
-becomes the release manager's responsibility. See
+fix will ship in. The tracker then waits for the release train.
+
+The `pr merged` → `fix released` hand-off is **gated**: every one of the six
+mandatory CVE body fields must be populated (*CWE*, *Affected versions*,
+*Severity*, *Reporter credited as*, *Short public summary for publish*,
+*PR with the fix*) **and** the CVE record must have advanced to `REVIEW`
+state in Vulnogram. If any field is still empty when the PR merges (Step 11)
+or when the release ships (Step 12), sync posts a
+**Remediation-developer fill-fields comment** on the tracker @-mentioning
+you with the specific missing fields. The tracker stays assigned to you and
+the RM hand-off is **not** posted until you fill them in. See
[Step 11](process.md#step-11--pr-merged) and [Step
12](process.md#step-12--fix-released).
### Tools you use most
@@ -328,31 +336,63 @@ Watch your `fix released` queue on the board. Until the
`pr merged` →
### Sending the advisory
-Review the attached CVE JSON on the tracker, fill any missing body fields
-(CWE, severity, affected versions), and send the advisory emails to
-`<announce-list>` / `<users-list>` from the ASF CVE tool.
-Add `announced - emails sent` and remove `fix released`. **Do not close the
-issue yet** — see [Step 13](process.md#step-13--send-the-advisory).
-
-### Capturing the public archive URL
-
-This is a handoff the sync skill handles for you: once the advisory has
-been archived on the users@ list, the next `security-issue-sync` run finds
-the URL, populates the *Public advisory URL* body field, regenerates the
-CVE JSON attachment, and moves the label to `announced`. See
-[Step 14](process.md#step-14--capture-the-public-advisory-url).
+By the time the hand-off comment lands, every mandatory body field is
+already populated (Step 12's gate) and the CVE JSON has been pushed to
+Vulnogram in `REVIEW` state. Your three actions are the numbered list in
+the hand-off comment, all single clicks in Vulnogram — **no shell
+commands, no JSON paste:**
+
+1. **Address reviewer feedback (if any) and promote `REVIEW → READY`.**
+ Open the record's `#source` tab. If the CVE reviewer has posted
+ comments, work through them on the same thread; when it is clear,
+ change the **State** dropdown from `REVIEW` to `READY` and save. Most
+ CVEs go through `REVIEW` with no reviewer comments and the flip is
+ immediate.
+2. **Preview and send.** Open the `#email` tab — it renders the exact
+ advisory email. Verify recipients (`<users-list>` and
+ `<announce-list>`) and body, then click **Send Email**.
+3. **Stop.** Sync drives the rest at the archive-URL trigger
+ ([Step
14](process.md#step-14--capture-the-public-advisory-url-and-close-out)).
+
+Sync does the `fix released → announced - emails sent` flip at Step 14,
+not here — you do not touch labels. **Do not close the issue** — sync
+does that too, in the same Step 14 combined apply.
+
+### Capturing the public archive URL and closing out
+
+This is a handoff the sync skill handles for you. Once the advisory has
+been archived on the users@ list, the next `security-issue-sync` run
+fires a **single combined apply** that:
+
+* writes the URL into the *Public advisory URL* body field;
+* extracts the short public summary from the archived advisory email and
+ writes it back to the *Short public summary for publish* body field;
+* flips labels `fix released → announced - emails sent + announced`;
+* regenerates and re-pushes the CVE JSON;
+* moves the Vulnogram record `READY → PUBLIC` (the CNA-feed dispatch to
+ [`cve.org`](https://cve.org));
+* moves the project board to the `Announced` column;
+* closes the tracker;
+* archives the tracker from the `Announced` column;
+* if every milestone-sibling is also closed at that moment, closes the
+ milestone too.
+
+See
+[Step 14](process.md#step-14--capture-the-public-advisory-url-and-close-out)
+for the full sequence.
### Publishing the CVE and closing the issue
-For every `announced` issue: open Vulnogram at
-`https://cveprocess.apache.org/cve5/<CVE-ID>#source`, paste the latest
-attached CVE JSON, save, and move the record from REVIEW to PUBLIC.
-Then close the issue (do not update any labels). This is the terminal
-step of the lifecycle. See
-[Step 15](process.md#step-15--publish-the-cve-record-and-close-the-issue).
+**Nothing to do.** Step 14 above already moved the Vulnogram record to
+PUBLIC, closed the tracker, and archived it from the board. You receive
+a purely-informational wrap-up comment as a timeline marker that the
+lifecycle is complete. See
+[Step 15](process.md#step-15--rm-verifies-the-close-out-landed).
-An issue that sits on `announced` for more than a day or two
-is a signal to ping the RM.
+A tracker that sits on `announced - emails sent` without `announced` for
+more than a day or two is a signal that sync did not see the advisory
+in the `<users-list>` archive yet — re-run sync or wait for the next
+scheduled pass.
### Post-release credit corrections
@@ -364,10 +404,12 @@ security team to push the information to `cve.org`. See
### Tools you use most
- [`security-issue-sync`](../../.claude/skills/security-issue-sync/SKILL.md) —
- *"sync announced"* at the start of each release window, to
- see the `announced` backlog needing a Vulnogram push. Also
*"sync CVE-YYYY-NNNN"* to drill into one specific CVE before sending the
- advisory.
+ advisory (confirms the hand-off comment was posted and reflects the
+ current record state). Subsequent syncs by the security team drive the
+ post-advisory close-out automatically when the archive URL appears on
+ `<users-list>`.
- [`generate-cve-json`](../../tools/vulnogram/generate-cve-json/SKILL.md) — to
regenerate the attachment on demand when a body field changes after the
- URL has been captured.
+ URL has been captured (rarely needed — sync regenerates and re-pushes
+ on every relevant body change).
