cve-zero-day-scanner

name

cve-zero-day-scanner

description

Run a directed CVE and zero-day risk pass against the project's dependency graph, container base images, infrastructure providers, and known exploit chains relevant to the detected stack and platform matrix. Verify advisory-source documentation with Context7 MCP, then query live sources such as CISA KEV, NVD, GitHub Security Advisories, distro trackers, vendor PSIRTs, and ecosystem registries with recorded timestamps, parameters, and evidence. Produces a prioritized vulnerability register with exploitability, blast radius, mitigation, owner, patch plan, and a release-gate verdict. Use before any release, after any dependency or base-image bump, and on schedule for long-lived services.

CVE / Zero-Day Scanner

Role

Move from "we updated deps last quarter" to "as of today, these CVEs apply to this build, this one is on the KEV list, here is the patch plan and the owner". Treat unknown-unknowns by checking active exploitation feeds, not only static CVSS.

Start By

1. Read references/cve-workflow.md.
2. Pull the dependency graph: language lock files, container base images, OS packages, runtime versions, infra provider versions, MCP servers, plugins, model versions.
3. Pull the platform matrix from platform-detector and the OWASP status from security-owasp-web/-llm/-agentic.
4. Use Context7 MCP to verify current source documentation and query formats for CISA KEV, NVD, GitHub Security Advisories, ecosystem advisories, distro trackers, and vendor PSIRTs. Then query the live feeds/APIs/tools directly and record source URL, timestamp, parameters, result IDs, and raw evidence path.

Procedure

1. Build the asset inventory: every dependency, image, OS package, infra provider, plugin, and model with its pinned version.
2. Query advisory sources for each asset; collect candidate CVEs.
3. For each candidate CVE, compute: exposure path (is the vulnerable code path reachable?), severity (CVSS), exploitability (KEV listing, public PoC, exploit kit), blast radius, fix availability.
4. Bucket findings: Critical-now (KEV + reachable), Critical-latent (KEV but not reachable), High (CVSS ≥ 7 + reachable), Medium, Low.
5. Cross-check supply chain: signed artifacts, SLSA level, dependency confusion risk, typo-squat candidates near recent installs.
6. Produce patch plan: per finding, action (upgrade, pin, replace, mitigate-in-config, accept-risk-with-expiry), owner, ETA.
7. Issue release-gate verdict: Go / Conditional / Hold.

Principal-Level Defaults

• Follow ../../routing/principal-operating-model.md.
• Use Context7 MCP every run for source/API documentation, but never treat Context7 output as the vulnerability feed itself.
• Keep a decision trace: source feeds queried, query date/time, query parameters, response evidence, false-positive notes, accepted-risk register with expiry.
• Refuse to mark a CVE Resolved without naming the artifact hash or version that contains the fix.
• Escalate any KEV-listed vulnerability before any cosmetic work; KEV blocks release.

Output Artifacts

• Asset inventory with pinned versions
• Vulnerability register with severity, exploitability, exposure path, fix availability
• KEV-listed exposures (always called out separately)
• Patch plan with owners and ETAs
• Accepted-risk register with named approver and expiry
• Release-gate verdict

Quality Bar

• No KEV-listed finding accepted without a written exception by a named approver and a near-term expiry.
• No "scan passed" without naming the live feeds/APIs/tools, query date/time, query parameters, response evidence, and lock file hashes scanned.
• No vulnerable transitive dependency hidden behind "we only use a subset" without proving the subset.
• No release gate without re-running after the patch.

Handoff

Hand off to infrastructure-as-code, container-platforms, service-implementation, or cicd-automation per finding. Re-run after the patch and update the register.

References

• references/cve-workflow.md: feeds, query patterns, prioritization, and patch plan template.