Vulnerability gate check in PRs

[bartpleiter]

As OpenSTEF maintainer
I want to make sure we do not merge a PR when it introduces vulnerabilities
So that I can keep OpenSTEF secure

🌍 Background

Important

Changes should be done by forking main branch (main) and then make a PR back onto main branch.
Please read the contributing guide before you start.

❗Priority (What if we don't do this?/Are there any deadlines? etc.)

Definition of Done:

✅ Acceptance criteria

• Looked into a way to add a vulnerability gate in CI that would not allow new dependencies if they are vulnerable
• Investigated if this can be solved using sonar

📄 Documentation criteria:

Interfaces with other products and services

Update relevant confluence pages

🧪 Test criteria:

Unit tests written and passed

⌛ Dependencies:

N/A

🚀 Releasing:

N/A

Other information:

[Valyrian-Code]

I looked into both acceptance criteria.

AC2: SonarCloud can't handle this. It catches issues in our own code, but not vulnerable versions of third-party dependencies. We'd need a separate dependency scanning step for that.

AC1: I compared a few options for our uv workspace:

• pip-audit looks like the best fit. It uses OSV, doesn't need any secrets, works on fork PRs, and I verified it fails on a known vulnerable dependency.
• dependency-review-action won't work since GitHub's dependency graph doesn't understand uv.lock.
• safety needs an API key, so it has the same fork PR limitation as Sonar.
• uv audit would be the nicest long-term solution, but it's still in preview.

My thought is to add a SHA-pinned pip-audit step to the existing quality-check job using uv export, so it becomes part of the required CI checks.

Before I open a PR, I had a couple of questions:

1. Should we scan just runtime deps, or also the shipped extras/dev groups?
2. Should the gate check the whole lockfile, or only newly introduced dependencies?
3. Should any advisory fail the build, or only above a certain severity?
4. Are you okay with an allowlist for unfixable advisories?

I can also update SECURITY.md to document the new gate.