Security Advisory
Take a privately reported vulnerability through this repo's security advisory flow, ...
Install
npx skills add modelcontextprotocol/inspector --skill security-advisory -g -a claude-code -y- Repository
- modelcontextprotocol/inspector11.2k
- Category
- Security
- Updated
- 6d ago
- License
- See repository
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Take a privately reported vulnerability through this repo's security advisory flow, board it, verify who owns the code path, accept or reject, fix it in the private fork, ship to every affected release line, publish, then turn the card into public tracking. Use when a vulnerability is reported privately; when deciding whether an advisory is ours to fix; when looking up or creating its private fork; when answering a reporter; or when a GHSA-titled board card needs handling.
Handling a security advisory
Private vulnerability reporting is enabled on this repo and
SECURITY.md routes every report to it, the issue
chooser deliberately has no security template, because a vulnerability report
must not open a public issue. So an advisory never arrives as an issue, and for
most of its life it must not become one.
Two steps in this flow are outward-facing, and both stay human-gated: accepting an advisory (the reporter sees it) and publishing it (it becomes public, and there is no unpublish). Never automate either, never bulk-apply them, and never take either step because a checklist said to. Everything else here is mechanics.
⚠️ A CVE and the credits are choices made at publish time, not effects of publishing. Requesting a CVE is an optional action on the advisory, and a credit appears only when someone is explicitly added and accepts it. They are named here because they are the parts a maintainer must not forget, the reporter's credit especially, since nothing prompts for it, not because publishing performs them.
Related: /board-ops (the card IDs and recipes) and /issue-create, for the
labels, milestone and board that public tracking takes, after publication,
never merely after the release, since the release ships the fix while the
advisory may still be private.
⚠️ How that tracking is created depends on the affected lines, and only the v2 path is a conversion: a v2 issue is converted from the draft (filing one separately would duplicate both the issue and the card), while a v1 issue is filed on #11, because the draft is on #28 and cannot move there. Step 6 has the per-line sequence.
