uv audit

[AdrianSosic]

Replace pip-audit with uv audit, which is faster and saves us one dependency.

[Copilot]

Pull request overview

This PR migrates the project’s dependency vulnerability scanning from pip-audit to uv audit, aligning the audit step with the repository’s existing uv/tox-uv tooling and reducing dev dependency surface area.

Changes:

• Removed pip-audit from dev dependencies and the lockfile, dropping its transitive dependency set.
• Updated tox audit environments to run uv audit instead of pip-audit.
• Updated CI workflows and contributor documentation to refer to uv audit.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
uv.lock	Removes pip-audit and its transitive dependencies; updates uv to 0.11.2 in the locked set.
tox.ini	Switches audit testenv commands from pip-audit to uv audit.
pyproject.toml	Removes pip-audit from dev extra; bumps uv minimum version to >=0.11.2; updates audit-related comment.
CONTRIBUTING.md	Replaces pip-audit reference with uv audit and links to uv docs.
.github/workflows/regular.yml	Renames the audit step label to “Run uv audit” (tox env remains the driver).
.github/workflows/ci.yml	Renames the audit step label to “Run uv audit” (tox env remains the driver).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[AVHopp]

Looking good, but want to understand what the full intent of this PR is.

[AVHopp]

@AdrianSosic @Scienfitz does a tool replacement deserve a CHANGELOG entry? Imo it would

[AdrianSosic]

@Scienfitz: I've had a quick look but it seems there is no straightforward way to implement your idea of auditing only primary dependencies. However, the uv audit functionality is quite new and it might exist in the future – we could even open an issue for it, what do you think?

In any case, it means there is no immediate solution for the problem at hand. So how do we want to handle secondary deps vulnerabilties for now? Manually excludes?

[Scienfitz]

i was thinking of it a separate bash logic int he aciton not as configuraiton of uv, would be surprised if thats not possible, did you try? just need to grep the error lines and compare them with dependency anmes in toml and ignore if not there

[AdrianSosic]

Sure, we (or claude) could hack something together, but I'm not sure if this is gonna be very robust, given that the entire audit functionality and probably also its output format isn't stable. So I'm not sure if it's really worth the (maintenance) effort or if we should rather go the official route? Regardless of the decision, let me open an issue 👍🏼

[AdrianSosic]

what I can see is that they at least have this on their agenda, which would facilitate to implement your approach:

[Scienfitz]

if you assess that the tool is evolving too quickly then let snot hack something

but what do we do in the meantime with the amount of errors?

[AdrianSosic]

Ok, I've now opened the issue + tried the custom script. As soon as either the feature gets implemented on uv side or their JSON output work item is completed, we can adjust once again. But for now, it seems to do the job – let's hope it's somewhat stable 🤞🏼 Let me know if I can resolve

[Scienfitz]

hmmmm I would have prefered if this only affects the action and not the entire tox command, ie its a seconds step after the uv-audit that does the additional check in bash, any reason it was added as separate python tool?

[AVHopp]

I thought a bit about this as well and also have to say that I am not entirely happy with a hacked script that is hard to understand and highly depends on the output format (e.g. the regex) of a tool rapidly evolving. I however also see the advantages of the test only failing for primary dependencies. I think I would prefer to have this as a two step approach: First just replace pip-audit by uv audit and then think about the best way to only fail on primary dependencies - in particular since Adrian already started the discussion on uv side, this might be redundant very soon, so I would at least wait for whatever comes out of that discussion, but this should not block this PR whose original goal was to replace the tool - NOT to change what we are auditing.