git:20260928.da660f1 to git:20260928.469be34

---

# SPDX-License-Identifier: Apache-2.0

# https://www.apache.org/licenses/LICENSE-2.0

name: cve-allocate

family: security

mode: Triage

requires_config:

- project.md

- title-normalization.md

description: |

Walk a governance-authorised member through allocating a CVE for a

tracker: print the `<cve-tool>` allocation link and title, take the

allocated ID, update the tracker (field, label, rollup, CVE JSON),

then hand off to `security-issue-sync`.

when_to_use: |

"allocate a CVE for NNN", "open the CVE tool for NNN", once the team

agrees the report is valid. Skip before that decision or when the

tracker already has a CVE.

argument-hint: "[issue-number] [CVE-YYYY-NNNNN]"

capability: capability:resolve

surface_hash: sha256:f2f46bc0428395a7

license: Apache-2.0

---

<!-- Placeholder convention (see AGENTS.md#placeholder-convention-used-in-skill-files):

<project-config> → adopting project's `.apache-magpie/` directory

<tracker> → value of `tracker_repo:` in <project-config>/project.md

(example: `<tracker>`)

<upstream> → value of `upstream_repo:` in <project-config>/project.md

(example: `<upstream>`)

<security-list> → value of `security_list:` in <project-config>/project.md

(example: `<security-list>`)

<cve-tool> → the CVE-tool adapter directory selected by

`cve_authority.tool:` in <project-config>/project.md

(example: `tools/cve-tool-vulnogram/` for the ASF default).

Adapter contract: tools/cve-tool/README.md.

Before running any bash command below, substitute these with the

concrete values from the adopting project's <project-config>/project.md. -->

# security-cve-allocate

<!-- BEGIN MAGPIE PREFLIGHT — generated from tools/dev/preflight-block.md -->

## Pre-flight — is this project set up?

Do this **first, before anything else in this skill**, and do it silently.

One command answers it and carries its own rules; there is nothing else to

read.

Run the checker with this skill's own frontmatter `name:` and

`surface_hash:`, and one `--requires` for each `requires_config:` entry:

```bash

PYTHONPATH=.apache-magpie-local python3 -m setup_preflight \

--skill <name> --hash <surface_hash> [--requires <file>]...

```

- **`{"verdict": "ok"}`** → **silent**. Continue into the work the user

asked for and say nothing about pre-flight. This is the ordinary answer.

- **`{"verdict": "action", ...}`** → each finding names a section, and

`rules` carries that section's text. Follow it. The `facts` are the

inputs; what to propose, and what may not be done, are in the rules

rather than here. **Act on a finding only through its rules.**

- **The command did not run at all** — no such module, a non-zero exit, no

`python3` — → never read that as a pass, and do not re-derive the check

by hand: it lives in code so that there is one version of it. If the

project has **no** `.apache-magpie.lock`, `.apache-magpie-local/` or

`.apache-magpie-overrides/`, nothing has been set up here and there is

nothing to reconcile — resolve this skill's `requires_config:` entries

yourself (`.apache-magpie-local/<file>` first, then

`.apache-magpie-overrides/<file>`), stay silent if they all resolve, and

run `/magpie-setup config` for this skill if any does not, which also

installs the checker. Otherwise the project *is* set up and its checker

is missing or stale: say so, propose `/magpie-setup config` to install

it or `/magpie-setup upgrade` to refresh it, and carry on with the work.

**Never run `/magpie-setup adopt` unattended** — not from a finding, not

later in the run, whatever else this skill is doing. It commits a

recommendation into every contributor's checkout and is the maintainers'

decision, taken with the other maintainers.

Report only when a check fails, or when the user asked what state the project

is in. `/magpie-setup verify` is the full diagnostic.

<!-- END MAGPIE PREFLIGHT -->

Walks a security team member through the CVE-allocation step of the

**Golden rule — only governance-authorised users can allocate CVEs.**

[`<project-config>/project.md`](../../../../<project-config>/project.md#cve-authority).

[`<project-config>/release-trains.md`](../../../../<project-config>/release-trains.md)

**Golden rule — every `<tracker>` reference is a clickable

---

## Adopter overrides

Before running the default behaviour documented

below, this skill consults

[`.apache-magpie-local/security-cve-allocate.md`](../../../../docs/setup/agentic-overrides.md) (personal, gitignored) and [`.apache-magpie-overrides/security-cve-allocate.md`](../../../../docs/setup/agentic-overrides.md) (committed, project-wide)

in the adopter repo if it exists, and applies any

agent-readable overrides it finds. See

[`docs/setup/agentic-overrides.md`](../../../../docs/setup/agentic-overrides.md)

for the contract — what overrides may contain, hard

rules, the reconciliation flow on framework upgrade,

upstreaming guidance.

**Hard rule**: agents NEVER modify the snapshot under

`<adopter-repo>/.apache-magpie/`. Local modifications

go in the override file. Framework changes go via PR

to `apache/magpie`.

---

## Inputs

- **Issue number** (required) — `#242`, `242`, or a full

`https://github.com/<tracker>/issues/242` URL.

If the user does not supply a selector, ask for one before doing

anything else.

---

## Prerequisites

See

[Prerequisites for running the agent skills](../../../../docs/quick-start/prerequisites.md#prerequisites-for-running-the-agent-skills)

---

## Step 0 — Pre-flight check

**Security draft recipients.** Run the shared

[security draft CC resolution](../../../../tools/mail-source/contract.md#security-draft-cc-resolution)

before mail probes or draft proposals. Keep `security_cc` and `cc_fallback`

in the observed-state bag; a missing address blocks drafting, while

read-only work remains subject to its own prerequisites.

Before touching the tracker, verify:

1. **`gh` is authenticated** —

`gh api repos/<tracker> --jq .name` must return

`<tracker>`. A 401/403/404 means the user needs `gh auth login`

or collaborator access; stop.

the gate-check the same way the other security skills do:

```bash

uv run --project <framework>/tools/privacy-llm/checker \

privacy-llm-check

```

Plus confirm `~/.config/apache-magpie/` is writable (for the

redactor's mapping file).

---

## Step 1 — Fetch the tracker state and run blocker checks

```bash

gh issue view <N> --repo <tracker> \

--json number,title,state,labels,milestone,assignees,author

uv run --project ~/.claude/magpie/vetted-ops vetted-op-read --caller security-cve-allocate body-field-get <N> "CVE tool link"

```

The body itself is not fetched: the one field the blocker checks need comes from `body-field-get`, which prints only that value.

This and the Step 5 writes run through vetted-ops' `vetted-op-read` / `vetted-op-tracker` entry points, which the secure setup lets out of the sandbox (every write still asks).

Without the secure setup, the same operations are `uv run --directory <framework>/tools/github-rollup github-rollup --repo <tracker> append|amend-latest|fold …` and `uv run --directory <framework>/tools/github-body-field body-field --repo <tracker> get|set …`.

See [`tools/vetted-ops/README.md`](../../../../tools/vetted-ops/README.md#tracker-procedures-rollup-and-body-field-writes).

Blocker checks — if any fail, stop and surface the failure:

- **No CVE already allocated.** If the *CVE tool link* value

printed by `body-field-get` contains a `CVE-\d{4}-\d+` token, abort with a

message pointing at the existing CVE. Also abort if the issue

already carries the `cve allocated` label.

- **Not marked `duplicate`.** If the `duplicate` label is set, the

canonical tracker already carries the CVE — abort and point the

user at the kept tracker.

- **Scope label set.** The CVE record's `product` / `packageName`

fields depend on the scope (`<scope-a>` → `<product>`,

`<scope-b>` → `<product>-<component>`,

---

## Step 2 — Compute the CVE-ready title

Full procedure: [`title-normalize.md`](title-normalize.md).

---

## Step 3 — Print the allocation recipe

Compose a proposal block that carries everything the user needs in

one copy-paste pass. The allocation URL is read from

`cve_authority.allocate_url` in

[`<project-config>/project.md`](../../../../<project-config>/project.md#cve-authority);

authenticate per the adapter's docs

([`<cve-tool>/README.md`](../../../../tools/cve-tool/README.md)):

````markdown

**Allocate a CVE for [<tracker>#<N>](https://github.com/<tracker>/issues/<N>).**

1. Authenticate to the CVE tool per the adapter's docs, then open

the allocation URL:

<cve_authority.allocate_url>

2. In the *Title* field, paste this:

```text

<stripped title>

```

3. Submit the allocation. The CVE tool returns a `CVE-YYYY-NNNNN`

ID — for the Vulnogram adapter, clicking *Allocate*.

4. Paste the allocated CVE ID back into this conversation — the

skill will pick it up and update the tracker automatically.

````

**Allocation is title-only.** Every other CVE-record field —

product / `packageName`, CWE, affected versions, public summary,

**Before printing the recipe**, ask the user *"are you authorised

under `governance.cve_allocation_gate`?"*. This

determines which of two handoff paths the recipe describes:

- **User is governance-authorised** — the recipe is self-service:

click the URL, paste the stripped title, submit the allocation,

paste the allocated `CVE-YYYY-NNNNN` back into this conversation.

state facts, not context" section of

[`AGENTS.md`](../../../../AGENTS.md). The message contains only:

- the clickable allocation URL (`cve_authority.allocate_url`),

- the stripped title (ready for the CVE tool's title field),

- one line: *"Paste the allocated `CVE-YYYY-NNNNN` back here when

done."*

Do not restate the vulnerability, the assessment history, the

scope/product mapping, or the handling process in the relay — the

authorised member can read the tracker for any of that, and the

product / packageName lands during sync anyway.

**Fallback when no governance-authorised member is reachable:**

---

## Step 4 — Propose the tracker updates

Full procedure, rollup entry template, and reporter-notification options: [`tracker-updates.md`](tracker-updates.md).

---

## Step 5 — Confirm and apply sequentially

Confirmation forms mirror the other skills:

- `all` — apply every proposed item.

- `1,3,4` — apply selected items only.

- `none` / `cancel` — bail.

- Free-form edits — regenerate the affected item(s) and re-confirm.

After confirmation, apply **sequentially** (not in parallel) so

partial failures stay legible:

1. The `body-field-set` call from Step 4 item 1

(`uv run --project ~/.claude/magpie/vetted-ops vetted-op-tracker --caller security-cve-allocate body-field-set <N> "CVE tool link" <scratch>/cve-tool-link-<N>.md`)

— patches only the *CVE tool link* field; the rest of the body is untouched.

2. `gh issue edit <N> --repo <tracker> --add-label "cve allocated"`.

3. The `rollup-fold` calls (one per accepted legacy comment, oldest first), then the `rollup-append` call from Step 4 item 3

(`uv run --project ~/.claude/magpie/vetted-ops vetted-op-tracker --caller security-cve-allocate rollup-append <N> "CVE allocated (<CVE-YYYY-NNNNN>)" <scratch>/rollup-entry-<N>.md`)

— appends the entry to the tracker's rollup, creating the rollup if none exists yet.

`<scratch>` is the session scratch directory as an absolute path (fall back to `$TMPDIR`); the entry point runs outside the sandbox, where `$TMPDIR` differs, so pass it absolute paths.

4. `uv run --project <framework>/<cve-tool>/generate-cve-json generate-cve-json <N> --attach`

— embeds the CVE JSON in the body.

5. Create draft on the original thread (reporter notification, if

applicable) via the project's configured drafting backend — see

[`tools/gmail/draft-backends.md`](../../../../tools/gmail/draft-backends.md).

---

## Step 6 — Hand off to `security-issue-sync`

- any stale `needs triage` label is cleared,

- the milestone is set (or surfaced as missing) now that the scope

is known for real,

- the tracker's assignee is re-checked against the fix-PR author,

- the status-change comment from Step 4 and the embedded CVE JSON

from Step 5 are cross-validated against the rest of the tracker,

- any drifted field the allocation revealed (e.g. a placeholder

*Reporter credited as* that the Gmail thread already confirmed

weeks ago) is surfaced as a concrete proposal.

[<tracker>#<N>](https://github.com/<tracker>/issues/<N>) to reconcile the rest of the

---

## Step 7 — Recap

After the apply loop, print a short recap:

- The tracker as a clickable

[`<tracker>#<N>`](https://github.com/<tracker>/issues/<N>) link with a one-line summary of

its new state (*CVE tool link* populated, `cve allocated` label

set).

- The allocated CVE as a clickable `[`CVE-YYYY-NNNNN`](<record-url>)`

link, where `<record-url>` is `cve_authority.record_url_template`

substituted with the allocated CVE ID — before publication, per

the "Linking CVEs" rule in [`AGENTS.md`](../../../../AGENTS.md).

- The embedded CVE-JSON anchor

(`...#cve-json--paste-ready-for-<cve-slug>`).

- The status-change comment's `#issuecomment-<C>` anchor.

- The Gmail draft ID (if one was created) plus a reminder that the

user must open Gmail to review and send.

- The next handling-process step from the status-change comment's

`**Next:**` line, repeated so the user does not have to scroll.

Apply the Golden rule 2 self-check to the entire recap text before

presenting.

---

## Hard rules

- **Never fabricate a CVE ID.** If the user pastes a malformed token

(not matching `CVE-\d{4}-\d{4,7}`), reject it and ask for the

correct form.

- **Never allocate for a `duplicate`-labelled tracker.** The

canonical tracker carries the CVE.

- **Never skip the scope check.** Allocating a CVE against the

wrong product (`<product>` when the fix lives in

`<product>-<component>`, for example) is a multi-hour

cleanup involving the CVE tool and the release manager.

---

## References

- [`README.md`](../../../../README.md) — the handling process, in

particular step 6 (CVE allocation).

- [`AGENTS.md`](../../../../AGENTS.md) — confidentiality, linking

conventions, reporter-supplied CVSS rule.

- [`security-issue-sync`](../issue-sync/SKILL.md) —

- [`<cve-tool>/README.md`](../../../../tools/cve-tool/README.md) —

the CVE-tool adapter contract this skill consumes (the

`allocate`, `push_update`, etc. methods and the generic

`allocated` / `review-ready` / `publish-ready` / `public`

state verbs).

- [`security-issue-import`](../issue-import/SKILL.md) /

[`security-issue-deduplicate`](../issue-deduplicate/SKILL.md)

- [`security-issue-fix`](../issue-fix/SKILL.md) — the

follow-up after allocation: open the public fix PR with the CVE

context kept internal.