ci(security): workflow skanowania CVE w uv.lock + bump jaraco.context

[mpasternak]

Podsumowanie

PR 8/12 z serii pypi-security-best-practices — praktyka #6: Scan for Known Vulnerabilities.

Co się zmienia

1. Nowy workflow .github/workflows/dependency-audit.yml

uv-secure skanuje uv.lock (natively reads hashe SHA-256) na:

Trigger	Kiedy
push do dev/master	gdy zmienia się uv.lock/pyproject.toml
pull_request	każdy PR dotykający lockfile
schedule	weekly cron, poniedziałek 6:00 UTC
workflow_dispatch	manualny z UI

Policy:

• HIGH/CRITICAL z dostępnym fix-em → failure. PR podbijający dep
  to jedyne wyjście.
• LOW/MEDIUM → raport w GitHub Step Summary, nie blokuje.
• --ignore-unfixed → CVE bez fix-a pomijane.

2. Bump jaraco.context 6.0.1 → 6.1.2

Workflow wykrył transitive vuln GHSA-58pv-8j8x-9vj2 (ReDoS) podczas
testowania lokalnie. Bez fixa workflow failowal by od razu na pierwszym
runie. Bump zrobiony przez:

uv lock --upgrade-package "jaraco.context"

Dlaczego uv-secure a nie pip-audit

uv-secure czyta uv.lock natively (z hashami SHA-256), pip-audit
potrzebuje konwersji do requirements.txt. uv-secure to mniej kroków,
mniej miejsc gdzie coś może rozjechać. Możemy dodać pip-audit jako
second opinion w follow-up.

Plan testowy

• Lokalne uv-secure --severity high --ignore-unfixed uv.lock → exit 0
  po bumpie jaraco.context.
• actionlint passed.
• persist-credentials: false na checkout.
• Permissions: contents: read only.
• Po mergeu sprawdzić że workflow uruchamia się na PR dotykających
  uv.lock.
• Weekly cron run w przyszły poniedziałek.

Future work

• Dodać pip-audit jako second opinion w osobnym jobie.
• Dodać Slack/email notification dla weekly cron failures.

🤖 Generated with Claude Code