`uv audit` Command for Security Vulnerability Scanning

[31z4]

Problem

Currently, there's no integrated way to audit dependencies defined in pyproject.toml and uv.lock against known security vulnerabilities in the Python Packaging Advisory Database. This creates security risks and workflow inefficiencies:

• Dependencies across different groups cannot be audited in a single operation
• Current solutions require additional tools and complex workflows
• Cross-platform compatibility issues with existing solutions
• Risk of auditing outdated or incorrect dependency sets

Proposed Solution

Implement a native uv audit command that would:

1. Read dependencies from both pyproject.toml and uv.lock
2. Check all locked dependencies (including all dependency groups) against the Python Packaging Advisory Database
3. Generate a security report highlighting:
   • Identified vulnerabilities
   • Affected versions
   • Available fixes

Example usage:

# Audit all dependencies
uv audit

# Audit specific dependency groups
uv audit --group dev,test

# Output in different formats
uv audit --format json

Benefits

• Improved Security: Integrated security scanning as part of the uv toolchain
• Better Performance: Native implementation could offer significant speed improvements (assuming that querying the Python Packaging Advisory Database isn't a bottleneck)
• Cross-Platform: Works consistently across all supported platforms
• Comprehensive Coverage:
  • Seamless support for dependency groups
  • Covers all project dependencies, not just installed packages
  • Ensures audit matches locked dependencies exactly
• Simplified Workflow:
  • No additional tools required
  • Single command for complete package security audit
  • Native integration with uv's dependency management

Alternatives Considered

1. Using pip-audit

• Current Status:
  • Limited pyproject.toml support (ref: Support for optional dependencies/extras when auditing from pyproject.toml pypa/pip-audit#766)
  • No uv.lock support
• Limitations:
  • Additional dependency requirement
  • Cross-platform inconsistencies
  • Incomplete dependency group coverage

2. Extending pip-audit for uv.lock support

• Pros:
  • Leverages existing tool
  • Community familiarity
• Cons:
  • Loses uv's performance benefits
  • Additional dependency requirement remains
  • More complex integration

3. Local environment scanning with pip-audit

• Approach: Running pip-audit -l against installed packages
• Issues:
  • Environment may not match declarations
  • Limited dependency group coverage
  • Platform-specific behavior

4. Requirements.txt generation and scanning with pip-audit

• Approach: Convert uv.lock to requirements.txt format for scanning
• Issues:
  • Additional synchronization overhead
  • Platform compatibility issues
  • Complex workflow

Additional Context

• Related Issue: Security check before installation discussion (✨[Feature Request]: Filter uv install by Python Package Authority's Security Advisory Database.✨ #8842)
• Implementation Interest: I'm willing to contribute to the implementation pending community feedback
• Similar Features:
  • cargo audit (Rust)
  • npm audit (Node.js)
  • composer audit (PHP)

Next Steps

1. Gather community feedback on the proposed approach
2. Discuss implementation details if approved
3. Define specific behavior for edge cases
4. Determine output format standards

---

💡 Please share your thoughts on this proposal, particularly regarding:

• Preferred output formats
• Specific use cases to consider

[woodruffw]

For prior art: take a look at pip-audit, which currently interoperates with pip and the other PyPA tooling.

Based on our experience with that tool, some scattered thoughts:

• Avoid security fatigue: all developers are susceptible to security fatigue, and auditing tools in particular eat into the "fatigue budget" more than most other tools. We try to minimize fatigue in pip-audit by making it an independent flow, i.e. not spitting out warnings or errors on every pip install, since we think users are more likely to just ignore security advisories if we force them in their faces.
• Be aware of quality issues: the PyPA advisory database is curated, but low-quality submissions and vulnerability spam/reputation-seeking chum can still make its way in. Having a system by which end users can ignore obviously bogus or irrelevant reports is a good day 1 feature to have 🙂
• Be aware of current fidelity gaps in Python advisory reporting: Python package advisories currently operate at the (name, version) scope, but many vulnerabilities are more specific than that: they either apply only to binary builds (wheels) of packages, or onto to specific API surfaces, etc. There's a long-term plan to increase the fidelity in reports (e.g. to expose which files within a release are vulnerable, or which API surfaces are vulnerable), but it's worth noting that the current level of fidelity will cause false positives.

[saada]

In the meantime, this seems to work fairly well

uvx pip-audit -r requirements.txt --fix

[strayer]

I had some issues with pip-audit trying to install pip (subprocess.CalledProcessError: Command '['/var/folders/n9/kcz03p6n2pb5xchxn1ywm4640000gn/T/tmp74_otz01/bin/python3.11', '-m', 'ensurepip', '--upgrade', '--default-pip']' died with <Signals.SIGABRT: 6>), so this is what I'm doing for now:

uv export --format requirements-txt > requirements.txt && uvx pip-audit -r requirements.txt --disable-pip && rm requirements.txt

Seems to work very well too.

[aplantinga]

See also the uv-secure project, which seems to have a similar aim of providing pip-audit functionality for uv

[colin-kerkhof]

I have been running uv run --all-groups --with pip-audit pip-audit -l. That should make sure that every package in the pyproject.toml is checked against the database, no?

[ycheng517]

I had some issues with pip-audit trying to install pip (subprocess.CalledProcessError: Command '['/var/folders/n9/kcz03p6n2pb5xchxn1ywm4640000gn/T/tmp74_otz01/bin/python3.11', '-m', 'ensurepip', '--upgrade', '--default-pip']' died with <Signals.SIGABRT: 6>), so this is what I'm doing for now:

uv export --format requirements-txt > requirements.txt && uvx pip-audit -r requirements.txt --disable-pip && rm requirements.txt

Seems to work very well too.

I get an error when I try this:

uv export --no-emit-project --format requirements-txt > requirements.txt && uvx pip-audit -r requirements.txt --disable-pip
Resolved 491 packages in 338ms
Traceback (most recent call last):
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/bin/pip-audit", line 12, in <module>
    sys.exit(audit())
             ~~~~~^^
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/pip_audit/_cli.py", line 538, in audit
    for spec, vulns in auditor.audit(source):
                       ~~~~~~~~~~~~~^^^^^^^^
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/pip_audit/_audit.py", line 68, in audit
    for dep, vulns in self._service.query_all(specs):
                      ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/pip_audit/_service/interface.py", line 155, in query_all
    for spec in specs:
                ^^^^^
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/pip_audit/_dependency_source/requirement.py", line 134, in collect
    yield from self._collect_from_files(collect_files)
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/pip_audit/_dependency_source/requirement.py", line 167, in _collect_from_files
    yield from self._collect_preresolved_deps(iter(reqs), require_hashes)
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/pip_audit/_dependency_source/requirement.py", line 319, in _collect_preresolved_deps
    if req.marker is not None and not req.marker.evaluate():
                                      ~~~~~~~~~~~~~~~~~~~^^
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/packaging/markers.py", line 319, in evaluate
    return _evaluate_markers(
        self._markers, _repair_python_full_version(current_environment)
    )
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/packaging/markers.py", line 225, in _evaluate_markers
    groups[-1].append(_eval_op(lhs_value, op, rhs_value))
                      ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/packaging/markers.py", line 183, in _eval_op
    return spec.contains(lhs, prereleases=True)
           ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/packaging/specifiers.py", line 552, in contains
    normalized_item = _coerce_version(item)
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/packaging/specifiers.py", line 28, in _coerce_version
    version = Version(version)
  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/packaging/version.py", line 202, in __init__
    raise InvalidVersion(f"Invalid version: {version!r}")
packaging.version.InvalidVersion: Invalid version: '6.11.0-21-generic'

It looks to be caused by the presence of markers in requirements such as platform_release >= '20.0' and sys_platform == 'darwin'

[woodruffw]

It looks to be caused by the presence of markers in requirements such as platform_release >= '20.0' and sys_platform == 'darwin'

That's not why -- the error message shows that the error is caused by an invalid package version:

  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/packaging/version.py", line 202, in __init__
    raise InvalidVersion(f"Invalid version: {version!r}")
packaging.version.InvalidVersion: Invalid version: '6.11.0-21-generic'

You can reproduce this directly as well:

uv run --with packaging python
>>> import packaging.version
>>> packaging.version.Version("6.11.0-21-generic")
packaging.version.InvalidVersion: Invalid version: '6.11.0-21-generic'

If you could report that upstream to pip-audit with a reproduction case, I'd appreciate it -- pip-audit should be catching and skipping these kinds of invalid package versions, but it's always possible there are edge cases we missed.

You can report it here: https://github.com/pypa/pip-audit/issues/new?template=bug-report.yml

[ycheng517]

That's not why -- the error message shows that the error is caused by an invalid package version:

  File "/home/yifei/.cache/uv/archive-v0/ebnZSnxmb7JKYb1q41oSp/lib/python3.13/site-packages/packaging/version.py", line 202, in __init__
    raise InvalidVersion(f"Invalid version: {version!r}")
packaging.version.InvalidVersion: Invalid version: '6.11.0-21-generic'

'6.11.0-21-generic' is my Linux kernel version, this version doesn't exist at all in my requirements.txt file. I believe because of the platform_version marker, pip-audit tries to get the version of the OS kernel to compare, and fail to recognize it as a valid version. Your point about this being a pip-audit issue still stands though, I shall report there. On the UV side, if there's an option to not generate the markers, that will help as well.

[woodruffw]

Oh huh, that's interesting! Yeah, please file an issue, thanks -- that might even be a lower-level issue than pip-audit itself (since assuming that platform_version evaluates to something like a PEP 440 version seems wrong within packaging).

Edit: Yep, here it is: pypa/packaging#774

[ycheng517]

Ah, thanks for finding that issue!

[Avasam]

I personally would like to get vulnerability warnings whenever I install (sync, add, uv pip) à la npm. But I'm fine if its opt in rather than opt out.

[owenlamont]

I should've searched for this issue earlier - I am the author of uv-secure - but I'd love for my package to become obsolete if uv did add an audit sub-command or perform automatic vulnerability scanning when syncing or locking.

In my case uv-secure hits the PyPi json API to request known vulnerabilities per package version and requesting that info in parallel / asynchronously can still take a while - I'm sure the uv devs could do that smarter and more efficiently but you may not want that option always enabled by default. Maybe a uv audit command would be the way to go.

In the short-term if I can find ways to incorporate more of uv into uv-secure (uv-secure is currently pure Python and not as fast as I'd like) I'd be interested to learn ways I could do that.