Trivy ist ein weit verbreiteter Open‑Source‑Security‑Scanner für Container, Repositories und Kubernetes, der in vielen CI/CD‑Pipelines als zentrales Sicherheitswerkzeug eingesetzt wird. Am 1. März 2026 wurde ein Sicherheitsvorfall rund um das Projekt öffentlich, der in der GitHub‑Discussion #10265 beschrieben ist und darauf hinweist, dass Ressourcen im Umfeld des Projekts kompromittiert wurden. Für ein Tool, dem viele Teams quasi blind vertrauen, ist das ungefähr so angenehm, als würde man merken, dass die Alarmanlage selbst ein offenes WLAN hat.
Für DevOps‑ und Security‑Teams ist der Vorfall vor allem ein Reminder, Supply‑Chain‑Risiken ernst zu nehmen: Welche Trivy‑Versionen nutzen wir, wo kommen Binaries und Images her, sind Versionen und Digests fest gepinnt oder ziehen wir „latest“, und mit welchen Rechten laufen unsere Scanner in CI/CD‑Pipelines. Sinnvolle Sofortmaßnahmen sind eine Inventur aller Trivy‑Verwendungsstellen, das Prüfen von Checksummen bzw. Signaturen, ein Update auf als sicher kommunizierte Releases, das Herunterdrehen von Permissions (Least Privilege) und gegebenenfalls das Rotieren von Secrets, die Trivy‑Jobs sehen konnten.
Positiv ist, dass der Incident transparent in der öffentlichen Diskussion dokumentiert wird, statt in einem dunklen Ticket‑System zu verschwinden. Kein Security‑Tool ist unfehlbar, und der Vorfall ist weniger ein Grund zur Panik als eine Steilvorlage, die eigene Tool‑Chain erwachsener zu betreiben: Versionen pinnen, Signaturen prüfen, SBOMs nutzen und sich daran gewöhnen, dass auch Scanner nur Menschen sind – metaphorisch gesprochen.