feat: add uv audit in check vulnerability

[SMoraisAnsys]

This PR allows users additionally run uv audit in ansys/actions/check-vulnerabilities.

While uv audit is still experimental, it can surface both known vulnerabilities and project risk signals (like adverse project status/malware-related checks). The current implementation also assumes that one has a uv lockfile available to avoid resolving the dependencies before checking them. If not, the action will fail. The current parsing is simple because the feature is still experimental.

If required (e.g. false positive), vulnerabilities can be ignored. For example, I get an expected failure when testing this branch in here and using

[tool.uv.audit]
ignore = ["PYSEC-2026-2132"]

allows the uv audit command to pass locally without failing.

Close #1458

---

Note

Even if they safety and uv audit do not use the same DB (PyUp Safety vs OSV), we might think about replacing the former with the latter to answer #1342, see also #641 for more information on this safety replacement topic. However, projects without a lockfile would lose coverage entirely so this might be for laterrrrrr. Maybe we could rediscuss that when the audit feature is no longer considered experimental ? :)

[AlejandroFernandezLuces]

This is a great addition, thanks for taking care of it! I have a question about this. What do you think of integrating the uv audit as a pre-commit hook rather than in the vulnerability action? Or maybe even having it in both places?

From my pov, it looks doable and potentially keeps the vulnerability from reaching public code, since users should have pre-commit installed in local generally.

[SMoraisAnsys]

This is a great addition, thanks for taking care of it! I have a question about this. What do you think of integrating the uv audit as a pre-commit hook rather than in the vulnerability action? Or maybe even having it in both places?

From my pov, it looks doable and potentially keeps the vulnerability from reaching public code, since users should have pre-commit installed in local generally.

That's a very good remark, I just checked and feels like it would be doable astral-sh/uv-pre-commit#65. However, here are some remarks:

• uv audit is still experimental so I'd leave that pre-commit configuration up to each repo's maintainer. It would help with security for sure but that's a decision I would leave to maintainers (that's also why I made this input opt-in and not a default choice).
• adding a hook or even the uv audit check in CI won't prevent a vulnerability from reaching public code. It can help us to know that a vulnerability needs to be handled (just like dependabot security reports are doing) but this vulnerability is likely already here. The case I can think of, where this approach would work to prevent things to reach public code, is when one tries to add a dependency that leads to a new dependency version / malware.
• adding a hook would lead novice developers to face issues with the hook whenever a new (previously-resolved) malware is detected. While this will likely be handled by changing a package version or adding an ignore rule, I think that this should be be left to the maintainers to decide and not delegating this to any developer. Sometimes the vulnerability are not even impacting the package and putting an extra ignore rule would be the correct solution.

Tbh I think dependabot & safety are doing a great job atm and the main value of uv audit are:

• why malware scanning?
• faster feedback: immediate failure in CI when a CVE is present in the resolved lockfile (and not in the next dependabot schedule).
• Given that more and more of our repos are leveraging uv and its lock files, that would be beneficial for us.

=> I think we can let people know about the hook if this PR ever gets merged and we present it :)

[RobPasMue]

Thanks for considering my previous comment @SMoraisAnsys !
That might not be relevant but I thought of something else: In the PR description you write that running uv audit assumes that a uv lock file is available. I am not sure if the uv lock file is strictly needed to run the uv audit, but even if it's just the "recommended way", why do you prefer to assume this, rather than explicitly checking for its existence? In that case, if it appears to be missing a warning or an error could be raised and the "run uv audit checks" step could be skipped.

If you run uv audit without having a lock file, the file gets generated on the fly and then is analyzed. One of the benefit of uv audit is that it works with that file and doesn't require you to install anything. You can just analyze the lock file. If this logic needs to be updated, I would rather exit with an error when the lockfile is not detected.

This is an open question, any thoughts @ansys/pyansys-core ?

If you ask me... I would only run it if the repo already has a checked in "uv.lock" file. Anything else is problematic:

• If you generate the lockfile yourself, you might be running dependency versions which the project actually doesn't install (because they install a different target, they install a lockfile from a different location, etc.
• It's a bad practice if you have a uv-based project not to have a uv.lock file... same for poetry projects.

So.. I agree with @SMoraisAnsys - if it is not detected, I would throw out an error.

[SMoraisAnsys]

Changes are working as expected https://github.com/ansys/pyaedt/actions/runs/33410581239?pr=8024

[SMoraisAnsys]

@ansys/pyansys-core can I have some reviews ? :)

[moe-ad]

@SMoraisAnsys shouldn't we document this for local runs, similar to bandit and safety?

I think we should. If you agree, we just need to update generate_advisory_files with an initial run of uv audit ..., so that info_uv_audit.log will be generated. Otherwise, this line would cause failure locally. And of course update the documentation section above.

Other than the above comments, the rest LGTM and I am approving.

[SMoraisAnsys]

@RobPasMue @moe-ad @MaxJPRey changes performed to handle your comments, please have a look and resolve the discussion if the changes are fine with you :)

[moe-ad]

I left a comment regarding UV_MALWARE_CHECK env variable vs audit.malware-check in pyproject.toml. Those two are essentially the same thing based on my understanding. So if we are already forcing UV_MALWARE_CHECK=1, then we shouldn't need to have any logic relating to detecting the value of audit.malware-check, right?

Unless I am misunderstanding something, in which case the PR should be good to go.

[SMoraisAnsys]

Tested in https://github.com/ansys/pyaedt/actions/runs/33410581239/job/102422153154