ci: add osv-scanner lockfile scan workflow

[yuneng-berri]

Relevant issues

None

Linear ticket

None

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests (the workflow itself was runtime-verified twice on this branch; detection behavior is proven by the failing runs linked below)
• My PR passes all unit tests on make test-unit (no Python code touched)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Screenshots / Proof of Fix

The workflow was runtime-verified on this branch via a temporary push trigger (removed in the final commit). Run on the actual ubuntu runner: https://github.com/BerriAI/litellm/actions/runs/27367621871

The run shows the full chain working: binary fetched by pinned URL and verified against its SHA-256 (/home/runner/work/_temp/osv-scanner: OK), the documented diskcache suppression applied with its reason logged, and the scan correctly failing with exit code 1 on the four advisories that exist on this branch's lockfiles:

GHSA-w8v5-vhqr-4h9v and 1 alias have been filtered out because: diskcache has no fixed release published; remove this entry once one exists
Total 3 packages affected by 4 known vulnerabilities (1 Critical, 0 High, 3 Medium, 0 Low, 0 Unknown) from 2 ecosystems.
| https://osv.dev/GHSA-hg6j-4rv6-33pg | 6.6 | PyPI | aiohttp               | 3.13.5 | 3.14.0 | uv.lock                                |
| https://osv.dev/GHSA-jg22-mg44-37j8 | 6.4 | PyPI | aiohttp               | 3.13.5 | 3.14.0 | uv.lock                                |
| https://osv.dev/GHSA-jxxr-4gwj-5jf2 | 6.5 | npm  | brace-expansion (dev) | 5.0.5  | 5.0.6  | ui/litellm-dashboard/package-lock.json |
| https://osv.dev/GHSA-5xrq-8626-4rwp | 9.8 | npm  | vitest (dev)          | 3.2.4  | 3.2.6  | ui/litellm-dashboard/package-lock.json |
##[error]Process completed with exit code 1.

That red is expected and is the point: this PR's own osv-scan check will stay red until #30220 (which bumps those packages) merges and this branch is refreshed. The green path was verified locally against the bumped lockfiles: same command exits 0 with "No issues found".

zizmor 1.16.3 in pedantic mode reports no findings on the workflow:

$ uvx zizmor==1.16.3 --persona=pedantic .github/workflows/osv-scan.yml
No findings to report. Good job!

Type

🚄 Infrastructure

Changes

Adds .github/workflows/osv-scan.yml, a CI guard that fails when a published advisory exists for anything in uv.lock or ui/litellm-dashboard/package-lock.json (direct and transitive, both ecosystems). Today this coverage only exists as repo Security-tab alerts that require someone to remember to look; this makes it a failing check instead.

Triggers: a daily cron (which runs on the default branch and catches advisories published for dependencies we already ship) and a pull_request run scoped with a paths: filter to the two lockfiles, the suppression file, and the workflow itself (so a PR introducing a flagged dependency goes red, while an advisory dropping overnight does not paint unrelated PRs red; the cron catches that case and notifies).

Supply-chain posture, per the repo CI rules: the osv-scanner v2.3.8 binary is fetched by full version-pinned URL and verified against its SHA-256 (taken from the release's official osv-scanner_SHA256SUMS sidecar and independently re-derived by downloading and hashing the asset) before being made executable; a checksum mismatch fails the job before anything runs. actions/checkout is SHA-pinned to the same commit used by the sibling workflows, with persist-credentials: false. The workflow references no secrets and needs none (osv-scanner queries the public osv.dev API anonymously; the only data sent is package name+version tuples from lockfiles that are already public). Top-level permissions: {} with a job-scoped contents: read, matching the zizmor.yml pattern. The binary lives in $RUNNER_TEMP rather than /tmp.

osv-scanner.toml also carries two time-boxed suppressions for the aiohttp advisories: vcrpy releases up to 8.1.1 cannot import aiohttp 3.14 (the upstream fix is merged but unreleased), so aiohttp stays at 3.13.5 for now; the entries expire 2026-08-15 and force a dated re-triage. Besides those, it carries the single suppression for the diskcache advisory, which has no fixed release. The entry has ignoreUntil = 2026-09-09: if diskcache still has no fix by then, the cron goes red and forces a dated re-triage instead of the suppression silently outliving an upstream fix. Editing this file re-triggers the scan on the PR (it is in the paths: filter), so suppression changes are always visible in diff review

Notes for reviewers

The scan deliberately fails closed: scanner errors (osv.dev outage, deleted release asset) and real findings both fail the job, and the log output distinguishes them. Scheduled-run failure notifications go to the last committer of the workflow file per GitHub semantics

[yuneng-berri]

@greptileai

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[greptile-apps]

Greptile Summary

Adds a new osv-scan CI workflow and an osv-scanner.toml suppression config to enforce dependency vulnerability scanning as a failing check on PRs and via a daily cron.

• The workflow downloads the osv-scanner v2.3.8 binary from a pinned GitHub release URL, verifies it against a hardcoded SHA-256 before execution, and scans uv.lock and ui/litellm-dashboard/package-lock.json using scan source -L. The actions/checkout SHA (08eba0b) matches the v4.3.0 pin used across the rest of the repo's workflows. Permissions are minimised to contents: read at the job level with permissions: {} at the workflow level, consistent with the zizmor.yml pattern.
• The pull_request trigger uses a paths: filter (lockfiles, suppression file, and the workflow itself) so unrelated PRs aren't painted red by an overnight advisory; the daily schedule cron covers that case by running against the default branch.
• osv-scanner.toml carries a single time-bounded suppression (ignoreUntil = 2026-09-09) for a diskcache advisory that has no upstream fix yet, ensuring the suppression is forced back into triage before it goes stale.

Confidence Score: 5/5

Safe to merge — pure CI infrastructure addition, no production code touched.

The workflow is a self-contained CI guard with no changes to any Python or application code. The checkout action SHA is consistent with every other workflow in the repository. The osv-scanner binary is fetched by full version-pinned URL and verified against a 64-char SHA-256 before execution. Permissions are minimal (contents: read job-scoped, empty top-level), credentials are not persisted, and the binary lives in $RUNNER_TEMP. The single suppression entry carries an explicit expiry date that forces re-triage.

No files require special attention.

Important Files Changed

Filename	Overview
.github/workflows/osv-scan.yml	New CI workflow: downloads osv-scanner v2.3.8 via SHA-256-verified URL, scans uv.lock and package-lock.json on PR (paths-filtered) and daily cron. Checkout SHA matches the repo-wide v4.3.0 pin; minimal permissions; binary stored in $RUNNER_TEMP.
osv-scanner.toml	Suppression config for GHSA-w8v5-vhqr-4h9v (diskcache, no fixed release); includes an ignoreUntil = 2026-09-09 expiry to force re-triage if the upstream fix is delayed.

_{Reviews (1): Last reviewed commit: "Merge remote-tracking branch 'origin/lit..." | Re-trigger Greptile}

[greptile-apps]

Greptile Summary

This PR introduces a new GitHub Actions workflow (.github/workflows/osv-scan.yml) that downloads and SHA-256-verifies the osv-scanner v2.3.8 binary, then scans uv.lock and ui/litellm-dashboard/package-lock.json for known CVEs. It also adds osv-scanner.toml with a single time-bounded suppression for a diskcache advisory that has no upstream fix yet.

• The workflow is triggered on PRs (via a paths: filter scoped to the lockfiles, the config, and the workflow file itself) and a daily cron, providing both change-time and overnight coverage.
• Security posture is solid: SHA-256 pinned binary, actions/checkout SHA-pinned, persist-credentials: false, permissions: {} at the top level with a job-scoped contents: read, and binary stored in $RUNNER_TEMP.
• One coverage gap: the root package-lock.json (containing prisma, prism-react-renderer, and others) is not included in the scan command or the paths: filter.

Confidence Score: 4/5

Safe to merge — this is a new, additive CI workflow with no changes to application code.

The workflow is well-constructed with appropriate supply-chain hygiene throughout. The only notable gap is that the root package-lock.json is not included in the scan.

.github/workflows/osv-scan.yml — the scan command and paths filter should be reviewed to decide whether the root package-lock.json belongs in scope.

Important Files Changed

Filename	Overview
.github/workflows/osv-scan.yml	New workflow adding OSV vulnerability scanning; well-structured with SHA-256 pin, minimal permissions, and proper concurrency handling. Root package-lock.json coverage gap noted.
osv-scanner.toml	Single suppression entry for GHSA-w8v5-vhqr-4h9v (diskcache) with an expiry date of 2026-09-09 and a documented reason; format is correct.

_{Reviews (2): Last reviewed commit: "Merge remote-tracking branch 'origin/lit..." | Re-trigger Greptile}

[greptile-apps]

Root package-lock.json not included in the scan

The repo has a root-level package-lock.json (project name litellm-dependency-refresh) that lists production dependencies including prisma 5.17.0 and prism-react-renderer 2.4.1. It is not passed to -L here, and the paths: filter above also does not watch it, so a PR touching that lockfile would not trigger this scan and the daily cron would also miss its dependencies. If vulnerabilities exist in those packages they would go undetected. Consider adding -L package-lock.json to the scan command and package-lock.json to the paths: filter if this lockfile is within scope.