Security & Trust

How we secure LiteLLM

LiteLLM sits in the path of your model traffic and holds your provider keys. You can check how we build releases and verify each image before you deploy it.

Oct 21, 2026 The attack chain behind the v1.107.0 LiteLLM release →

258

security fixes shipped in May, July, August and September 2026

4

minor release lines receive every security backport

3 days

a new package version must be public before our builds will install it

5

security scanners in CI: zizmor, semgrep, CodeQL, OSV-Scanner and Grype

01 / Release pipeline

Our release process

We build releases in a private repository from a commit that already passed qualification, and we rebuild nothing at publish time.

  1. STEP 1

    Cut a release-candidate branch and tag

    This happens on Friday at 3AM, and the branch and tag do not change.

  2. STEP 2

    Qualify the release candidate

    We run the code through our integration tests, both publicly through CircleCI and privately through Buildkite, and check that everything is correct.

  3. STEP 3

    Create artifacts

    This step is a GitHub workflow that runs in a private repo, and creates artifacts based on the SHA that has been qualified. This must be done by an engineer with write permissions to the private release repo.

  4. STEP 4

    Deploy artifacts to testing environment

    We run a second round of testing against the produced artifacts.

  5. STEP 5

    Publish the artifacts

    This is a GitHub workflow that uses Trusted GitHub Publishers to publish the artifacts made in the previous step. Publishing can only be performed by an account locked to a specific laptop physically located within our office at all times. No docker image is rebuilt at publish time.

02 / Verify

Verifiable, tamper-proof Docker signatures

Image security guide →
terminal cosign verify 
cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/e82a3c646908ba0a6ee0beddc4310d7a6cac4065/cosign.pub \
  ghcr.io/berriai/litellm:[release-tag]

The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key

Signing key

We rotated the image signing key on Oct 23, 2026. Verify new releases against the key at commit e82a3c6, not the old one.

Pin by digest

Versioned tags can't be overwritten. Rolling tags like latest and main-stable can, so pin a version or digest in production.

03 / CI/CD v2

Isolated dependencies in CI

Read the CI/CD v2 announcement →

In March 2026, an attacker used a compromised security scanner in our shared CI environment to read a long-lived PyPI token. We shipped CI/CD v2 on March 30, 2026, starting with v1.83.0. Tests and scans now run in environments that hold no release credentials.

Security scans
isolated env
Unit tests
isolated env
BerriAI/litellm
Public repo. No release credentials.
PRIVATE REPO
BerriAI/project-releaser
HOLDS LLM API KEYS ONLY
CircleCI
PyPI and GHCR release
Trusted Publishing, cosign-signed
E2E tests
against real model providers
manually triggered release
runs on main and litellm_ PRs
The four principles

Limit what each step can access

Scans and unit tests run in isolated environments with no access to release credentials.

Reduce sensitive environment variables

PyPI releases use Trusted Publishing, so no long-lived publishing token exists to steal.

Avoid compromised packages

We pin Actions to commit SHAs, and zizmor checks each workflow change.

Prevent release tampering

We build releases in a separate private repo and sign each image with cosign. Versioned image tags can't be overwritten.

04 / Supply chain

Scanners on every PR

Dependencies
SHA-pinned Actions
We pin each GitHub Action to a commit, so nobody can swap in new code by moving a tag.
3-day cooldown
uv and npm won't install a package version until it has been public for 3 days.
Lockfiles
We lock Python dependencies in uv.lock and turn off npm install scripts. CI checks each downloaded tool against a pinned SHA-256.
Fork guard
PRs from forks can't change uv.lock or pyproject.toml.
Scanners on every PR
zizmor
Finds unsafe GitHub workflow patterns.
CodeQL, semgrep
Static analysis with the security-extended query set.
Veria AI
AI review bot that flags security issues in PRs.
OSV-Scanner, Grype
Known vulnerabilities in lockfiles and built images, on PRs and daily.

05 / Bug bounty

Our bug bounty program

File a private report on GitHub with steps to reproduce and a video of the exploit against a live instance.

When an unauthenticated attacker can reach a bug, we fix it in a private fork and publish the release, backports and advisory together.

Read the full policy →

P0 · Critical

Supply chain compromise of our PyPI or Docker releases

$1,500–$3,000

P1 · High

Unauthenticated access to protected proxy data

$500–$1,500

P2 · Medium

Authenticated privilege escalation

Reports welcome, no bounty yet

06 / Disclosures

Our incidents and advisories

07 / Partners and programs

Partners and programs

Hear about fixes before they ship.

Subscribers get 1 to 2 days of notice before we release a fix for a severe or unauthenticated vulnerability.