CVE intelligence intake gate

A tool-agnostic prompt that turns a fresh CVE, GHSA, OSV, vendor bulletin, scanner alert, or ticket into one of five bounded outcomes:

  • accept for a remediation PR;
  • accept for temporary containment;
  • suppress as not exposed;
  • stop for human triage;
  • reject as an unverified signal.

Use this before handing an agent a remediation prompt when the advisory is new, sources disagree, exploitability is unclear, or the scanner finding lacks enough context for a reviewer-ready fix.

What this prompt does

  1. Reads the advisory signal and normalizes its identifiers, aliases, affected surface, affected range, fixed versions, mitigations, and source links.
  2. Prioritizes primary sources: vendor patch notes, GitHub Advisory Database, CVE/NVD, OSV or package-registry advisories, then CISA KEV or exploitation signals.
  3. Checks repository evidence: manifests, lockfiles, images, code paths, middleware, runtime configuration, deployment artifacts, and scanner output.
  4. Decides whether a safe agent task exists.
  5. Outputs either a remediation packet, a containment packet, a suppression note, or TRIAGE.md.

When to use it

  • A CVE or GHSA just landed and the team needs to know whether an agent should patch, contain, suppress, or stop.
  • Multiple sources disagree about fixed versions, severity, affected ranges, or exploitability.
  • A scanner reports a vulnerable dependency but does not prove reachability or ownership.
  • The advisory targets an agent, MCP, browser automation, workflow, identity, tenant, or connector surface where naive upgrades may miss the real boundary.

Do not use this to replace the actual remediation recipe. This gate decides whether the remediation prompt is safe to run and what evidence it must carry.

Inputs

  • Advisory ID: CVE, GHSA, OSV-family ID, ecosystem advisory ID such as PYSEC, RUSTSEC, GO, USN, RHSA, ALAS, or VMSA, vendor ID, package-registry advisory, or scanner finding ID.
  • Optional affected package, image, runtime, route, plugin, framework, or product hint.
  • Scanner output, ticket text, SBOM row, dependency graph row, or incident note.
  • Repository path or deployment scope the agent is allowed to inspect.
  • The local intake policy: data/intelligence/cve-intelligence-intake-gates.json.
  • Optional local evaluator: scripts/evaluate_cve_intelligence_intake.py.

The prompt

You are running the CVE intelligence intake gate for this repository.

Output exactly one of:

- `REMEDIATION_PACKET.md`
- `CONTAINMENT_PACKET.md`
- `SUPPRESSION.md`
- `TRIAGE.md`
- `REJECTED_SIGNAL.md`

Do not change application code, dependencies, lockfiles, deployment manifests,
runtime configuration, scanner suppressions, or tickets. This is an intake and
routing task only.

## Step 0 - Load policy and scope

1. Read `data/intelligence/cve-intelligence-intake-gates.json`.
2. Record the repository path, service, package, image, route, or deployment
   scope you are allowed to inspect.
3. Record `evaluation_date` in `YYYY-MM-DD` format for this intake decision.
4. Normalize the advisory identifiers: CVE, GHSA, OSV-family ID, ecosystem or
   vendor advisory ID, registry advisory ID, scanner finding ID, and aliases.
   The canonical ID must match a supported advisory format exactly. If the
   only candidate is a prefix plus extra text, or the canonical ID is malformed
   even though an alias is valid, stop with `TRIAGE.md`.

## Step 1 - Gather primary evidence

For each available source, capture the link, publisher, timestamp if present,
affected surface, affected range, fixed version or commit, mitigation, severity,
and exploitation status.

A source type without an absolute `http` or `https` source URL is not primary
evidence. Keep it as a note, but stop with `TRIAGE.md` unless another primary
source link is available. Likewise, `primary_source_backed: true` does not turn
scanner output, ticket text, social-media links, or unknown-source links into
primary evidence.

Use this priority order:

1. Vendor advisory, release notes, patch commit, or security bulletin.
2. GitHub Advisory Database.
3. CVE record or NVD entry.
4. OSV, package-registry advisory, or ecosystem security feed.
5. CISA KEV, vendor exploitation notice, incident signal, or trusted threat
   intelligence feed.

A known-exploited or threat-intelligence feed raises priority, but it is not a
standalone remediation source. Pair it with a vendor advisory or patch, GitHub
Advisory Database entry, CVE/NVD record, OSV entry, or package-registry
advisory before accepting remediation, containment, or suppression.

If sources disagree in a way that changes the fix, stop with `TRIAGE.md`.

## Step 2 - Prove repository relevance

Inspect only the allowed scope.

1. Search manifests, lockfiles, SBOMs, image definitions, vendored code, runtime
   config, deployment manifests, and scanner output for the affected surface.
2. Identify whether the vulnerable component is direct, transitive, vendored,
   image-layer, runtime-provided, plugin-provided, or deployment-provided.
3. Determine whether exploit preconditions are present: untrusted input,
   internet reachability, tenant crossing, auth or billing gate, file upload,
   model/checkpoint loading, deserialization, SSRF-capable URL fetch, command
   execution, browser automation, MCP tool execution, or connector approval.
4. Capture exact evidence paths and commands. Do not use secrets, production
   customer data, live tokens, or exploit payloads.

## Step 3 - Choose one decision

Choose `REMEDIATION_PACKET.md` only when all are true:

- stable identifier exists;
- affected surface maps to repository-owned code, dependency, image, or
  deployment artifact;
- fixed version, fixed commit, or safe configuration mitigation exists;
- the fix is inside repository ownership and a named owner is recorded;
- reviewer-runnable verification exists.

Choose `CONTAINMENT_PACKET.md` when exposure is plausible or confirmed but the
full fix is blocked and a temporary control can reduce exposure. Include an
owner and `YYYY-MM-DD` follow-up date that is not earlier than
`evaluation_date`. Name the exact control, configuration change, rule, or
compensating action; a boolean temporary-control marker is not enough.

Choose `SUPPRESSION.md` when the vulnerable surface is absent, unreachable,
dev-only, test-only, or below exploit preconditions. Include owner,
`YYYY-MM-DD` expiration that is not already stale, and recheck command.

Choose `TRIAGE.md` when evidence is missing, sources disagree, ownership is
unclear, the fix requires a migration, or safe verification is not possible.

Choose `REJECTED_SIGNAL.md` when the claim has no primary source, no stable
affected surface, and no safe reviewer-runnable validation.

## Step 4 - Write the packet

Every output must include:

- canonical ID and aliases;
- source links used;
- which source links counted as standalone primary evidence and which were
  auxiliary, invalid, or non-standalone;
- affected surface and affected range;
- repository evidence found;
- decision and why;
- evaluation date used for follow-up freshness;
- priority modifiers such as KEV, public reachability, agent/control-plane
  impact, or no known fix;
- selected SecurityRecipes recipe or prompt if one is ready to run;
- fix, containment, suppression, triage, or rejection path;
- exact verification or recheck commands;
- owner for the decision record;
- `YYYY-MM-DD` follow-up date, not earlier than `evaluation_date`, when action
  continues outside this packet.

## Safety rules

- Do not auto-merge.
- Do not generate exploit payloads against live systems.
- Do not log secrets, cookies, tokens, tenant IDs, customer content, or private
  vulnerability details.
- Do not change unrelated dependencies while routing one advisory.
- Do not disable authentication, authorization, validation, or tests to make an
  upgrade appear safe.
- Do not open write-capable connectors only to gather vulnerability context.

Output contract

The output is a routing artifact, not a patch. A reviewer should be able to read it and decide whether to run a per-CVE recipe, the generic vulnerable-dependency workflow, the base-image workflow, containment, or human triage.

Validate reviewer-ready packets with:

python3 scripts/evaluate_cve_intelligence_intake.py \
  --packet path/to/intake-packet.json

For model-generated Markdown packets, translate the required fields into JSON first or pass them as CLI flags. The evaluator checks policy evidence, primary source backing, source disagreement, ownership clarity, verification safety, exposure status, and whether the packet should remediate, contain, suppress, triage, or reject the signal.

The evaluator output includes source_evidence, valid_primary_source_count, and invalid_or_non_standalone_source_count. Use those fields in review notes and CI logs so a KEV, scanner, ticket, social-media, or unknown-source link does not get mistaken for standalone remediation evidence.

Guardrails

  • Primary-source backed. Scanner text is an input, not the final source of truth. KEV-only or threat-intelligence-only packets need a remediation source before an agent patches.
  • Exposure-aware. Installed is not the same as reachable.
  • Fix-path required. No remediation PR without a known fixed version, fixed commit, safe mitigation, or explicit containment path.
  • Stop on disagreement. If the affected range or fixed version differs across sources in a way that changes the patch, triage.
  • Reviewer-runnable verification. Every accepted task names the command or probe that proves the decision.