[Docs] Add cosign Docker image verification steps to security blog posts

[yuneng-berri]

Summary

Problem

The cosign Docker image verification steps from the release GHA workflow are not documented in the security-related blog posts, so users don't know how to verify image signatures.

Fix

Added cosign verification instructions to three blog posts:

• CI/CD v2 — new "Verify Docker image signatures" section + bullet point in "What changed"
• Security Townhall — "How to verify a Docker image with Cosign" subsection under Release Auditing
• Security Update — "Verify Docker image signatures" section before Verified Safe Versions

Type

📖 Documentation

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Apr 5, 2026 5:23pm

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
0 out of 2 committers have signed the CLA.

❌ krrish-berri-2
❌ yuneng-berri
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codspeed-hq]

Merging this PR will not alter performance

✅ 16 untouched benchmarks

---

_{Comparing litellm_/vibrant-wu (3c9aa5e) with main (4c1ef42)}

[greptile-apps]

Greptile Summary

This PR adds cosign Docker image verification instructions to three security-related blog posts (ci_cd_v2_improvements, security_townhall_updates, security_update_march_2026) and the main deployment guide (docs/proxy/deploy.md), following the rollout of image signing in PR #24683. The documentation update is clear and consistent across the blog posts — each correctly scopes signing to GHCR images starting from v1.83.0-nightly — and the outdated "have already begun working on it" wording in the security townhall has been updated to reflect the completed status.

• Key finding: docs/proxy/deploy.md omits both the GHCR registry scope and the v1.83.0-nightly version constraint that all three blog posts include, and the Docker example immediately below the new section uses a docker.litellm.ai (Docker Hub) image URL that cannot be verified with the cosign command shown.
• Five security scan configuration/tooling files (ci_cd/security_scans.sh, ci_cd/.grype.yaml, two .trivyignore files, and one from docs/my-website/) are deleted without explanation in a PR scoped as documentation-only. While none are currently referenced by .github/ workflows, this should be acknowledged in the PR description.
• The temporal inconsistency in security_townhall_updates (noted in the previous review thread) has been addressed — the transition sentence now reads "have shipped it" rather than "have already begun working on it".

Confidence Score: 4/5

Safe to merge after resolving the GHCR-scope inaccuracy in deploy.md and confirming the security tooling deletions are intentional.

One P1 finding: deploy.md omits the GHCR-only and v1.83.0-nightly+ scoping that all blog posts include, and the adjacent Docker example uses a Docker Hub URL that cannot be cosign-verified. This is a correctness issue in the user-facing deployment docs that could mislead users into thinking older or Docker Hub images are signed when they are not.

docs/my-website/docs/proxy/deploy.md (line 70 over-broad claim) and the five deleted security tooling files need confirmation.

Important Files Changed

Filename	Overview
docs/my-website/docs/proxy/deploy.md	New 'Verify Docker image signatures' section added but over-claims all images are signed without scoping to GHCR or the v1.83.0-nightly+ version constraint
docs/my-website/blog/ci_cd_v2_improvements/index.md	New section correctly scopes cosign signing to GHCR images starting from v1.83.0-nightly with clear verification steps
docs/my-website/blog/security_townhall_updates/index.md	Updated transition sentence from 'begun working on it' to 'shipped it' and added correctly scoped cosign verification subsection
docs/my-website/blog/security_update_march_2026/index.md	New 'Verify Docker image signatures' section added with correct GHCR scoping and version constraint
ci_cd/security_scans.sh	File deleted — comprehensive Trivy + Grype scan runner removed without explanation in a docs PR
ci_cd/.grype.yaml	File deleted — Grype CVE ignore list with documented rationale removed without explanation
.trivyignore	File deleted — root Trivy CVE allowlist removed without explanation
ui/litellm-dashboard/.trivyignore	File deleted — UI-specific Trivy CVE allowlist removed without explanation
.github/workflows/run_llm_translation_tests.py	File mode change only (755→644), no content change

Sequence Diagram

sequenceDiagram
    actor User
    participant GHCR as GHCR Registry
    participant GitHub as GitHub Raw
    participant Cosign as cosign CLI

    User->>GHCR: Pull ghcr.io/berriai/litellm:<tag>
    User->>GitHub: Fetch cosign.pub from raw.githubusercontent.com/<tag>/cosign.pub
    User->>Cosign: cosign verify --key cosign.pub ghcr.io/berriai/litellm:<tag>
    Cosign->>GHCR: Retrieve image manifest + signature
    Cosign->>Cosign: Validate signature against public key
    Cosign-->>User: Verification result (claims validated, signatures verified)

Loading

_{Reviews (5): Last reviewed commit: "[Docs] Add starting version callout to c..." | Re-trigger Greptile}

[greptile-apps]

Temporal inconsistency within the same section

The sentence immediately preceding the new subsection reads:

"We believe that Cosign is a good fit for this, and have already begun working on it [PR]."

But the very next subsection opens with:

"All LiteLLM Docker images are now signed with cosign."

A reader will see these two statements in the same paragraph/section and interpret them as contradictory — the older sentence implies signing is in progress/incomplete, while the new one states it is fully done. Consider updating the transition sentence to reflect the completed status, e.g.:

Suggested change

	We believe that [Cosign](https://github.com/sigstore/cosign) is a good fit for this, and have already begun working on it [PR](https://github.com/BerriAI/litellm/pull/24683).
	#### How to verify a Docker image with Cosign
	All LiteLLM Docker images are now signed with [cosign](https://docs.sigstore.dev/cosign/overview/). To verify the integrity of an image before deploying:
	We believe that [Cosign](https://github.com/sigstore/cosign) is a good fit for this, and have shipped it in [PR #24683](https://github.com/BerriAI/litellm/pull/24683).

[krrish-berri-2]

The phrasing here makes it look like this was always the case. We should be clear from which version this is implemented from. @yuneng-berri

[krrish-berri-2]

The phrasing here makes it look like this was always the case. We should be clear from which version this is implemented from. @yuneng-berri