cvebrainstorm

name: cve:brainstorm description: Plan responsible CVE disclosure, guide silent fixes, and BLOCK all public GitHub actions until CVE is properly handled

CVE Brainstorm — Responsible Disclosure & Public Output Gate

When to Use

• After cve:scan detects a confirmed HIGH/CRITICAL CVE
• When you need to plan responsible disclosure for a vulnerability
• When deciding whether to fix silently (dependency bump) or report formally
• Automatically invoked by cve:scan when findings are detected

When a CVE is detected by cve:scan, this skill guides responsible disclosure and blocks all public output until the vulnerability is properly handled.

CRITICAL SAFETY RULE

+===========================================================+
|                                                             |
|   CVE DISCLOSURE HOLD IS ACTIVE                             |
|                                                             |
|   ALL public GitHub actions are BLOCKED:                    |
|   - gh pr create / gh pr comment                            |
|   - gh issue create / gh issue comment                      |
|   - Commit messages containing CVE IDs                      |
|   - Any text containing vulnerability descriptions          |
|                                                             |
|   Accidental CVE disclosure:                                |
|   - Enables exploitation before patches exist               |
|   - Violates responsible disclosure agreements              |
|   - Causes legal and reputational harm                      |
|                                                             |
+===========================================================+

This hold is NOT optional. It cannot be skipped or deferred.

Workflow

flowchart TD
    START(["CVE found by cve:scan"]) --> HOLD["ACTIVATE CVE HOLD"]:::block
    HOLD --> P1["Phase 1: Find Disclosure Channel"]:::cve
    P1 --> P2["Phase 2: Assess Fix Options"]:::cve
    P2 --> CANFIX{"Silent fix possible?"}

    CANFIX -->|Yes| SILENTFIX["Apply silent fix"]:::fix
    CANFIX -->|No| REPORT["Guide disclosure to proper channel"]:::cve

    SILENTFIX --> VERIFY["Verify fix (no CVE refs in output)"]:::fix
    VERIFY --> RESOLVE

    REPORT --> WAITREPORT["User confirms: reported to channel"]:::cve
    WAITREPORT --> RESOLVE

    RESOLVE["LIFT CVE HOLD"]:::green
    RESOLVE --> DONE([Return to calling workflow])

    classDef block fill:#D32F2F,stroke:#333,color:white
    classDef cve fill:#FF5722,stroke:#333,color:white
    classDef fix fill:#FF9800,stroke:#333,color:white
    classDef green fill:#4CAF50,stroke:#333,color:white

Follow this diagram as the workflow.

Phase 1: Disclosure Channel Discovery

For each affected dependency with a confirmed CVE:

Step 1: Search for security policy

WebSearch: "<project-name> SECURITY.md responsible disclosure vulnerability report"

Step 2: Check GitHub repo directly

# If the dependency is on GitHub
gh api repos/<owner>/<repo>/contents/SECURITY.md --jq '.content' | base64 -d 2>/dev/null

Step 3: Present disclosure channel to user

For each CVE, present:

Disclosure Channel for <package>
================================
Project: <name> (<repo-url>)
Security policy: <SECURITY.md URL or "not found">
Report via: <email / form / GitHub Security Advisory>
Embargo: <timeline if documented, or "not specified">

If no security policy found:

No formal security policy found for <package>.
Options:
  1. Open a GitHub Security Advisory (private by default)
  2. Email the maintainer directly (check package metadata)
  3. Report to the ecosystem registry (PyPI, npm, etc.)

Phase 2: Fix Assessment

Interactive brainstorm with user, one question at a time:

Question 1: Fixed version available?

The CVE affects <package> <version>.

A fixed version exists: <fixed-version>
  -> Can we bump to <fixed-version> in this repo?

OR

No fixed version is available yet.
  -> We need to report and wait, or apply a workaround.

Question 2: Can the fix be applied silently?

If a fix is available:

Silent fix options (commit messages that DON'T reference the CVE):

  1. Dependency bump:
     Commit: "Bump <package> to <version>"
     (No CVE reference - just a version update)

  2. Configuration change:
     Commit: "Update <config> for <package> compatibility"
     (Describes the config change, not the vulnerability)

  3. Code workaround:
     Commit: "Refactor <component> to use <alternative>"
     (Describes the behavior change, not the security issue)

Which approach fits this situation?

Question 3: Does the fix change behavior?

Will bumping <package> from <old> to <new> change any behavior?

  If yes:
  - Tests must verify the new behavior
  - Test descriptions must NOT reference the CVE
  - Use neutral language: "test compatibility with <package> <version>"

  If no:
  - Straightforward bump, minimal risk

Phase 3: Public Output Blocking (HARD GATE)

While the CVE hold is active, REFUSE the following actions:

Blocked Actions

Allowed Actions

CVE Reference Detection

Before ANY public output, scan for these patterns:

• CVE-\d{4}-\d+ (CVE IDs)
• Words: "vulnerability", "exploit", "security flaw", "attack vector"
• Specific vulnerability class names when combined with the affected package name

If detected, STOP and rewrite using neutral language.

Phase 4: Resolution

The CVE hold is resolved when the user confirms ONE of:

Resolution 1: Reported to proper channel

User: "CVE reported to <channel>"

Response:
  CVE hold lifted.
  - Reported to: <channel>
  - Embargo: <timeline if known>

  You may now proceed with public GitHub actions.
  REMINDER: Do NOT reference the CVE in public until the embargo lifts.

Resolution 2: Fixed silently

User: "CVE fixed, bumped to <version>"

Response:
  CVE hold lifted.
  - Fix: bumped <package> to <version>
  - Commit message: <the neutral message used>

  Verify: commit message and PR description contain no CVE references.
  You may now proceed.

Resolution 3: False positive

User: "False positive, not a real CVE"

Response:
  CVE hold lifted.
  - Reason: false positive
  - Evidence: <user's explanation>

  You may now proceed.

Resolution 4: User override

User: "CVE hold resolved" (explicit override)

Response:
  WARNING: Lifting CVE hold by user override.
  - No disclosure confirmed
  - No fix confirmed

  Ensure you have handled this CVE through appropriate channels
  before publishing any related work.

  CVE hold lifted.

Anti-Patterns

Related Skills

• cve:scan - Detection engine that triggers this skill
• tdd:ci - Calling workflow (Phase 3.5 gate)
• git:commit - Commit conventions (CVE ID check added)