| name | resolve-cve |
| description | Resolve a dependency CVE in the Wazuh Dashboard platform — confirm the vulnerable package is actually present and reachable, apply the least-invasive remediation (direct bump, lockfile dedupe, or scoped resolution), verify build/tests/audit, and hand off a prepared PR. Use when the user asks to fix or resolve a CVE / dependency vulnerability, or provides a CVE id or CVE issue URL. |
Resolve a dependency CVE
Remediation flow for a dependency vulnerability. Pairs with analyze-dashboard-vuln
(triage/verdict + issue drafting) — use that first if it's not yet confirmed the
repo is affected. This skill assumes remediation is wanted.
Optional input: a CVE-XXXX-XXXXX id or a CVE issue URL. Without one, look up open
CVE issues and ask which to resolve.
repo-specific (wazuh-dashboard): this is the platform, a single Yarn
workspace with one root package.json + one root yarn.lock (unlike the
plugins repo's three independent plugins). Dependencies install/build via
yarn osd bootstrap. Forced versions live in the root package.json > resolutions block. Tests generally run on the host here (the full OSD
checkout ships setup_node_env).
Workflow
- [ ] 1. Identify the CVE (package, vulnerable range, safe version, severity)
- [ ] 2. Verify presence + reachability in the workspace
- [ ] 3. Remediate with the least-invasive strategy that works
- [ ] 4. Verify (bootstrap + tests + audit; vulnerable version gone)
- [ ] 5. Write a report to tmp/ and deliver via create-pr (prepare mode)
1. Identify
Read the CVE. If given an issue URL: gh issue view <url>. Extract: affected
package, vulnerable version range, recommended safe version, severity, and the
GHSA if present. If you cannot confirm whether the repo is truly affected, run
to get the reachability verdict before changing code.
