research: evaluate uv.lock (Python) support - separate product or in-scope?

[sonukapoor]

Research whether uv.lock support belongs in CVE Lite CLI or warrants a separate product.

Background

uv is rapidly becoming the default Python package manager for modern Python projects. uv.lock is its lockfile format. A DINUM (French government) user running CVE Lite CLI across government digital service repositories requested Python lockfile scanning.

Questions to answer

• Does adding Python/uv.lock support fit the CVE Lite CLI product identity (currently JS/TS focused) or does it dilute it?
• Would a separate cve-lite-cli-python (or similar) be a better home?
• What would the OSV query surface look like for Python packages vs npm packages?
• Are there existing tools in the Python ecosystem this would compete with or complement (pip-audit, Safety)?
• What is the effort to parse uv.lock vs the JS/TS lockfile formats already supported?

Motivation

Requested by a DINUM (French government) user. No implementation commitment yet - this issue is to scope the decision first.

---

If you would like to see Python/uv.lock support, please give this issue a 👍 - it helps us prioritize.

[kaaloo]

Thanks for posting @sonukapoor . A unified CLI would be great as I'm frequently in the situation where we are dealing with polyglot Node / Python monorepos. Hope a polyglot CVE Lite CLI makes sense to others!

[pfarikrispy]

Just my 2 cents...

Much like checkov supports scanning for several frameworks, perhaps you can "wrap" the scanner type behind a switch:

• --scanner=python
• --scanner=ts

without a switch present, probe for the resp. lock files of each language.

[sonukapoor]

Thanks for the suggestion - a --scanner flag is a natural shape for multi-language support if we go that route.

This issue is currently in research/scoping mode: we're figuring out whether Python/uv.lock fits CVE Lite CLI's JS/TS identity or is better as a separate tool. If we do add Python support, a flag like --scanner=ts / --scanner=python (or auto-detect without a flag, as you suggest) would be worth prototyping. Appreciate the input.

[alex-powell]

Detect is an addon. --fix is a second product.

The useful split is detect vs --fix. Those are not the same amount of work.

Detect

Detect is: read a lockfile, get {name, version}, ask OSV if that version is known-bad.

The scanner already does this.

• PackageRef already has an ecosystem field
• OSV already understands PyPI the same way it understands npm
• Parsers already plug in through LockfileHandler in src/parsers/

A uv.lock / pylock.toml parser is another input file for the same machine. That is an addon. Same shape as adding bun.lock.

--fix is not that

Default cve-lite does not rewrite the tree. It prints copy-paste commands.

--fix only auto-applies direct deps that have a validated safe version, via npm install / pnpm add / yarn add, then rescans. Transitive findings stay “bump this parent yourself.”

That apply path is the expensive, JS-shaped part of the product.

Doing the same for Python means a new brain, not a new parser:

• versions are PEP 440, not npm semver
• you edit pyproject.toml + extras / groups / markers, not package.json
• the commands are uv add / uv lock / uv sync
• parent-aware upgrades do not map cleanly onto a universal uv.lock
• override hygiene, cooldown, and the npm registry bulk API all need Python equivalents

Wrong fix commands are worse than no fix commands. So Python --fix is a second product in the same binary. Detect-only is not.

Product identity

Keep the tool JS/TS-first.

• Auto-detect uv.lock / pylock.toml when present
• Label it experimental
• Do not advertise Python --fix
• A --scanner=python flag is fine as an override
• Do not use that flag as an excuse to rebuild remediations

A separate cve-lite-python package only makes sense if you commit to that second engine.

Do not scrape uv.lock as if it were stable

Astral treats uv.lock as uv-private and points other tools at uv workspace metadata (JSON).

PEP 751 pylock.toml is the public format, but it is a resolution output, not a full uv workspace graph.

Prefer metadata / pylock.toml. If you parse raw uv.lock, you own every format bump.

OSV

Same batch API, "ecosystem": "PyPI".

• IDs will be PYSEC-… / GHSA-…
• Offline mode needs the PyPI slice of OSV, not just npm
• “In the lockfile” is not “installed on this runner” because of environment markers

Say which marker set you used, or Linux CI will page on Windows-only wheels.

Other tools

This gap got smaller after the issue was opened:

• uv audit (June 2026) already does native OSV on a uv project
• osv-scanner already reads uv.lock and pylock.toml
• pip-audit is a good CI gate but does not read uv.lock (export first)
• Dependabot already alerts on uv.lock

So the remaining gap is not “can anyone see PyPI CVEs.”

It is one local CLI over a Node + Python monorepo with one JSON / SARIF / SBOM contract. That is the DINUM request. Full Python remediations are a different bet.

Suggestion

1. Keep it in this repo.
2. Ship detect-only.
3. Order:
   • pylock.toml and/or uv workspace metadata
   • OSV PyPI on the existing client
   • same outputs / --fail-on
   • raw uv.lock only if you must, and pin the revision you accept
4. --fix, parent upgrades, override rules: out of scope until detect-only is used for real.
5. Docs: uv-only repo → uv audit. CVE Lite → polyglot gate, same output schema.
6. Success for DINUM: CI fails on known PyPI vulns from the committed lockfile. If they later want validated uv add commands, that is the other product.

Happy to sketch a LockfileHandler + fixtures if this scoped approach is ok.

[sonukapoor]

This is the most useful thing anyone has put on this issue, so let me engage with it properly rather than just thanking you.

You are right about the plumbing, and I checked rather than took your word for it. PackageRef.ecosystem really is a free string, osv-advisory-source.ts:22 really does pass it straight through, and I confirmed live that a PyPI querybatch returns PYSEC and GHSA ids. LockfileHandler is a genuine compiler-checked table and a new entry touches about five places. The npm-registry supplemental pass is already correctly ecosystem-gated at scanner.ts:258.

The uv audit catch is the most valuable line in your comment and it changes the competitive picture more than the parser question does.

Where I think the argument breaks is "same shape as adding bun.lock". Bun is still the npm ecosystem, so every downstream assumption survives. PyPI breaks four of them, and the sharpest one lands in detect, not in --fix:

looksLikeVersion (utils/version.ts:1) requires a strict X.Y.Z, and findFirstFixedVersion (scanner.ts:1043) skips any fixed value that fails it. So:

numpy@1.21.0, GHSA-fpfv-jqm9-f5jm, declares fixed: "1.22". Two components. We would report "no fix available" for a vulnerability that numpy 1.22 fixes.

That is your own rule, wrong output is worse than no output, violated in the half you called cheap. It is not an edge case either: four of the thirty most-downloaded PyPI packages currently ship a version that check rejects (python-dateutil@2.9.0.post0, idna@3.20, packaging@26.3, pytz@2026.3.post1).

Three more, all verified against the code:

purl.ts:9 hardcodes pkg:npm/, and it feeds both SPDX and CycloneDX. Python packages would be emitted as pkg:npm/requests@2.19.1. On a project that talks about the Cyber Resilience Act, that is a wrong compliance artifact rather than a cosmetic bug.

pylock.toml, the input you recommend, is flat, and readDirectDependencyNames only reads package.json. So classifyRelationship falls back to path length, every finding comes out "unknown", and fix-commands.ts:237-245 routes every "unknown" finding into skipped. Detect-only via pylock.toml gives a findings list where every row has no command and a confusing reason.

And findRootLockfile picks exactly one lockfile per root, so a polyglot repo root scans one and lists the other as skipped. Your headline use case needs the two ecosystems in separate subfolders.

So the seam is not detect versus fix. It is "does this ecosystem's version algebra match semver." Detect here is four steps, not one: OSV query, version reasoning, relationship classification, output. Only the first is ecosystem-neutral today.

And the strategic question your comment does not ask. osv-scanner already reads uv.lock and pylock.toml and emits SARIF, so "one CLI over a polyglot repo with one SARIF contract" is already available. Our differentiator is remediation quality. Detect-only walks into the segment where we are weakest against an incumbent, and drops the axis where we win. What does it win us that we are not already losing?

Two things came out of reading this that are worth fixing regardless of whether Python ever happens, both latent on main today, and I have filed them: #1192 for the unparseable-fix-version case above, and #1191 for deriveAdvisoryPackageRows storing GIT-range commit hashes as versions, where compareVersions("2.32.4", "74ea7cf...") returns -1 so a patched version can be flagged vulnerable. Your comment found both. Thank you for that.

I am not taking the LockfileHandler sketch, and I want to be straight about why rather than leave it hanging: the handler is the easy five percent, and merging it would imply a scope decision this issue exists to make. If anything here is worth prototyping it is a PEP 440 version module behind the existing compareVersions and looksLikeVersion seam, which is the actual gate and is testable on its own without committing the project to a second ecosystem.

Leaving this open as research. You have moved it forward considerably.