Das Tool, dem du vertraust, Malware zu finden, liefert Malware aus.
Am 19. März 2026 war dieser Satz keine Metapher. Er war die technische Realität für jeden Entwickler und jedes Unternehmen, das in diesem Zeitfenster Trivy 📎 in seiner CI/CD-Pipeline laufen hatte. Nach Aqua-Angaben kommt das Tool auf mehr als 100 Millionen jährliche Downloads 📎 und gilt damit als einer der meistverbreiteten Open-Source-Vulnerability-Scanner weltweit — breit integriert in die Build- und Scan-Workflows von Banken, Cloud-Anbietern und Entwicklungsteams auf allen Kontinenten.
Und Trivy ist ein israelisches Produkt. Es stammt von Aqua Security 📎, 2015 in Israel gegründet, mit seinen Wurzeln in Tel Aviv und Ramat Gan.
Ich schreibe das nicht, weil es ein hübsches Detail ist. Ich schreibe es, weil es die eigentliche Dimension dieses Vorfalls beschreibt: Ein israelisches Unternehmen, das die Aufgabe übernommen hat, einen kritischen Teil der globalen Entwicklungsinfrastruktur zu sichern, wurde selbst zum Einfallstor.
Zehn Jahre Aufbau — und eine schlecht getaktete Krise
Dror Davidoff und Amir Jerbi gründeten Aqua Security 2015 in Tel Aviv mit einer Vision, die damals radikal klang: Sicherheit nicht als nachträgliches Audit, sondern als integraler Bestandteil des gesamten Cloud-nativen Entwicklungszyklus. Der Container-Boom um Docker und Kubernetes explodierte gerade, und mit ihm die Erkenntnis, dass bestehende Sicherheitstools für diese neue Welt nicht gemacht waren. Aqua baute gezielt für dieses Vakuum.
2021 überschritt das Unternehmen mit einer Series-E-Runde über 135 Millionen Dollar 📎 die Milliarden-Dollar-Bewertung — mit Beteiligung von Microsofts Venture-Arm M12, Lightspeed, Insight Partners und TLV Partners. Über 500 der weltweit größten Unternehmen, darunter 40 Prozent der Fortune 100, schützten ihre Infrastruktur mit Aquas Plattform. Israels neuestes Unicorn, und die Wachstumsgeschichte schien ungebremst.
Trivy war dabei die strategisch klügste Entscheidung: Ein kostenloses, quelloffenes Tool, das Millionen Entwickler in ihre Workflows integrierten — und das gleichzeitig die Tür zur kommerziellen Plattform öffnete. Trivy wurde zum Standard-Scanner für die Harbor Registry, für GitLab, für Amazons Container Registry. Wer Trivy kannte, kannte Aqua Security. Und wer Aqua Security kannte, kaufte irgendwann die Plattform dahinter.
Was weniger öffentlich sichtbar war: Aqua Security befand sich zum Zeitpunkt des Angriffs in einer Phase des internen Umbaus. Im November 2025 gaben Davidoff und Jerbi ihre operativen Rollen ab — Mike Dube 📎, zuvor CRO mit Stationen bei CrowdStrike, Splunk, Cybereason und Check Point, übernahm als neuer CEO. Wenige Wochen später folgten Entlassungen, darunter 20 Stellen in Israel 📎, als Teil einer Restrukturierung auf Profitabilität.
Solche Übergangsphasen erhöhen erfahrungsgemäß das Risiko von Koordinations- und Reaktionsproblemen — und es ist die Phase, in der dieser Angriff landet.
Warum Trivy ein Hochwertziel ist, das kaum jemand als solches nennt
Bevor ich die Angriffskette beschreibe, möchte ich kurz erklären, warum dieser Vorfall strukturell ein anderes Gewicht hat als ein gewöhnlicher Supply-Chain-Angriff.
Trivy ist tief in automatisierte Pipelines eingebettet — es wird aufgerufen, bevor Code deployed wird, bevor Container in Produktion gehen, bevor Kubernetes-Cluster skalieren. Über 10.000 GitHub-Workflow-Dateien 📎 sind allein auf trivy-action angewiesen. Unternehmen, die Trivy in CI/CD-Workflows mit weitreichenden Runner- und Secret-Berechtigungen einsetzen — und das ist in der Praxis die Mehrheit — geben dem Tool faktisch Zugriff auf hochsensible Build-Umgebungen und alle darin verfügbaren Secrets. SSH-Keys, Cloud-Credentials, Kubernetes-Tokens, API-Keys. Alles, was eine moderne Produktionsinfrastruktur zusammenhält.
Das ist die eigentliche Pointe. Die Sicherheitsindustrie hat ausgefeilte Systeme für das Tracking von Schwachstellen in Softwarepaketen gebaut. Was sie kaum gebaut hat, ist das Monitoring des Security-Posture der Tools 📎, die dieses Tracking durchführen. Das ist eine strukturelle Lücke, und der Trivy-Vorfall macht sie unmöglich zu ignorieren.
Ich habe ähnliche Blindspot-Probleme bereits im SOC-Kontext beschrieben — wenn die Monitoring-Infrastruktur selbst unsichtbar versagt 📎. Der Trivy-Angriff ist dieselbe Denkfigur, nur eine Ebene tiefer: Nicht das SOC übersieht seinen eigenen Ausfall. Der Scanner übersieht seine eigene Kompromittierung — und führt dabei ganz normal weiter seinen Scan durch, damit niemand etwas bemerkt.
Drei Wochen, zwei Angriffe, ein Versäumnis
Was am 19. März geschah, begann am 28. Februar — und der Zusammenhang ist nicht zufällig.
Ein autonomer KI-gesteuerter Angriffsbot namens „hackerbot-claw“ 📎 nutzte eine bekannte Fehlkonfiguration im Trivy-Repository aus — den sogenannten pull_request_target-Trigger. Mit dem so gestohlenen Personal Access Token löschte er alle 178 GitHub-Releases sowie das gesamte Repository. Der pull_request_target-Trigger ist in der CI/CD-Community seit Jahren als hochriskant dokumentiert: Er führt Workflows mit vollen Repository-Rechten aus, auch wenn er von einem Fork ausgelöst wird. Das nennt sich „Pwn Request“-Muster. Trivy hatte es aktiv in seiner Build-Pipeline.
Eine Randbemerkung, die ich nicht unerwähnt lassen möchte: Der Name „hackerbot-claw“ und die verwendete Domain hackmoltrepeat.com referenzieren „molt“ — dieselbe Namenskonvention wie das OpenClaw/MoltBot-Ökosystem, das in dieser Zeit als parallele KI-Agenten-Sicherheitskrise für Schlagzeilen sorgte. Ob direkte Verbindung oder bewusstes Naming-Borrowing als Tarnfarbe: Es bleibt unklar. Relevant ist es trotzdem — in einer Phase, in der die Namenslandschaft rund um autonome Agenten so unübersichtlich war, funktionierte selbst die Benennung von Angriffswerkzeugen als Verwirrungsstrategie.
Aqua Security reagierte auf den Februar-Angriff, rotierte Credentials, veröffentlichte einen Incident Report. Die Community betrachtete den Vorfall als abgeschlossen.
Er war es nicht — weil die Reaktion einen kritischen Fehler enthielt. Aqua räumte später im offiziellen GitHub-Incident-Thread 📎 ein: „Unsere Eindämmung des ersten Vorfalls war unvollständig. Wir haben Secrets und Tokens rotiert, aber der Prozess war nicht atomar — die Angreifer könnten Zugang zu frisch generierten Tokens erlangt haben.“
Diese Aussage ist selbst ein Befund.
Nicht-atomare Secret-Rotation bedeutet: Es gibt ein Zeitfenster zwischen dem Moment, in dem das alte Credential ungültig wird, und dem Moment, in dem das neue vollständig ausgerollt ist. Wer in diesem Fenster beobachtet, kann das neue Credential abgreifen. Genau das ist hier offenbar passiert. Es ist eine Situation, die mich an das erinnert, was ich über Confident-Wrong-Entscheidungen unter Druck 📎 geschrieben habe: Der Glaube, das Problem gelöst zu haben, ist oft gefährlicher als das Eingestehen, dass man es nicht vollständig im Griff hat.
Drei Wochen später schlugen die Angreifer zu. Wie Wiz Research in seiner Analyse 📎 dokumentiert, tätigten sie Impersonations-Commits unter Vortäuschung bekannter Entwickleridentitäten und veröffentlichten um 17:43:37 UTC die malicious Release v0.69.4 — backdoorte Binaries, distribuiert über GitHub Releases, Docker Hub, GHCR und Amazon ECR, mit Schadcode von der Typosquatting-Domain scan.aquasecurtiy[.]org — ein einzelnes vertauschtes ‚i‘ in „security“. Wer nicht genau hinschaut, sieht nichts Auffälliges.
Gleichzeitig zeigte sich das eigentliche Ausmaß. Socket dokumentiert 📎, wie der Angreifer 75 von 76 Tags im aquasecurity/trivy-action-Repository force-pushte — und damit vertrauenswürdige Versionsnummern in Distributionskanäle für die Malware verwandelte. Jedes Unternehmen, das trivy-action per Versions-Tag referenzierte — was die große Mehrheit tut — rief in diesem Zeitfenster automatisch Schadcode in seine Build-Umgebung. Es gab keine Warnung. Die Scans liefen normal durch.
Die Forensik enthält dabei ein Detail, das die Sorgfalt der Täter zeigt: Jeder malicious Commit trug einen Zeitstempel aus dem ursprünglichen Release-Jahr — 2021, 2022 — hatte aber einen Parent-Commit aus März 2026 📎. Physikalisch unmöglich, und damit ein eindeutiges Manipulationsindiz. Zusätzlich fehlte die Web-Flow-GPG-Signatur von GitHub. Kaum ein DevOps-Team führt solche Checks routinemäßig durch. Warum auch — man vertraut dem Scanner.
Die Schadsoftware operierte in drei Stufen: Sammlung von Credentials aus dem Runner-Prozessspeicher und dem Filesystem, Verschlüsselung mit AES-256 und RSA-4096, anschließend Exfiltration. Scheiterte die Exfiltration am primären Kanal, wurde das GitHub-Konto des Opfers selbst missbraucht, um die gestohlenen Daten in einem öffentlichen Repository namens tpcp-docs 📎 zwischenzuspeichern. Der Angreifer nutzte also die Infrastruktur des Opfers als eigenen Zwischenspeicher. Das ist kein technischer Zufall — das ist Kalkül.
StepSecurity dokumentiert 📎 noch eine weitere Dimension: Die Angreifer löschten Aquas ursprünglichen Incident Report aus dem Repository und fluteten Diskussions-Threads mit koordinierten Bot-Accounts, um die sachliche Debatte zu verdrängen. Trolling und Ablenkung als taktische Ergänzung zum technischen Angriff — das ist kein Zufall, sondern Methode.
TeamPCP: Was über die Tätergruppe bekannt ist
Die Gruppe, die sich zu dem Angriff bekennt, ist bemerkenswert jung. TeamPCP — auch bekannt als PCPcat, ShellForce und DeadCatx3 — tauchte erst im November 2025 auf 📎, mit ersten Telegram-Aktivitäten ab dem 17. November 2025. Vier Monate von der Gründung bis zur Kompromittierung eines der meistverbreiteten Security-Tools der Welt.
TeamPCP funktioniert als cloud-native Cybercrime-Plattform: Datenexfiltration, Ransomware, Erpressung und Kryptomining parallel 📎, als integriertes Geschäftsmodell. In einer früheren Kampagne um Weihnachten 2025 wurden bereits 185 kompromittierte Server 📎 mit angreifer-kontrollierten Containern identifiziert — Azure stand für 61 Prozent, AWS für 36 Prozent der betroffenen Infrastruktur. Die Stärke liegt dabei nicht in technischer Innovation, sondern in operativer Integration und Skalierung — die meisten Exploits basieren auf bekannten Schwachstellen und modifizierten Open-Source-Tools.
Das ist keine Randnotiz. Das ist das eigentliche Bedrohungsprofil: Keine Zero-Days, keine staatliche Infrastruktur — nur industrialisierte Anwendung bekannter Techniken in einem Tempo, das Verteidiger strukturell benachteiligt. Die Frage, wie KI-gestützte Systeme unter Eskalationsdruck reagieren 📎, stellt sich bei TeamPCP auf der Angriffsseite: schnell, adaptiv, ohne menschliche Bremsen.
Die Selbstbezeichnung als „TeamPCP Cloud Stealer“ im Quellcode könnte auch ein False Flag sein — aber die technische Überschneidung mit bekanntem TeamPCP-Tooling macht eine Zuordnung operativ plausibel, wenn auch nicht abschließend bewiesen. Wer das False-Flag-Argument ernstnehmen möchte, dem sei gesagt: Es ändert nichts an der Angriffskette und nichts an den notwendigen Reaktionen.
Das Schadensausmaß — und was noch offen ist
Je nach Quelle war trivy-action für rund zehn bis zwölf Stunden kompromittiert, setup-trivy für rund vier Stunden, die malicious Binary v0.69.4 für rund drei Stunden. StepSecurity analysierte 📎 767 Repositories mit über 100 Stars und bestätigte, dass 45 mindestens einen kompromittierten Workflow-Run ausgeführt hatten. In fünf davon hatten die Jobs direkten Zugang zu AWS-Credentials, Docker Hub-Tokens oder GitHub Container Registry-Zugangsdaten. Das sind die bestätigten Fälle. Die Dunkelziffer ist nicht bekannt.
Die Kaskaden-Effekte reichen weiter. Der Angreifer kompromittierte auch den aqua-bot-Serviceaccount und nutzte diesen Zugang, um weitere Projekte aus Aquas Portfolio zu attackieren — inklusive dem Diebstahl von GPG-Keys sowie Credentials für Docker Hub und Slack. Und der Vorfall ist kein abgeschlossenes Kapitel: TeamPCP hat die gestohlenen Tokens genutzt, um Operationen auf das npm-Ökosystem über einen Wurm namens „CanisterWorm“ auszuweiten — mit einer aktiv weiterentwickelten Payload namens kamikaze.sh.
CrowdStrike beschreibt 📎, wie der Angriff durch Laufzeit-Anomalie-Erkennung in Falcon-geschützten Umgebungen sichtbar wurde — die Schadsoftware verhielt sich in Mustern, die mit normalem CI/CD-Verhalten nicht vereinbar waren. Das ist der Erkennungsvektor, der funktioniert hat. Er setzt aber voraus, dass man Laufzeit-Monitoring in CI/CD-Umgebungen überhaupt aktiviert hat. Das ist nicht der Standard.
NIS-2, CRA und Produkthaftung: Was dieser Vorfall regulatorisch bedeutet
Dieser Abschnitt fehlt in den meisten technischen Analysen — weil er unbequem ist. Ich schreibe ihn trotzdem, weil er für die CISOs und ISBs unter meinen Lesern direkt handlungsrelevant ist. Ich tue das als Praktiker, nicht als Jurist — und entsprechend sollte dieser Abschnitt gelesen werden.
Für betroffene Organisationen unter NIS-2: Wer Trivy in einer CI/CD-Pipeline betrieb, die unter NIS-2 fällt, und dessen Pipeline im Zeitfenster des Angriffs lief, sollte eine konkrete Folgefrage dokumentiert haben: War das ein meldepflichtiger Sicherheitsvorfall? Die Meldepflicht nach § 32 BSIG 📎 knüpft an erhebliche Auswirkungen auf die Netzwerk- und Informationssysteme an — ob ein kompromittierter Build-Prozess diesen Schwellenwert erfüllt, hängt von den konkreten Auswirkungen im Einzelfall ab. Was in jedem Fall gilt: Die Prüfung selbst muss dokumentiert sein. Wer sie nicht vorgenommen oder nicht dokumentiert hat, hat ein Governance-Problem.
Für die Managementverantwortung: NIS-2 hat in Deutschland mit § 38 BSIG 📎 klare Pflichten der Unternehmensleitung verankert — darunter die Verpflichtung, Risikomanagementmaßnahmen zu billigen, zu überwachen und entsprechende Schulungen zu absolvieren. Supply-Chain-Risiken sind explizit Teil dieser Anforderungen. Ob daraus im Einzelfall persönliche Haftung folgt, ist eine juristische Einzelfallbewertung. Was aber feststeht: Wer als CISO oder Geschäftsführer nachweislich keine Maßnahmen gegen eine seit dem tj-actions-Vorfall 2025 📎 bekannte Risikokategorie ergriffen hat, hat ein Dokumentationsproblem — und damit ein Governance-Problem. Die Frage „Wie pinnt ihr eure GitHub Actions?“ ist ab sofort keine akademische Frage mehr.
Für Aqua Security als Anbieter: Hier wird es interessant — und juristisch offen. Trivy ist Open Source, kostenlos, und Aqua Security stellt es explizit als Community-Projekt bereit. Die klassische Open-Source-Disclaimer-Logik würde sagen: Keine Garantie, keine Haftung. Der Cyber Resilience Act 📎, der stufenweise in Kraft tritt, schafft hier eine Grauzone, die noch nicht abschließend geklärt ist: Die EU unterscheidet zwischen freier Open-Source-Software, kommerziellen Aktivitäten und sogenannten „Open-Source Software Stewards“, für die abgestufte Pflichten gelten. Aqua Security ist ein kommerzielles Unternehmen, das Trivy als Teil seiner Go-to-Market-Strategie betreibt — ob und wie genau das Unternehmen unter welche CRA-Kategorie fällt, ist eine offene Frage. Ich habe die grundsätzliche Problematik am Beispiel israelischer Hardware-Hersteller beschrieben 📎 — und das Trivy-Szenario zeigt, dass sie sich auch für Software-Anbieter stellt, die Open Source als Vertriebskanal nutzen.
Was das für israelische Technologieunternehmen bedeutet, die ähnliche Open-Source-Strategien für den europäischen Markteintritt verfolgen: Das rechtliche Fundament, auf dem man sich bewegt, ist nicht mehr dasselbe wie vor 2025. Diese Lücke zu ignorieren ist selbst ein Befund.
Die strukturellen Lehren — und eine unbequeme Pointe
Es gibt drei Erkenntnisse, die über diesen Einzelfall hinausgehen.
Erstens: Mutable Tags sind ein grundlegendes Vertrauensproblem. Version Tags können auf malicious Commits umgezeigt werden — GitHub Actions sollten an vollständige Commit-SHAs gepinnt werden. Das klingt nach einer technischen Kleinigkeit. Es ist eine fundamentale Fehlkonstruktion im Vertrauensmodell der meisten CI/CD-Pipelines — und war seit dem tj-actions-Vorfall 2025 📎 bekannt, der exakt dasselbe Muster zeigte.
Zweitens: Secret-Rotation nach einem Incident muss atomar sein — oder sie ist kein Schutz, sondern ein weiteres Beobachtungsfenster für den Angreifer. Das lässt sich technisch lösen. Es erfordert aber Disziplin in einem Moment, in dem man unter erheblichem Druck steht.
Drittens — und das ist die unbequeme Pointe: Chainguard 📎-Kunden waren nicht betroffen. Chainguard baut Trivy direkt aus dem Applikationsquellcode und bezieht keine vorgefertigten Upstream-Artifacts. Da nur der Build- und Release-Workflow kompromittiert war, nicht der Quellcode selbst, produzierte die unabhängige Build-Pipeline ein sauberes Image. Das zeigt: Die technische Lösung existiert. Sie wird nur nicht überall angewendet.
Was solche Compliance-Aussagen tatsächlich belegen und wo ihre Grenzen liegen, habe ich am Beispiel regulierter KI-Umgebungen beschrieben 📎 — das Grundproblem ist dasselbe: Compliance-Aussagen und operative Sicherheit sind nicht dasselbe.
Was das für israelische Technologieunternehmen in Europa bedeutet
Als Executive Security Architect begleite ich israelische Technologieunternehmen beim Markteintritt in Deutschland und Europa — genau dort, wo Produktarchitektur auf Vertrauenswirklichkeit trifft.
Trivy ist ein Paradebeispiel dafür, wie Vertrauen in Europa aufgebaut wird — durch technische Exzellenz, durch Open Source, durch Ubiquität. Aqua hat in zehn Jahren eine globale Abhängigkeit von einem Tool geschaffen, das aus Israel kommt. Das ist beeindruckend und selten.
Diese Woche wurde dieses Vertrauen beschädigt. Nicht irreparabel — aber spürbar. Ich mache mir weniger Sorgen um die technische Reaktion, die erkennbar läuft, als um die kommunikative. Europäische Enterprise-Kunden, die Trivy in ihren Pipelines betreiben, haben in den letzten 72 Stunden eine Frage gestellt: Wie hat Aqua reagiert, und wie transparent war die Kommunikation? Die Antwort auf diese Frage entscheidet oft mehr über langfristiges Vertrauen als die technische Qualität des Incident Response selbst.
Die israelische Cyber-Industrie ist gut darin, Angriffe zu analysieren. Sie ist weniger geübt darin, sich öffentlich zu den eigenen Fehlern zu verhalten — und das fällt im deutschen und europäischen Markt besonders auf, wo regulatorische Nachweisfähigkeit und Governance-Kultur strukturell anders gewichtet werden als im US-amerikanischen. Der Trivy-Vorfall ist ein weiteres Lehrstück dafür, dass technische Exzellenz allein keine hinreichende Vertrauensbasis in Europa ist. Wie strategische Investoren israelische Cyber-Assets in diesem Licht bewerten sollten, habe ich hier ausgeführt 📎.
Was dieser Artikel nicht beantwortet
Wie viele der kompromittierten Credentials tatsächlich eingesetzt wurden und welche Organisationen konkret betroffen sind, ist zum Zeitpunkt dieses Artikels nicht öffentlich bekannt. Ob TeamPCP staatlich unterstützt ist oder rein kriminell motiviert, bleibt offen. Wie weit die CanisterWorm-Ausbreitung im npm-Ökosystem reicht, wird erst in den nächsten Tagen vollständig sichtbar werden.
Und die regulatorisch vielleicht wichtigste offene Frage: Wird ein europäischer Regulator in den nächsten Monaten die Einordnung von Aqua Security unter den CRA prüfen — und wenn ja, welche Konsequenzen das für die Haftung bei diesem Vorfall hat? Diese Frage ist noch nicht gestellt worden. Sie wird gestellt werden.
Diese Lücke ist selbst ein Befund.
Eine persönliche Anmerkung zum Abschluss: Ich nutze Trivy selbst in Architektur-Assessments, wenn ich CI/CD-Pipelines israelischer Unternehmen für den europäischen Markteintritt evaluiere. Der Vorfall ändert nichts daran, dass es das beste frei verfügbare Tool seiner Klasse ist. Er ändert jedoch, wie ich künftig die Frage stelle: Nicht nur „Welchen Scanner nutzt ihr?“ — sondern auch „Wie pinnt ihr eure GitHub Actions, habt ihr euren Secret-Rotation-Prozess validiert, und habt ihr Trivy als Lieferanten in eurer NIS-2-Risikobeurteilung?“ Das sind keine Fragen, die ich bisher routinemäßig gestellt habe. Das ist eine direkte Konsequenz aus diesem Vorfall.
Sie betreiben eine CI/CD-Infrastruktur und fragen sich, ob Ihre aktuelle Trivy-Integration im Angriffsfenster kompromittiert war — oder welche NIS-2-Dokumentationspflichten sich daraus ergeben? Oder Sie sind israelisches Technologieunternehmen und suchen den Einstieg in den europäischen Markt mit einem Sicherheitsprodukt, das auch unter CRA und NIS-2 trägt? Schreiben Sie mir direkt. 📎
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar