amdravidranjan / cve-patch-sweep

Sweeping a codebase for recent severe CVEs

npm audit and friends only see libraries. Many of the worst recent CVEs hit
the runtime (PHP, Java, Go, Node, Python, OpenSSL, nginx) or **certificate
trust**, which those tools never check. This skill checks all three layers
against what was published recently, fixes with the smallest safe change, and
proves the fix.

**Your memory of CVEs is out of date. Never use it for affected or fixed
versions.** Every version number must come from data fetched in this session,
with its source.

Step 1: Inventory the three layers

python scripts/sweep.py inventory <repo>

It lists:

• Dependencies locked in npm, PyPI, Packagist, Go, crates.io and RubyGems lockfiles

• Runtimes and images: Dockerfile FROM tags, composer.json PHP,
  go.mod go/toolchain, .nvmrc, .python-version, .tool-versions,
  .java-version, GitHub Actions setup-* versions

• Trust material: committed certificates and keystores, and code that
  disables TLS verification

Write down what the repo can't show: production hosts, managed hosting, OS
packages. These go under "Check outside the repo" in the report.

Step 2: Fetch recent severe CVEs and match them

python scripts/sweep.py recent <repo> --days 30 --min-severity high

--days sets the lookback window (default 30, NVD maximum 120).
--min-severity is critical or high (default high).

It matches the inventory against three sources:

1. CISA KEV (Known Exploited Vulnerabilities): entries added in the
   window whose vendor or product matches something in the repo. These are
   exploited in the wild, so they go first.

2. NVD: critical/high CVEs published in the window for each runtime it found,
   matched by product and exact version.

3. OSV.dev: every locked dependency version, filtered to high or critical.
   Ones published in the window are marked NEW.

Treat the output as candidates. Before reporting each one, open its
advisory link and confirm the affected range, the fixed version, and the
condition needed to exploit it (for example "PHP serving web requests").

If the user named a specific CVE or nickname, also run
python scripts/sweep.py cve <CVE-ID> <repo>. Find a nickname's CVE IDs first.
If a CVE has no record or no fixed version, ask for the vendor advisory link.
Don't guess.

Verdicts

• AFFECTED: the version is in range, and the condition plausibly holds.
• NOT AFFECTED: the version is outside the range, or the feature isn't used. Show the evidence.

• CHECK DISTRO: a distro package (Debian, Ubuntu, RHEL, Alpine) may carry
  a backported fix its version string doesn't show. Name the distro advisory to read.

• CHECK OUTSIDE: you need a host or a setting not in the repo. Give the
  exact command (php -v, java -version, openssl version).

Floating tags (php:8.3, node:lts, latest) mean the repo can't prove what
version runs. Report that and pin it in the fix.

Step 3: Plan, then fix

Show a plan table before editing: item, CVE, current, target, file, command.
Order: KEV first, then network-reachable critical, then high.

Use the smallest change that reaches a fixed version:

• Dependency: the lowest fixed version on the same major, through the package manager:
  npm install pkg@x.y.z · composer update vendor/pkg --with-dependencies ·
  pip install "pkg==x.y.z" then regenerate the project's pinned file ·
  go get mod@vX.Y.Z && go mod tidy · cargo update -p pkg --precise x.y.z ·
  bundle update pkg.
  For a transitive package, upgrade the parent that pulls it in. If no
  parent release fixes it, use an override (npm overrides, yarn
  resolutions, a direct composer or pip constraint) with a comment naming the CVE.

• Runtime or image: bump to the patched release on the same branch in
  every place it appears: Dockerfiles, CI, version files, composer.json
config.platform. Pin exact patch tags.

• Certificate trust: update the runtime or ca-certificates that carries
  the fixed trust store, and remove the distrusted CA from committed bundles
  or keystores. If one of your own services uses a certificate from that CA,
  get a replacement from a different CA.

• No fix released: apply the advisory's documented mitigation, mark it
  OPEN, and say what release to watch for.

Ask before: a major-version upgrade, removing a dependency, or any change
that alters behaviour beyond the fix.

Step 4: Verify

1. Re-run sweep.py recent with the same arguments. Fixed items must be gone.

2. Run the project's build and tests. Report failures honestly, and never
   delete or skip tests to get a pass.

3. Show the diff.

Step 5: Report

# CVE sweep: <repo>, last <N> days, severity ≥ <level>

**Sources fetched:** CISA KEV (<catalog date>), NVD, OSV.dev. **Run at:** <date>
**Result:** <n> fixed · <n> open · <n> not affected · <n> check outside the repo

| CVE | KEV | Layer | Item | Was | Now | Verdict | Advisory |

## Still open
- <CVE / item>: <mitigation applied, what release to watch for>

## Check outside the repo
- <host>: run `<command>`. Patched if <condition>.

## Verification
- sweep re-run: <result> · build/tests: <summary>

Mistakes to avoid

• Never "fix" TLS errors by turning verification off (verify=False,
  InsecureSkipVerify, rejectUnauthorized: false,
  NODE_TLS_REJECT_UNAUTHORIZED=0, CURLOPT_SSL_VERIFYPEER => false). Report
  any already in the code as findings.

• Never edit a lockfile by hand. Use the package manager.

• Don't downgrade into an older vulnerable version, and don't jump a major
  version without asking.

• Patched is not the same as safe. If the advisory or a credible follow-up
  names a remaining attack path, report it OPEN with its mitigation.

• Don't write or run exploit code. Prove the fix with versions, the
  sweep re-run and the tests.

• Don't dump every CVE ever filed against a package. Report only those
  whose ranges include the version in the repo.

• NVD lags in tagging new CVEs with products. A KEV or vendor advisory
  newer than the NVD data wins. Say when NVD had no product data yet.

• If OSV, NVD or CISA was unreachable, say which, and don't fill the gap from
  memory.

references/examples.md has two worked examples from October 2026: a runtime
RCE (PHP2Shell) and a certificate-authority compromise (eMudhra).