Roadmap: uv audit

This is a roadmap/tracking issue for uv audit, including both MVP and post-MVP tracks.

For previous context, see #9189 and #18119.

MVP tasks

Post-MVP tasks

Unhide `uv audit` (#18540)

Add `--service-format` and `--service-url` to `uv audit` (#18571)

Will there be an option to ignore specific vulnerabilities, like the --ignore-vuln option of pip-audit?

Will there be an option to ignore specific vulnerabilities, like the --ignore-vuln option of pip-audit?

Yeah, I'll add a roadmap item for that.

pysentry has a nice option you should consider: --ignore-while-no-fix which lets you ignore a specific vulnerability until there is a fix available, at which point it will start flagging it as an issue again.

Evaluate extras and groups when determining auditable packages (#18511)

I would love to incorporate uv audit into my CI pipelines but there two features that I think would make this a drop-in solution:

The previously mentioned --ignore-while-no-fix flag
Setting a failing exit code when there are detected vulnerabilities. This could be an optional flag, something like --fail-on-detection

These two would make it an easy addition to any CI pipeline.

I found uv audit this week - really happy it's being added to uv. The reason I went looking was the well publicised supply chain attacks. What I'm trying to do is ensure a) none of our internal repos are using vulnerable / malicious packages (which uv audit directly targets) but secondly I'm trying to ensure that malicious packages are not added by a user or agent via uv add (correct me if I'm wrong but uv audit doesn't directly target this vector - uv add updates the lock file and installs the package by default - at which point it's too late if the package installer contains a Trojan, and finally I'm trying to prevent agents installing malicious packages directly into an venv on-the-fly (ie using uv pip install)

Would be great if uv could address these cases. What I've done so far is use uv audit with pre-commit, and add Claude code Bash hooks that (using regex) prevent uv add (only allow uv add --no-sync, then auto run uv audit). Still not sure what to do about agents that run uv pip install

Given that I'm not a security expert it would be great if the tooling had option to harden against these attacks - esp given "agentic workflows" where agents might be the uv user.

Ah, I forgot --offline is a global flag. It's not really disable-able here given that, but maybe I can produce a more useful warning or error message. I'll see.

#22114 will address this.

@woodruffw

@woodruffw would an option to not audit specific packages be considered for the MVP ?

I currently work for an administration: for security purposes, we don't want internal package names to be leaked to the outside world.
But money is tight so using pip-audit/uv audit is all we can afford in early CI steps.

For our purpose, we can sort the packages by which index is used, or maybe by name/name prefix.

I played with a custom dependency group ('internal'), but we then have to do light shenanigans to build a wheel with the correct dependencies.
It works, but i would prefer waiting for this feature over switching n data teams to a "complex" process some would struggle to understand.

If this is not the correct track i can create a specific issue on the subject, and of course thank you the incredible work on uv.

@aureliesalmon

Hi @aureliesalmon, thanks for the kind words. Making sure I understand: are you envisioning some kind of per-project ignore for audit lookups (where we'd exclude the package name from being sent to OSV at all), or something more general like only auditing packages that are locked with pypi.org as their origin?

(The latter is close to what we do for uv's malware checks, but it might not work as well in an auditing context since it would make uv audit less useful to people who are mirroring PyPI on their own internal registry.)

@woodruff

Hello @woodruff, my apologies for the delay. I was envisioning the latter: do not inspect packages with this index as origin.
And yes, it would need to be careful, we are part of the people who are mirroring PyPI on their own internal registry.

For instance:

[[tool.uv.index]]
name = "my_librairies_index"
url = "https://nexus.mycompany.org/repository/my_internal_releases/simple"

[[tool.uv.index]]
name = "internal_pypi_mirror"
url = "https://nexus.mycompany.org/repository/pypi/simple"
default = true

[tool.uv.audit]
malware-check = true
ignore-index = ["my_librairies_index"]

But i acknowledge that the implementation is harder, and maybe doesn't cover all edge cases. We do not have a lot of internal dependencies, so an ignore by package name/regex would also work for us :

[tool.uv.audit]
malware-check = true
ignore-packages= ["internal1", "internal2", "mycompany-.*"]

I'll need to think about it a bit, but I think we could probably support excluding entire indices. But does that mean you're using both PyPI and an internal index, rather than mirroring PyPI onto your internal index?

Yes in my current organization the policy is to use:

one index for external assets (PyPi mirror for Python)
n internal assets indices (one for each Python project, with authentication and privileges checked).

It is inherited from a long Java/Maven/Nexus tradition, and applied to the Python ecosystem without much thought.

feat(github-issues): linked issues expand, collapse, and show type an…

Navigation Menu

Repository navigation

Roadmap: `uv audit` #18506

MVP tasks

Post-MVP tasks

64 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Roadmap: uv audit #18506

Description

MVP tasks

Post-MVP tasks

Activity

fniessink commented on Mar 25, 2026

andrew-monroe commented on Mar 25, 2026

woodruffw commented on Mar 25, 2026

mattjreynolds commented on Mar 25, 2026

MatthewCane commented on Mar 27, 2026

woodruffw commented on Mar 27, 2026

MatthewCane commented on Mar 27, 2026

adamchainz commented on Mar 28, 2026

david-waterworth commented on Mar 29, 2026

64 remaining items

woodruffw commented on Sep 30, 2026

aureliesalmon commented on Oct 16, 2026

woodruffw commented on Oct 16, 2026

aureliesalmon commented on Oct 19, 2026

woodruffw commented on Oct 19, 2026

aureliesalmon commented on Oct 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Roadmap: `uv audit` #18506