Was der BSI C5:2026 leistet

Der Cloud Computing Compliance Criteria Catalogue ist seit 2016 der deutschlandweit wichtigste Sicherheitsstandard für Cloud-Anbieter und Cloud-Nutzer. Er übersetzt komplexe Sicherheitsanforderungen in prüfbare Kriterien und schafft damit Vergleichbarkeit zwischen Anbietern. Prüfungen nach C5 werden von Wirtschaftsprüferinnen und Wirtschaftsprüfern durchgeführt, die nach erfolgreicher Prüfung testieren, dass ein Cloud-Anbieter die definierten Sicherheitskriterien erfüllt.

Mit der Veröffentlichung des BSI C5:2026 trägt die Behörde den technologischen Entwicklungen der vergangenen Jahre Rechnung. Inhaltlich und strukturell orientiert sich der Katalog eng an den Arbeiten zum europäischen Zertifizierungsschema EUCS und kann in Teilen als dessen deutsche Interpretation gelesen werden. Berücksichtigt wurden zudem die aktuellen Versionen der CSA Cloud Controls Matrix v4, der ISO/IEC 27001:2022 und der NIS2-Direktive.

Neue Themen im Kriterienkatalog

Drei Themenbereiche werden im BSI C5:2026 erstmals dezidiert aufgegriffen. Container-Management erhält wesentlich genauere Vorgaben als in der Vorgängerversion und reagiert damit auf eine Technologie, die in modernen Cloud-Architekturen längst Standard ist. Confidential Computing wird als eigenständiger Themenbereich verankert und schließt eine Lücke, die in bisherigen Prüfkatalogen kaum greifbar gemacht wurde.

Besondere Aufmerksamkeit verdient die Aufnahme der Post-Quanten-Kryptographie. Kapitel 5.8 enthält umfangreiche Vorgaben zur wirksamen Verschlüsselung, darunter den Einsatz von Hybridverfahren, mit denen absehbar zu schwache Algorithmen gehärtet werden sollen. Damit reagiert das BSI auf eine Entwicklung, die für viele Cloud-Anbieter erst in den kommenden Jahren operativ relevant wird, deren Vorbereitung jedoch bereits heute beginnen muss.

Bestehende Themen wurden geschärft. Mandantentrennung und Supply Chain Management werden gezielter adressiert als zuvor. Auch klassische Bereiche wie die Absicherung der Kundendaten und das Vorfallmanagement bleiben fester Bestandteil des Katalogs.

Strukturelle Neuerungen und Maschinenlesbarkeit

Strukturell wurde der Katalog deutlich überarbeitet. C5-Kriterien bestehen nun aus voneinander abgegrenzten Unterkriterien. Zusatzkriterien werden klassifiziert danach, ob sie bestehende Basiskriterien durch strengere Anforderungen verschärfen oder durch neue Anforderungen ergänzen. Diese Differenzierung soll Prüfung, Zuordnung und Auswertung erleichtern.

Eine wichtige Neuerung folgt in Kürze: Der Katalog wird erstmals auch in einem maschinenlesbaren Format bereitgestellt, geplant sind YAML, XLSX und PDF in deutscher und englischer Sprache. Diese Bereitstellung erleichtert die Nutzung in Governance-, Risiko- und Compliance-Prozessen und schafft eine gemeinsame Sprache dafür, wie Cloud-Sicherheit beschrieben, geprüft und bewertet werden kann. Für die Automatisierung von Prüfprozessen und die Integration in bestehende Compliance-Plattformen ist das ein zentraler Schritt.

Bedeutung für regulierte Branchen

Für viele Sektoren ist ein C5-Testat kaum eine freiwillige Auszeichnung, sondern faktische Marktzugangsvoraussetzung. Im digitalen Gesundheitswesen wird seit Juli 2025 ein Typ-2-Testat verlangt, sobald Patientendaten in einer Cloud verarbeitet werden. Auch im Bankensektor, bei digitalen Finanzdienstleistungen und bei staatlichen Stellen gilt der C5 vielfach als maßgeblicher Standard.

Der Aufwand einer offiziellen Testierung bleibt hoch. Die Prüfung ist umfangreich, kostenintensiv und damit insbesondere für etablierte Anbieter stemmbar. Für kleinere und mittlere Cloud-Anbieter bleibt die Hürde bestehen, auch wenn die maschinenlesbare Bereitstellung des Katalogs perspektivisch dazu beitragen könnte, manuelle Aufwände zu reduzieren.

Ergänzend will das BSI in Kürze allgemeine Souveränitätskriterien für Cloud-Computing-Lösungen veröffentlichen. Damit entsteht ein zweites Regelwerk, das nicht nur Sicherheitsfragen, sondern auch Aspekte digitaler Souveränität adressiert.

Handlungsempfehlungen für Cloud-Anbieter und Anwender

Cloud-Anbieter sollten frühzeitig eine Gap-Analyse zwischen ihrem aktuellen Setup und den Anforderungen des BSI C5:2026 durchführen. Besonderes Augenmerk verdienen die neuen Themenbereiche Container-Management, Post-Quanten-Kryptographie und Confidential Computing, da hier in vielen Bestandsumgebungen die größten Lücken zu erwarten sind. Auch Supply-Chain-Prozesse sollten überprüft werden, da die geschärften Kriterien strengere Nachweise zur Sicherheit von Unterauftragnehmern verlangen.

Cloud-Nutzer sollten in laufenden Vergabeverfahren prüfen, ob bestehende C5:2020-Testate ihrer Anbieter eine belastbare Roadmap für den Übergang auf den neuen Katalog enthalten. Informationssicherheitsbeauftragte sollten den Katalog frühzeitig in interne Risikobewertungen einbeziehen, insbesondere dort, wo regulatorische Anforderungen wie NIS2, DORA oder Vorgaben aus dem Gesundheitswesen greifen.

Der Beitrag BSI C5:2026: Neuer Kriterienkatalog für Cloud-Sicherheit erschien zuerst auf Ilja Schlak InfoSec Blog.

Cybersecurity-Markt Q1 2026 erreicht 6,3 Milliarden US-Dollar Gesamtvolumen

Der Q1 2026 Cybersecurity Market Review von Momentum Cyber dokumentiert ein Quartal historischer Dimension. Über 211 Finanzierungsrunden flossen insgesamt 3,8 Milliarden US-Dollar in Cybersecurity-Unternehmen – ein Anstieg um 33 % gegenüber dem Vorjahresquartal. Parallel dazu erreichte das M&A-Geschehen mit 108 Transaktionen und einem offengelegten Gesamtwert von 2,6 Milliarden US-Dollar den zweithöchsten Quartalswert in der 65 Quartale umfassenden Erhebungshistorie. Zusammengenommen summiert sich die strategische Aktivität im Cybersecurity-Markt Q1 2026 auf 6,3 Milliarden US-Dollar.

Dass die Finanzierungen die M&A-Volumina übertrafen, ist ein seltenes Phänomen. Laut Momentum Cyber ist das erst zum vierten Mal seit 2018 der Fall. Die Analysten sehen darin ein Zeichen dafür, dass der im Januar in ihrem jährlichen Cybersecurity Almanac beschriebene „Capital Super Cycle” nun in Echtzeit sichtbar wird. Drei treibende Kräfte konvergieren: AI-getriebene Innovation, ein stabileres Finanzierungsumfeld und wachsender Konsolidierungsdruck.

AI-Sicherheit dominiert den Cybersecurity-Markt Q1 2026

Das auffälligste Signal des Quartals kommt aus dem Segment AI Security. Mit 37 Finanzierungsrunden und einem Anteil von 46 % am gesamten investierten Kapital hat sich AI-Sicherheit als das beherrschende Investitionsthema etabliert. Auf der M&A-Seite verzeichnete das Segment 12 Transaktionen – mehr als im gesamten Jahr 2025. AI-Governance entwickelt sich laut dem Bericht zu einem eigenständigen Investmentthema, angetrieben durch die wachsenden Anforderungen an KI-Risikomanagement, die Steuerung autonomer Agenten und regulatorische Compliance.

Die Kapitalallokation folgt einer klaren Logik: Unternehmen setzen AI schneller ein, als ihre Sicherheitsarchitekturen mithalten können. Legacy-Lösungen bieten keine ausreichende Transparenz über das Verhalten von LLMs oder agentic AI. In diese Lücke stoßen spezialisierte Anbieter mit dezidiert AI.

Vier neue Unicorns und das Prinzip „weniger, aber größere Wetten”

Das Quartal brachte mindestens vier neue Cybersecurity-Unicorns hervor: Tenex.AI, Aikido, Torq und XBOW. Tenex.AI, unterstützt von a16z, schloss eine 250-Millionen-Dollar-Series-B bei einer Bewertung von einer Milliarde US-Dollar ab. Die Plattform verfolgt einen AI-nativen Ansatz für Managed Detection and Response. Insgesamt überschritten zehn Finanzierungsrunden die 100-Millionen-Dollar-Marke und kamen zusammen auf 1,8 Milliarden US-Dollar – deutlich über dem Quartalsdurchschnitt 2025 von sechs solcher Runden mit 1,5 Milliarden US-Dollar. Der Medianwert dieser Megarunden lag bei einer Bewertung von 1,85 Milliarden US-Dollar.

Allein am letzten Tag des Quartals, dem 31. März, wurden mindestens 380 Millionen US-Dollar über drei Series-B-Runden verteilt. Momentum-Cyber-CEO Eric McAlpine kommentierte, die Kluft zwischen kapitalstarken Marktführern und dem übrigen Feld werde „immer schärfer”. Unternehmen, die die frühe Seed-to-C-Welle nicht mitgenommen hätten, würden nun in einer Größenordnung finanziert, die echte Investorenüberzeugung widerspiegele.

Strategische Käufer bestimmen die M&A-Dynamik

Strategische Käufer dominierten das M&A-Geschehen und verantworteten 87 % des offengelegten Transaktionswerts im Cybersecurity-Markt Q1 2026. Den größten Einzelbeitrag leistete CrowdStrike mit zwei Akquisitionen: der Übernahme der Identity-Security-Plattform SGNL für 740 Millionen US-Dollar sowie des Browser-Sicherheitsanbieters Seraphic Security für einen nicht offiziell bestätigten Betrag, der laut Analysten bei rund 400 Millionen US-Dollar liegt. Beide Zukäufe erweitern die Falcon-Plattform um Browser-Runtime-Schutz und kontinuierliche Identitätsautorisierung – Fähigkeiten, die angesichts der Verbreitung von KI-Agenten im Unternehmenskontext strategisch zentral werden.

Private-Equity-Firmen waren ebenfalls aktiv und zeichneten für 45 % des Dealflows verantwortlich, verteilt auf 49 Transaktionen. Security Services blieb mit 44 Deals der volumenstärkste M&A-Sektor. Auf Jahresbasis hochgerechnet steuert 2026 auf 437 Transaktionen zu – deutlich über dem Rekordwert von 400 im Vorjahr.

Ausblick

Der Cybersecurity-Markt Q1 2026 bestätigt einen Trend, der sich seit 2025 abzeichnet: Kapital konzentriert sich zunehmend auf plattformfähige Unternehmen mit skalierbaren, AI-nativen Architekturen. Strategische Exits überwiegen weiterhin gegenüber IPOs, wobei Momentum Cyber innerhalb der nächsten 12 bis 18 Monate einen Landmark-Exit erwartet, der die Größenordnung der Wiz-Akquisition übertreffen könnte. Identity-Plattformen erzielen weiterhin Premiumbewertungen, und die Gravitationskraft der Hyperscaler zieht Security-Funktionalitäten immer tiefer in deren Ökosysteme.

Für CISOs, ISBs, ISOs und Entscheider in Unternehmen ergeben sich aus diesen Zahlen konkrete Implikationen. Das Vendor-Ökosystem fragmentiert und konsolidiert sich gleichzeitig, was eine sorgfältige Evaluierung von Produkt-Roadmaps und Integrationsstrategien erfordert. Die Dominanz von AI-Sicherheit als Investmentthema signalisiert, dass Unternehmen ihre Sicherheitsarchitekturen für AI-Workloads grundlegend überdenken müssen. Wer bei der Absicherung von AI-Agenten, -Modellen und -Datenflüssen nicht nachrüstet, riskiert Lücken, die konventionelle Tools nicht schließen können. Gleichzeitig verschärft der Kapitalfluss den Wettbewerb um spezialisierte Fachkräfte – insbesondere in den Bereichen Cloud Security, Identity Management und AI-Security-GRC.

Der Beitrag Cybersecurity-Markt Q1 2026 – Rekorddynamik bei Finanzierungen und M&A erschien zuerst auf Ilja Schlak InfoSec Blog.

Ein LiteLLM Supply-Chain-Angriff Report steht mit allen verifizierten IOCs, Prüfbefehlen und einem vierphasigen Incident-Response-Playbook zum Download bereit.

LiteLLM Supply-Chain-Angriff entstand über die Trivy-Kompromittierung

Der LiteLLM Supply-Chain-Angriff vom 24. März 2026 kompromittierte zwei PyPI-Versionen der beliebten Python-Bibliothek mit einem dreistufigen Credential-Stealer. Der Schadcode sammelte unter anderem SSH-Schlüssel, Cloud-Zugangsdaten, Kubernetes-Secrets und LLM-API-Keys, verschlüsselte sie und übermittelte sie an eine vom Angreifer kontrollierte Domain. Hinter dem Angriff steht nach übereinstimmender Einschätzung mehrerer Sicherheitsunternehmen dieselbe Gruppe, die wenige Tage zuvor bereits den Trivy-Scanner kompromittiert hatte.

LiteLLM ist eine Python-Bibliothek, die als einheitliche Schnittstelle zu über 100 KI-Modellanbietern dient. Sie wird täglich rund 3,4 Millionen Mal von PyPI heruntergeladen, wobei der Großteil auf automatisierte CI/CD-Läufe entfällt. Kursierende Opferzahlen in sechsstelliger Höhe sind bislang nicht belegt und sollten mit Vorsicht betrachtet werden.

Der Angriffsweg führte über die wenige Tage zuvor kompromittierte Trivy-CI/CD-Integration, die in diesem Beitrag ausführlich beschrieben wurde. LiteLLMs Build-Pipeline nutzte Trivy als Sicherheitsscanner und installierte es ohne Versions-Pinning. Die kompromittierte Trivy-Version exfiltrierte dabei ein PyPI-Publish-Token aus der GitHub-Actions-Umgebung. Mit diesem Token lud der Bedrohungsakteur TeamPCP zwei schadhafte Versionen direkt auf PyPI hoch, ohne den regulären GitHub-Release-Prozess zu durchlaufen. Zwei-Faktor-Authentifizierung war auf den Maintainer-Accounts aktiv, wurde aber durch das gestohlene API-Token umgangen. LiteLLMs CEO bestätigte diesen Ablauf öffentlich.

Wie der Schadcode in den kompromittierten Versionen funktioniert

Die am 24. März um 10:39 UTC veröffentlichte Version 1.82.7 enthielt zwölf Zeilen obfuszierten Base64-Code in der Datei proxy_server.py, der beim Import des LiteLLM-Proxy-Moduls ausgeführt wurde. Dreizehn Minuten später folgte Version 1.82.8 mit einem zusätzlichen, deutlich aggressiveren Vektor: einer .pth-Datei im Wheel-Root, die Python bei jedem Interpreter-Start automatisch verarbeitet. Damit genügte nicht der Import der Bibliothek, sondern jeder beliebige Python-Prozess in der betroffenen Umgebung löste den Schadcode aus – einschließlich pip, pytest oder dem Language-Server einer IDE. Ein Bug in dieser Implementierung erzeugte eine unkontrollierte Prozessvervielfachung, die zur RAM-Erschöpfung führte und dadurch die Entdeckung durch einen Entwickler bei FutureSearch auslöste.

Der Payload operierte in drei Stufen: Zunächst sammelte er systematisch Zugangsdaten vom Host, darunter SSH-Schlüssel, AWS-, GCP- und Azure-Credentials, Kubernetes-Konfigurationen, Datenbankpasswörter, Git-Credentials, Shell-Historien und Kryptowährungs-Wallets. Anschließend verschlüsselte er die gesammelten Daten mit AES-256-CBC und RSA-4096 und übermittelte sie an die C2-Domain models.litellm[.]cloud, die am Vortag registriert worden war. In einer dritten Stufe installierte der Schadcode eine persistente Backdoor unter ~/.config/sysmon/sysmon.py mit zugehörigem systemd-Service und versuchte in Kubernetes-Umgebungen, privilegierte Pods auf jedem Node zu deployen.

Wer vom LiteLLM Supply-Chain-Angriff betroffen sein kann

PyPI stellte das Paket gegen 13:38 UTC unter Quarantäne, die endgültige Löschung der kompromittierten Versionen erfolgte am Nachmittag. Das konservative Betroffenheitsfenster reicht damit von 10:39 bis etwa 15 Uhr UTC. Nicht betroffen waren laut offiziellem Statement Nutzer des LiteLLM-Docker-Images, der Cloud-Variante oder Installationen direkt aus dem GitHub-Repository. Potenziell betroffen ist dagegen jede Umgebung, die in diesem Zeitfenster eine ungepinnte pip-Installation von LiteLLM durchgeführt hat. Das schließt ausdrücklich transitive Installationen ein: Der Erstentdecker bei FutureSearch hatte LiteLLM nie bewusst installiert – es wurde durch ein Cursor-MCP-Plugin als Abhängigkeit mitgebracht.

Alle bisher dokumentierten IOCs und Persistenz-Mechanismen beziehen sich auf Linux-Systeme. Ob und wie der Schadcode auf Windows oder macOS wirkt, ist zum Zeitpunkt dieser Veröffentlichung nicht dokumentiert, wobei der .pth-Mechanismus selbst plattformübergreifend funktioniert.

Was Unternehmen jetzt tun sollten

Wer prüfen will, ob eigene Systeme betroffen sind, sollte auf allen Maschinen, CI/CD-Runnern und in Docker-Images pip show litellm ausführen und nach der Datei litellm_init.pth in den site-packages-Verzeichnissen suchen. Bei einem Fund der Versionen 1.82.7 oder 1.82.8 müssen sämtliche auf dem betroffenen System zugänglichen Credentials als kompromittiert behandelt und rotiert werden. Das betrifft SSH-Schlüssel, Cloud-Provider-Zugangsdaten, Kubernetes-Secrets, LLM-API-Keys, Datenbankpasswörter und CI/CD-Tokens gleichermaßen.

Dieser Vorfall ist Teil einer laufenden Kampagne, die nach übereinstimmender Einschätzung von Endor Labs, Snyk und Wiz bislang fünf Ökosysteme durchlaufen hat. Die operative Konsequenz geht deshalb über den Einzelfall hinaus: Dependencies pinnen, Publish-Tokens durch Trusted Publishing ersetzen, Egress-Monitoring für Entwicklerumgebungen einführen und CI/CD-Runner nicht länger als vertrauenswürdige Infrastruktur behandeln, sondern als das, was sie sind – potenziell exponierte Systeme.

Der Beitrag LiteLLM Supply-Chain-Angriff – PyPI-Pakete mit Credential-Stealer kompromittiert erschien zuerst auf Ilja Schlak InfoSec Blog.

Der Trivy Supply-Chain-Angriff traf Entwickler und CI/CD-Pipelines, weil Angreifer nach einer früheren Credential-Exfiltration in der Lieferkette blieben, am 19. März 2026 offizielle Tags und Releases umbogen und einen Infostealer vor dem eigentlichen Scan ausführen ließen. Damit wirkten kompromittierte Workflows auf den ersten Blick normal, obwohl Secrets bereits abgegriffen werden konnten.

Trivy Supply-Chain-Angriff trifft Releases, Actions und Vertrauenskette

Der Trivy Supply-Chain-Angriff entstand nicht durch eine gewöhnliche Schwachstelle, sondern durch die offizielle Lieferkette. Betroffen waren nicht nur einzelne Artefakte, sondern der Release trivy v0.69.4 sowie die beiden GitHub Actions aquasecurity/trivy-action und aquasecurity/setup-trivy. Risiko: Wer Trivy automatisiert in Build- und Scan-Strecken eingebunden hatte, konnte auf formal unveränderte Versionsangaben vertrauen und dennoch unbemerkt Schadcode ausführen.

Nach dem Sicherheits-Advisory von Aqua auf GitHub nutzte ein Angreifer am 19. März 2026 kompromittierte Zugangsdaten, um den offiziellen Release trivy v0.69.4 zu veröffentlichen, 76 von 77 Versions-Tags in trivy-action auf bösartige Commits umzubiegen und alle sieben Tags in setup-trivy zu ersetzen. Der besonders heikle Punkt liegt darin, dass nicht nur eine neue, verdächtige Version eingeschleust wurde. Die Täter schrieben bereits bekannte und in vielen Pipelines verwendete Tags um. Workflows, die auf @0.x.y vertrauten statt auf einen festen Commit-SHA, konnten so beim nächsten Lauf kompromittierten Code nachladen, ohne dass sich die Referenz im Workflow selbst sichtbar geändert hätte.

Wie der Trivy Supply-Chain-Angriff entstehen konnte

Die inzwischen wichtigste neue Erkenntnis ist, dass der Vorfall vom 19. März nicht aus dem Nichts kam. Laut dem aktuellen Lagebild von Aqua begann die Angriffskette bereits Ende Februar 2026. Damals nutzten Angreifer eine Fehlkonfiguration in Trivys GitHub-Actions-Umgebung aus, erbeuteten einen privilegierten Zugangstoken und verschafften sich damit Zugriff auf Automations- und Release-Prozesse. Aqua beschreibt diesen Ursprung bislang bewusst allgemein als Fehlkonfiguration. Sicherheitsanalysen aus der Community und von Incident-Response-Seite führen die erste Eintrittskette technischer auf ein riskantes pull_request_target-Szenario zurück, bei dem öffentliche Repositories extern ausgelöste Workflows mit erhöhten Rechten ausführen können.

Entscheidend für den späteren Schaden war anschließend die nicht vollständig abgeschlossene Bereinigung nach dem ersten Incident vom 1. März. Aqua schreibt offen, dass Secrets und Tokens zwar rotiert wurden, der Vorgang aber nicht atomar verlief. Genau daraus entstand ein mehrtägiges Fenster, in dem der bereits eingedrungene Angreifer neu ausgegebene oder noch nicht gleichzeitig widerrufene Zugangsdaten erneut erfassen konnte.

So lief die zweite Phase des Trivy Supply-Chain-Angriffs ab

Am 19. März nutzten die Täter diesen Restzugriff, um die offizielle Vertrauenskette direkt zu missbrauchen. Die auffällige Aktivität begann (GTM+1) gegen 18:43 Uhr mit den manipulierten Actions-Tags. Der kompromittierte Release trivy v0.69.4 war laut Aqua ungefähr zwischen 19:22 Uhr und 22:42 Uhr öffentlich erreichbar. Für setup-trivy endete das Expositionsfenster noch am selben Abend gegen 22:44 Uhr, während trivy-action bis zum 20. März gegen 06:40 Uhr betroffen blieb. Diese konkreten Zeitfenster sind operativ relevant, weil sich damit GitHub-Workflow-Runs, Artefakte und Runner-Logs sehr gezielt eingrenzen lassen.

Technisch lief der Angriff in mehreren Schritten. Beim Release von trivy v0.69.4 wurde ein manipulierter Commit so vorbereitet, dass statt des legitimen Codes ein schädlicher Bestandteil aus einer typosquatteten Domain nachgeladen werden konnte; zusätzlich wurde laut Advisory die Validierung in der Release-Kette umgangen. Noch gefährlicher war die Tag-Manipulation in den GitHub Actions. Dort genügte den Angreifern Schreibzugriff, um Tags per Force-Push auf andere Commits zeigen zu lassen. Genau diesen Mechanismus beschreibt auch eine technische Analyse von CrowdStrike: Git-Tags sind bequem, aber veränderlich. Das macht sie als Versionsanker für CI/CD bequem, aber aus Sicht der Lieferkettensicherheit angreifbar.

Warum Entwickler und Pipelines den Angriff kaum bemerkten

Die eingeschleuste Malware war so platziert, dass sie vor dem eigentlichen Trivy-Scan anlief. Das ist der Grund, warum viele betroffene Workflows äußerlich normal wirken konnten. Der Job lieferte weiterhin ein vermeintlich reguläres Scannergebnis, während im Hintergrund sensible Daten aus dem Runner-Speicher und dem Dateisystem gesammelt wurden. Aqua nennt unter anderem SSH-Schlüssel, AWS-, GCP- und Azure-Credentials, Kubernetes-Tokens, Docker-Konfigurationen, .env-Dateien, Git-Zugangsdaten und Datenbank-Credentials. Wer in diesem Fenster betroffen war, darf einen grünen Pipeline-Run deshalb nicht als Entwarnung missverstehen.

Hinzu kam ein Fallback für die Datenabfuhr. Wenn die direkte Exfiltration fehlschlug und ein geeignetes GitHub-Token vorhanden war, sollte die Malware nach Aquas Beschreibung ein öffentliches Repository namens tpcp-docs im Konto des Opfers anlegen und die gesammelten Daten dort als Release-Asset ablegen.

Im Rahmen der Vorfallsbehandlung sollten hier, GitHub-Audit-Logs, neu angelegte Repositories, Release-Artefakte und Bot-Aktivitäten in Organisationskonten untersucht werden.

Der Trivy Supply-Chain-Angriff endete nicht beim Secret-Diebstahl

Der Trivy-Vorfall endete nicht beim Diebstahl von CI/CD-Secrets. Nach aktuellen Analysen hinterließ die kompromittierte Angriffskette auf betroffenen Entwickler-Systemen und Runnern zusätzliche Persistenz, sodass das Risiko weit über den eigentlichen Pipeline-Run hinausging. CrowdStrike beschreibt, dass die Malware vor dem legitimen Trivy-Scan anlief und so unauffällig Credentials abgreifen konnte, während Aqua den Angriff als mehrstufige Kampagne einordnet, deren Ursprung bereits Ende Februar in einer Kompromittierung der GitHub-Actions-Umgebung lag.

Besonders brisant ist die zweite Eskalationsstufe: Die nachgelagerte Infrastruktur setzte laut den vorliegenden Analysen auf einen ICP-basierten Dead-Drop-Mechanismus, über den kompromittierte Systeme weitere Nutzlasten nachladen konnten. Parallel dazu sprang die Kampagne auf das npm-Ökosystem über: Wie The Hacker News unter Verweis auf technische Analysen berichtet, wurden im Rahmen des sogenannten CanisterWorm mindestens 47 npm-Pakete kompromittiert; deren postinstall-Hooks suchten nach Tokens, luden weitere Schadkomponenten nach und nutzten kompromittierte Publisher-Rechte zur weiteren Verbreitung. Damit wurde aus einem Supply-Chain-Angriff auf Trivy eine deutlich breitere, sich fortpflanzende Ökosystem-Bedrohung.

Welche Versionen betroffen waren und was jetzt als sicher gilt

Als kompromittiert gelten trivy v0.69.4, bei trivy-action alle Tags von 0.0.1 bis 0.34.2 und bei setup-trivy sämtliche Tags von v0.2.0 bis v0.2.6. Als sichere Zielstände nennt Aqua trivy v0.69.3, trivy-action 0.35.0 und setup-trivy 0.2.6. Nicht betroffen waren Umgebungen, die Container per Digest statt per Tag bezogen oder GitHub Actions bereits auf volle Commit-SHAs gepinnt hatten.

Trivy Supply-Chain-Angriff – Lessons Learned

Die operative Sofortmaßnahme bleibt eindeutig: jede Pipeline, die in den genannten Zeitfenstern eine betroffene Version ausgeführt hat, sollte als potenziell kompromittiert behandelt werden. Das bedeutet Secret-Rotation ohne Ausnahme, inklusive Cloud-Keys, Registry-Tokens, Deploy-Schlüsseln, GitHub-Tokens und aller weiteren Zugangsdaten, die auf Runnern verfügbar waren. Bei Self-hosted Runnern reicht das reine Update ohnehin nicht aus, weil dort zusätzliche lokale Dateien und Zugangsinformationen abgegriffen worden sein können.

Strategisch ist der Fall ebenso unangenehm wie lehrreich. Ein Sicherheitswerkzeug wurde selbst zum Verteilkanal eines Infostealers, weil ein früher gestohlener Token, eine unvollständige Bereinigung und das Vertrauen auf mutable Tags zusammenkamen. Der Trivy Supply-Chain-Angriff zeigt damit exemplarisch, dass moderne Software-Lieferketten nicht nur auf Schwachstellen geprüft, sondern gegen Missbrauch der eigenen Automationsrechte gehärtet werden müssen. Wer daraus nur die Lesson „auf die nächste saubere Version aktualisieren“ zieht, greift zu kurz. Die eigentliche Konsequenz: GitHub Actions auf Commit-SHAs pinnen, Token-Rechte drastisch reduzieren, Rotationen vollständig und gleichzeitig durchführen und CI/CD-Runner wie kritische Produktionssysteme überwachen.

Die oft genannte Zuordnung zu TeamPCP bleibt dabei ein Nebenaspekt. Für die Verteidigung ist im Moment wichtiger, dass Ursache, Ablauf und betroffene Versionen inzwischen belastbar beschrieben sind. Der Fall ist vor allem deshalb bemerkenswert, weil er zeigt, wie schnell ein Angriff auf die Build- und Release-Ebene aus einem Sicherheitswerkzeug selbst ein Risiko für Entwickler, Organisationen und nachgelagerte Lieferketten macht.

Der Beitrag Trivy Supply-Chain-Angriff erklärt Ursache, Ablauf und Folgen für CI/CD erschien zuerst auf Ilja Schlak InfoSec Blog.

IT-Sicherheitsmarkt 2026 bestätigt die strategische Bedeutung von Cybersicherheit

Die aktuellen Zahlen aus Australien und der jüngste belastbare Vergleichspunkt für Deutschland zeigen nicht in erster Linie zwei Märkte im Wettbewerb, sondern dieselbe Entwicklung in zwei unterschiedlichen Wirtschaftsräumen: Cybersicherheit und Informationssicherheit werden in Unternehmen sichtbar wichtiger. Gartner erwartet für Australien 2026 Informationssicherheitsausgaben von 7,5 Milliarden AU$ und damit ein Wachstum von 9,5 % gegenüber 2025. Für Deutschland liegt die jüngste öffentlich verfügbare Prognose von Bitkom auf Basis von PAC bei 12,2 Milliarden Euro für 2026, was einem Plus von 9,9 % entspricht.

Gartner bestätigt nicht nur steigende Budgets, sondern auch eine Veränderung in der Investitionslogik. Security Services bleiben dort der größte Ausgabenblock, Security Software wächst am stärksten. Das ist ein typisches Signal für einen Markt, in dem Sicherheit nicht mehr punktuell als Produktkauf verstanden wird, sondern als dauerhafte betriebliche Fähigkeit. Unternehmen investieren parallel in Technologie, in operative Unterstützung und in zusätzliche Resilienz. Die Bitkom-Prognose zeigt mit fast identischer Wachstumsdynamik, dass sich dieselbe Entwicklung auch hierzulande beobachten lässt.

IT-Sicherheitsmarkt 2026 signalisiert einen Reifeprozess

Der IT-Sicherheitsmarkt 2026 wächst nicht bloß, weil mehr Sicherheitsprodukte nachgefragt werden. Er wächst, weil in den Unternehmen ein Reifeprozess stattfindet. Cyberrisiken werden zunehmend nicht mehr als isoliertes IT-Problem, sondern als Geschäftsrisiko verstanden. Wer Cybersecurity ein eine technische Disziplin ansieht, diskutiert über Tools, Architekturen und Maßnahmen. Wer sie strategisch und somit richtig liest, spricht über Geschäftskontinuität, Vertrauensschutz, regulatorische Belastbarkeit, Reputation, Wettbewerbsfähigkeit, Betriebsfähigkeit und unternehmerische Handlungsfähigkeit in einer Notfall- oder Krisensituation.

Dass dieses Verständnis zunimmt, ist kein abstrakter Eindruck, sondern lässt sich an der Struktur der Ausgaben ablesen. In Australien wächst Security Software überdurchschnittlich stark, weil AI, Daten- und Anwendungsschutz sowie Infrastruktursicherheit zusätzliche Investitionen erzwingen. Gleichzeitig bleiben Security Services dominant, weil die Umsetzung komplexer wird und interne Teams die wachsende operative Last oft nicht allein tragen können. Deutschland zeigt ein sehr ähnliches Muster aus starkem Softwarewachstum und hohem Dienstleistungsanteil. Diese Konstellation ist typisch für einen Markt, in dem Sicherheit in die operative Realität der Unternehmen hineinwächst.

Bedrohungslage entscheidet und lenkt

Die wichtigste Ursache dieser Entwicklung ist weiterhin die Bedrohungslage. Unternehmen haben in den vergangenen Jahren gelernt, dass Cybervorfälle nicht mehr auf technische Störungen begrenzt bleiben. Sie treffen Prozesse, Lieferketten, Serviceverfügbarkeit, Kommunikation, Haftungsfragen und in vielen Fällen auch die Vertrauensbasis gegenüber Kunden und Partnern. Gerade deshalb verändert sich die Bewertung von Sicherheit auch im Management. Cybersecurity wird dort ernster genommen, wo Vorfälle nicht mehr als Sonderfälle erscheinen, sondern als realistische Belastung für den laufenden Betrieb.

Diese Sicht wird auch institutionell gestützt. Gartner verweist in seinen Top Cybersecurity Trends für 2026 auf die Kombination aus beschleunigter Bedrohungslage, regulatorischer Volatilität, geopolitischen Spannungen und dem starken Einfluss von AI. Das BSI wiederum hält in seiner Lageeinschätzung fest, dass die IT-Sicherheitslage in Deutschland weiterhin angespannt bleibt. Wer digitale Prozesse, Cloud-Plattformen, Identitäten, Datenströme und AI-nahe Anwendungen in kritischer Abhängigkeit betreibt, kann die Business-Resilienz nicht mehr gewährleisten.

Regulierung erhöht die Verbindlichkeit

Der regulatorische Druck ist dabei ein wesentlicher Katalysator, aber nicht die alleinige Ursache der Entwicklung. Er sorgt vor allem dafür, dass Sicherheitsfragen verbindlicher, dokumentierbarer und gegenüber Vorstand, Aufsicht und Prüfern nachvollziehbarer werden. Sicherheitsmaßnahmen konkurrieren dann nicht mehr nur mit anderen IT-Projekten, sondern werden Teil von Governance, Risiko- und Compliance-Architekturen. Dadurch verschiebt sich der Stellenwert von Cybersecurity in Richtung unternehmerischer Governance.

Wo Nachweisfähigkeit, Resilienz und organisatorische Reaktionsfähigkeit wichtiger werden, steigt automatisch die Nachfrage nach Dienstleistungen, Beratung, Managed Services und strukturierten Sicherheitsprogrammen. Die Unternehmen investieren also nicht nur in mehr Schutz, sondern in belastbarere Sicherheitsorganisationen.

AI und Fachkräftemangel verschärfen den Handlungsdruck

Hinzu kommt ein zweiter struktureller, ja gar disruptiver Treiber: AI. Sie erzeugt auf der einen Seite neue Produktivitätspotenziale, auf der anderen Seite aber auch neue Angriffsflächen, neue Governance-Anforderungen und zusätzliche Anforderungen an Datenschutz, Zugriffskontrolle und Überwachung. Der IT-Sicherheitsmarkt 2026 wächst deshalb auch deshalb, weil Unternehmen AI absichern müssen, während Sicherheitsanbieter selbst AI in Erkennung, Analyse und Reaktion integrieren. Sicherheit wird dadurch technischer, schneller und gleichzeitig anspruchsvoller in der Steuerung. Interessante Tendenz: AWS ersetzt die AI durch Senior Engineers.

Der Fachkräftemangel verstärkt diesen Effekt zusätzlich. Viele Unternehmen wissen inzwischen, dass sie Cybersecurity strategisch ernster nehmen müssen. Gleichzeitig fehlt häufig die personelle Tiefe, um neue Sicherheitsanforderungen intern vollständig zu bewältigen. Genau deshalb bleibt der Service-Anteil hoch. Externe Expertise wird dort nahezu unverzichtbar, wo Sicherheitsarchitekturen, Monitoring, Incident Response und Governance parallel professionalisiert werden müssen.

Neues Verständnis der Cyberbedrohungen?

Die aktuellen Zahlen aus Australien und Deutschland sind damit vor allem als Indikatoren zu lesen. Sie belegen, dass sich das Verständnis für die Bedeutung von Cybersecurity verbreitert und vertieft. Zu verzeichnen ist erkennbare Prioritätenverschiebung. Unternehmen behandeln Informationssicherheit zunehmend als Voraussetzung für Stabilität, Regelkonformität, wettbewerbsfördernde Reputation und belastbare Digitalisierung.

Die Sicherheit in der unternehmerischen Realität muss zwingend anders verstanden werden als noch vor wenigen Jahren. Die Bedrohungslage ist konkreter, die regulatorischen Erwartungen sind höher, AI vergrößert die Komplexität, und die wirtschaftlichen Folgen unzureichender Absicherung sind sichtbarer geworden.

Der Beitrag IT-Sicherheitsmarkt 2026 zeigt, warum Cybersicherheit wichtiger wird erschien zuerst auf Ilja Schlak InfoSec Blog.

Amazon AWS AI-Ausfälle zeigen die Grenzen reiner Automatisierung

Die Diskussion über AI im Engineering wird bei Amazon und AWS inzwischen deutlich nüchterner geführt. Es geht nicht mehr um die einfache Frage, ob AI Entwicklern hilft. Das ist längst klar. Geklärt sollte jedoch, wo die AI Grenzen in hochkritischen Umgebungen liegen. Gerade dort, wo Produktionssysteme, Zugriffsrechte, interne Dokumentation und komplexe Abhängigkeiten ineinandergreifen, wird sichtbar, warum Unternehmen trotz wachsender Automatisierung wieder stärker auf menschliche Erfahrung setzen.

Ausgangspunkt der Debatte sind mehrere Vorfälle, die intern und öffentlich für Aufmerksamkeit sorgten. Im Dezember 2025 kam es bei AWS zu Problemen rund um Cost Explorer. Wie Reuters unter Berufung auf die Financial Times berichtete, stand ein internes AI-Werkzeug im Zusammenhang mit einer längeren Störung. Amazon widersprach der zugespitzten Darstellung später öffentlich und erklärte in einer Korrektur, es habe sich nicht um einen großflächigen AWS-Ausfall gehandelt, sondern um einen einzelnen Dienst in einer Region. Ursache sei ein fehlkonfigurierter Zugriff gewesen, nicht schlicht ein „AI-Fehler“. Für die Einordnung ist jedoch weniger die Kommunikationslinie entscheidend als das Grundmuster: Ein AI-gestützter Prozess traf auf unzureichend eingegrenzte Rechte und schwache Schutzmechanismen.

Ein zweiter Vorfall verschärfte diese Diskussion Anfang März 2026. Bei Amazon.com kam es zu einem Ausfall, von dem unter anderem Produktseiten, Checkout und Kontodaten betroffen waren. Amazon sprach gegenüber Reuters von einem Problem im Zusammenhang mit einem Software-Code-Deployment. Die Plattform Downdetector registrierte in den USA in der Spitze rund 22.000 Meldungen. In einer späteren Korrektur erklärte Amazon dann, nur einer der jüngeren Vorfälle habe AI-Tooling überhaupt berührt. In diesem Fall habe ein Engineer unzutreffende Hinweise befolgt, die ein AI-System aus einem veralteten internen Wiki abgeleitet habe. Auch das ist aufschlussreich. Denn es zeigt, dass das Problem nicht zwingend darin lag, dass die AI eigenständig schädlichen Code erzeugte. Kritisch war eher das Zusammenspiel aus fehleranfälliger Wissensbasis, operativer Nähe zur Produktion und fehlender menschlicher Kontrolle (Stichwort “Human-in-the-Loop”) an der richtigen Stelle.

Warum Amazon AWS AI-Ausfälle Senior Engineers wieder wichtiger machen

In komplexen Plattformumgebungen reicht es nicht, dass eine Änderung auf dem Papier sinnvoll wirkt. Entscheidend ist die Einschätzung des sogenannten Blast Radius, also der Frage, welche Folgewirkungen ein Eingriff in angrenzenden Systemen, Berechtigungen, Deployments, Abhängigkeiten und Rollback-Prozessen auslösen kann. Diese Fähigkeit entsteht nicht allein durch technisches Wissen, sondern vor allem durch Erfahrung mit realen Produktionssystemen, historischen Incidents und organisatorischen Schwachstellen.

Das erklärt, warum Unternehmen wie Amazon in kritischen Pfaden wieder stärker auf Senior-Sign-off, Peer Review, Humans-in-the-Loop und zusätzliche Freigaben setzen. Denn AI arbeitet zwar schnell, aber sie gewichtet Risiken nicht automatisch so, wie es ein erfahrener Engineer, aufgrund seiner Arbeits- und auch Lebenserfahrung in einer produktiven Cloud-Umgebung tun muss. AI kann Muster erkennen, Vorschläge formulieren und Routinearbeiten beschleunigen. Was ihr fehlt, ist belastbares Urteil in Situationen, in denen unvollständige Informationen, widersprüchliche Dokumentation oder ungewöhnliche Systemzustände zusammentreffen!

Seit Oktober 2025 summierten sich die angekündigten Stellenstreichungen bei AWS laut Reuters auf rund 30.000 Corporate-Jobs, also fast zehn Prozent der Corporate-Belegschaft. Parallel dazu wurden AI-gestützte Werkzeuge und agentische Systeme offensiver in Entwicklungs- und Betriebsprozesse eingebunden. Diese Kombination erhöht zwar das Tempo, sie kann aber zugleich institutionelles Gedächtnis ausdünnen. Gerade Senior Engineers fangen diese Lücke auf, weil sie nicht nur den aktuellen Änderungsvorschlag bewerten, sondern auch die Geschichte der Plattform, bekannte Schwachstellen und wiederkehrende Fehlermuster im Blick behalten.

Warum reine AI-Automatisierung bei AWS nicht genügt

Die Lessons-Learned lauten, dass reine AI-Automatisierung in sicherheitskritischen Umgebungen nicht ausreicht. Ein System kann Vorschläge generieren, Dateien ändern, Kommandos ausführen und Workflows beschleunigen. Doch sobald Kontext veraltet, Rechte zu weit gefasst oder Sicherheitsgrenzen unscharf definiert sind, steigt das Risiko sprunghaft an. Die AI ist zwar nützlich, schnell und teils günstiger, es bleibt jedoch “nur” ein Werkzeug, nur ein Tool.

Ein AI-Tool mit weitreichenden Berechtigungen kann Fehlentscheidungen nicht nur empfehlen, sondern unter Umständen direkt operationalisieren. Wenn ein Modell auf veraltete interne Dokumentation zugreift oder fehlerhafte Zusammenhänge aus Wissensquellen ableitet, entsteht eine neue Klasse operativer Informationssicherheitsrisiken. Dazu zählen Fehlkonfigurationen, unsaubere Rechtevergabe, problematische Infrastrukturänderungen und im ungünstigsten Fall auch Sicherheitslücken, die sich über CI/CD-Prozesse oder interne Verwaltungswerkzeuge weiter ausbreiten.

AWS selbst beschreibt in seiner DevOps-Guidance seit Langem Prinzipien wie Peer Review, Separation of Duties und kontrollierte Freigaben für produktionsnahe Änderungen. Genau diese Mechanismen wirken nun wieder wie eine Rückkehr zu den Basics. Und diese Basics sind und bleiben noch für lange Zeit: Least Privilege, Mehr-Augen-Prinzip, nachvollziehbare Freigaben und klare Verantwortungsketten.

Der Beitrag Amazon AWS AI-Ausfälle zeigen, warum Senior Engineers wieder unverzichtbar sind erschien zuerst auf Ilja Schlak InfoSec Blog.

Cyberangriffe auf deutsche Unternehmen steigen weiter

Im Februar 2026 registrierte Check Point in Deutschland durchschnittlich 1.345 Cyberangriffe pro Organisation und Woche. Weltweit lag der Wert bei 2.086, in Europa bei 1.764 Angriffen pro Woche. Gegenüber dem Vorjahresmonat stieg das Angriffsvolumen in Deutschland um 11 Prozent, in Europa ebenfalls um 11 Prozent. In Deutschland gehörten Energie und Versorger, Bildung, Bau und Ingenieurwesen, Telekommunikation sowie Medien und Unterhaltung zu den am stärksten betroffenen Bereichen. Damit lag Deutschland zwar unter dem globalen Durchschnitt, folgte aber demselben Aufwärtstrend wie der europäische Gesamtmarkt.

Cyberangriffe auf deutsche Unternehmen treffen mehrere Branchen gleichzeitig

Besonders auffällig ist, welche Branchen in Deutschland laut Check Point vorne liegen. Im Februar standen Energie- und Versorgungsunternehmen, Bildung, Bauwesen und Ingenieurwesen, Telekommunikation sowie Medien und Unterhaltung an der Spitze. International bleibt der Bildungssektor sogar der am stärksten attackierte Bereich. Das passt zu einem Muster, das sich schon länger beobachten lässt: Angreifer suchen sich Umgebungen, in denen Verfügbarkeit kritisch ist, viele Nutzerkonten existieren oder die Sicherheitsorganisation nicht mit der Digitalisierung Schritt hält.

Das ist für deutsche Unternehmen relevant, weil sich hinter den 1.345 Angriffen pro Woche keine abstrakte Statistik verbirgt. Solche Volumina erhöhen die Wahrscheinlichkeit, dass einzelne Phishing-Kampagnen, Zugangsdatenmissbrauch, Schadsoftware, DDoS-Angriffe oder Vorstufen von Ransomware irgendwann durchrutschen. Je höher die Taktzahl, desto eher treffen auch mittelständische Organisationen, die sich selbst nicht als prominentes Ziel verstehen, auf Angreifer mit industriellem Vorgehen.

Warum der Abstand zum Weltwert trügt

Auf den ersten Blick könnte man argumentieren, dass Deutschland mit 1345 Angriffen pro Woche deutlich unter dem weltweiten Durchschnitt von 2086 liegt und somit vergleichsweise besser dasteht. Diese Lesart greift jedoch zu kurz. Erstens meldet Check Point für Europa im Februar 1764 Angriffe pro Organisation und Woche, was ebenfalls einem Plus von 11% entspricht. Zweitens sagt der Abstand zum globalen Mittelwert wenig über die reale Gefährdung eines einzelnen Betriebs aus. Telemetriedaten hängen nämlich auch von Branchenschwerpunkten, Sichtbarkeit, Sensorik und der regionalen Zusammensetzung der gemessenen Organisationen ab. Für die operative Praxis zählt vor allem, dass das Niveau hoch bleibt und die Kurve nicht deutlich nach unten zeigt.

Diese Einordnung stützen auch offizielle und behördliche Quellen in Deutschland. Der BSI-Lagebericht 2025 beschreibt die IT-Sicherheitslage weiterhin als angespannt. Die Richtung ist also klar: es gibt mehr Angriffsfläche, mehr Schwachstellen und mehr professionell organisierte Angriffe.. Ergänzend zeigt die Bitkom-Studie Wirtschaftsschutz 2025, wie hart diese Entwicklung wirtschaftlich einschlägt. 87% der Unternehmen berichten dort von Angriffen oder vermuten solche, der Gesamtschaden liegt bei 289,2 Milliarden Euro, davon 70% durch Cyberattacken.

Neue Risiken durch KI und alte Probleme bei Ransomware

Interessant an der Februar-Auswertung ist außerdem, dass der generelle Angriffsdruck hoch bleibt, obwohl die weltweit veröffentlichten Ransomware-Fälle im Jahresvergleich zurückgingen. Check Point verweist hier auf einen Basiseffekt durch eine besonders große Clop-Kampagne im Vorjahr. Ohne diesen Sondereffekt bleibt Ransomware strukturell ein dominantes Risiko. Unternehmen sollten also nicht den Fehler machen, sinkende Ransomware-Zahlen als Zeichen einer Entspannung zu lesen.

Gleichzeitig verschiebt sich der Fokus. Check Point warnt im selben Bericht vor anhaltenden Risiken rund um GenAI-Nutzung in Unternehmen. Der Punkt ist sicherheitspolitisch wichtig. Wenn Mitarbeitende sensible Inhalte in viele unterschiedliche AI-Werkzeuge eingeben, entstehen zusätzliche Datenabfluss- und Governance-Risiken. Für Cyberangriffe auf deutsche Unternehmen heißt das: die klassische Angriffsoberfläche wächst nicht nur durch ungepatchte Systeme oder schwache Zugangsdaten, sondern zunehmend auch durch unkontrollierte AI-Prozesse im Arbeitsalltag.

Was ist also zu tun

Cyberangriffe auf deutsche Unternehmen lassen sich bei diesem Volumen nur abfedern, wenn Identitäten besser geschützt, Zugriffe segmentiert, Backups belastbar getestet und verdächtige Aktivitäten schneller erkannt werden. Dazu kommen saubere E-Mail-Sicherheit, gehärtete Remote-Zugänge und klare Regeln für den Umgang mit GenAI-Tools. Gerade mittelständische Unternehmen unterschätzen noch immer, wie stark sich alltägliche Prozesslücken mit professionell skalierten Angriffsketten verbinden lassen.

11% Plus im Februar 2026 bedeuten nicht nur mehr Alarmmeldungen in Security-Tools. Sie bedeuten höhere Eintrittswahrscheinlichkeit, mehr operative Belastung und wachsenden Entscheidungsdruck in den Unternehmen. Wer Cybersicherheit noch immer als reines IT-Thema behandelt, versteht diese Entwicklung nicht.

Der Beitrag Cyberangriffe auf deutsche Unternehmen steigen auf 1.345 pro Woche erschien zuerst auf Ilja Schlak InfoSec Blog.

ENFORCERS Projekt soll Europas Industrie-Software widerstandsfähiger machen

Mit ENFORCERS ist ein europäisches Forschungs- und Innovationsprojekt gestartet, das ein Problem adressiert, das viele Hersteller und Betreiber industrieller Systeme beschäftigt, nämlich der Lifecycle der industriellen Software. der der Automatisierungssoftware soll nämlich nicht mit dem Rollout enden. Es muss ein Lifecycle zur Pflege, Optimierung sowie für Patch- und Update-Zyklen der Software etabliert werden. Darüber hinaus muss auch der Krisenfall berücksichtigt werden. In OT-Umgebungen, die segmentiert, heterogen oder nur teilweise vernetzt sind, ist es oft ein Drahtseilakt für Betreiber. Genau soll das Projekt helfen. Laut der offiziellen Projektankündigung von WIBU-SYSTEMS soll über drei Jahre hinweg die Kooperation zwischen Industrie, Cybersecurity-Anbietern und Forschung ausgebaut werden, damit Sicherheitsvorfälle, Schwachstellenmanagement, Zertifizierung und sichere Software-Verteilung nicht länger in Silos gedacht werden.

ENFORCERS Projekt und die Relevanz für OT-Umgebungen, KRITIS und Industrie

Die eigentliche Stärke des ENFORCERS Projektes liegt im Fokus auf industrielle Software und Automatisierung. In klassischen IT-Landschaften lassen sich Patches, Telemetrie und Incident Response häufig zentral ausrollen. In Fertigung, industrieller Vernetzung und OT sieht die Realität oft anders aus. Die OT- und ICS-Systeme haben sehr lange Lebensdauer, dürfen nicht ohne Weiteres – z.B. für Wartung –  gestoppt werden und hängen in Netzen, die bewusst abgeschottet oder nur eingeschränkt erreichbar sind. Das ENFORCERS Projekt soll die Lücke schließen zwischen Erkennung eines Vorfalls, koordinierter Reaktion, vertrauenswürdiger Absicherung und sicherer Wiederverteilung von Software in industriellen Umgebungen.

ENFORCERS Projekt verbindet Incident Response, Zertifizierung und sichere Updates

Die Initiatoren beschreiben das Vorhaben als eine Cybersecurity-Systemplattform, die mehrere vertrauenswürdige Instanzen zu einem abgesicherten Systemverbund zusammenführt. Genannt werden private Security Operations Centers, die Vorfalls- und Schwachstellendaten sammeln, korrelieren und klassifizieren, dazu Secure Elements als Vertrauensanker an OT-Rändern und Gateways, automatisierte Playbooks für Schwachstellenbehebung, Zertifizierung und sichere Software-Updates sowie Mechanismen für den grenzüberschreitenden Datenaustausch unter Wahrung von Datensouveränität.

Es ist ein positive Entwicklung, denn heutzutage bedeutet Supply-Chain-Sicherheit längst nicht mehr nur die Herkunft von Komponenten. Es geht ebenso um die sichere Verteilung von Updates, die Vertrauenswürdigkeit von Build- und Signaturprozessen, die Nachvollziehbarkeit von Schwachstellen und die Frage, wie schnell ein Vorfall aus einem Partnernetz in koordinierte Gegenmaßnahmen übersetzt werden kann. ENFORCERS versucht, diese Themen in einem gemeinsamen Rahmen zu verbinden, statt sie auf einzelne Produkte, Teams oder Ländergrenzen zu verteilen.

Dass dabei nicht nur Cybersecurity-Anbieter, sondern auch Industrieunternehmen beteiligt sind, ist ein wichtiger Punkt. Koordiniert wird das Projekt von WIBU-SYSTEMS. Zum Konsortium gehören laut den veröffentlichten Angaben unter anderem Balluff, Schneider Electric, TTTech Computertechnik, Technology Nexus Secured Business Solutions, Infineon Technologies, Langlauf Security Automation, DYNAMIKI, AITAD und ResilTech; Fraunhofer SIT unterstützt als Forschungspartner, VDMA bringt den industriellen Netzwerk- und Policy-Bezug ein. Das spricht dafür, dass ENFORCERS nicht nur im Labor funktionieren soll, sondern mit realen Anforderungen aus Automatisierung, Fertigung und industrieller Vernetzung abgeglichen wird.

Neue EU-Vorgaben geben dem ENFORCERS Projekt zusätzlichen Druck

Besonders relevant wird das Vorhaben durch den Regulierungsrahmen der EU. Die Projektverantwortlichen ordnen ENFORCERS selbst ausdrücklich in den Kontext von NIS2 und Cyber Resilience Act ein. Der NIS2-Rahmen der EU verpflichtet Mitgliedstaaten und betroffene Unternehmen zu einem höheren Reifegrad bei Risikomanagement, Meldung erheblicher Vorfälle, Kooperation und Lieferkettensicherheit.

Parallel erhöht der Cyber Resilience Act den Druck auf Hersteller digitaler Produkte, Sicherheit nicht mehr nur beim Markteintritt, sondern über den gesamten Lebenszyklus hinweg nachzuweisen. Gerade für industrielle Software und vernetzte Automatisierungskomponenten ist das ein Einschnitt. Künftige Anforderungen an sichere Voreinstellungen, Schwachstellenmanagement, Update-Prozesse und Meldepflichten greifen deutlich tiefer in Entwicklungs- und Betriebsabläufe ein, als es viele Marktteilnehmer bislang gewohnt waren.

Der Zeitplan

Der operative Startpunkt lag laut den veröffentlichten Projektangaben im Kick-off am 10. und 11. Februar 2026 in Karlsruhe. Die Pressemitteilung zum offiziellen Start folgte am 11. März 2026. In der frühen Projektphase stehen zunächst rechtliche und technische Anforderungen, die Architektur des Systems sowie erste SOC- und Plattformkomponenten im Vordergrund. Demonstratoren und Validierung sind für spätere Phasen vorgesehen. Das ist für ein dreijähriges EU-Projekt ein typischer Verlauf, zeigt aber auch: Wer jetzt auf marktreife Ergebnisse hofft, wird sich gedulden müssen.

Dennoch ist der Start des Projekts aus Branchensicht bemerkenswert. Während viele Debatten über industrielle Cybersecurity noch zwischen Produkt-Compliance, Incident Response, Supply-Chain-Risiken und digitaler Souveränität pendeln, versucht ENFORCERS, genau diese Linien zusammenzuführen. Ob daraus am Ende ein übertragbares Modell für verschiedene Sektoren entsteht, wird sich erst mit den angekündigten Demonstratoren und Best Practices zeigen. Schon jetzt ist aber klar, dass das Projekt ein Thema aufgreift, das mit den neuen EU-Regeln eher mehr an Bedeutung gewinnen wird.

Der Beitrag ENFORCERS Projekt stärkt Cybersicherheit für industrielle Software in Europa erschien zuerst auf Ilja Schlak InfoSec Blog.

Veeam Backup Sicherheitslücken in Version 12 und 13 im Detail

Veeam hat mehrere gravierende Schwachstellen in Backup & Replication geschlossen, die sich sauber nach den betroffenen Hauptversionen 12 und 13 aufdröseln lassen. Besonders kritisch ist, dass es nicht nur um klassische Remote-Code-Ausführung auf dem Backup-Server geht, sondern auch um einen Fall mit der Rolle Backup Viewer, um manipulierte Dateien in Repositories, um auslesbare SSH-Zugangsdaten und um lokale Rechteausweitung auf Windows-basierten Systemen. Laut Veeam für Version 12, Veeam für Version 13 und der BSI-Warnung ist der Fall bereits als kritisch einzuordnen; die aktuelle Veeam-Build-Übersicht führt die gefixten Stände seit 13. März 2026 als aktuelle Builds.

Betroffen sind in der 12er-Linie die Version 12.3.2.4165 und ältere Version-12-Builds, in der 13er-Linie die Version 13.0.1.1071 und ältere Version-13-Builds. Gefixt wurde laut Hersteller ab 12.3.2.4465 beziehungsweise 13.0.1.2067. Für Leser ist dabei vor allem eine Unterscheidung wichtig: Manche Schwachstellen setzen einen authentifizierten Domain-Benutzer voraus, andere einen bereits vorhandenen Rollenzugang innerhalb der Backup-Umgebung, wieder andere einen lokalen Zugriff auf Windows-Systeme. Das macht die Gesamtlage so unangenehm, weil in realen Netzen genau solche abgestuften Rechteprofile häufig bereits vorhanden oder nach einem ersten Einbruch schnell erreichbar sind.

Veeam Backup Sicherheitslücken in Version 12

In Version 12 liegt der Schwerpunkt auf mehreren kritischen Angriffswegen gegen den Backup-Server selbst sowie auf einem besonders unangenehmen Fall gegen Repositories und einer lokalen Privilegieneskalation auf Windows-basierten Servern.

• CVE-2026-21666 – CVSS 9.9
  Diese Schwachstelle erlaubt einem authentifizierten Domain-Benutzer Remote Code Execution auf dem Backup-Server. Das macht sie so kritisch, weil kein lokaler Zugriff nötig ist und ein bereits vorhandenes Domänenkonto ausreichen kann, um direkt den zentralen Backup-Knoten anzugreifen. Sobald der Backup-Server im Fokus steht, geht es nicht mehr nur um einzelne Jobs, sondern potenziell um die gesamte Sicherungs- und Wiederherstellungslogik.
• CVE-2026-21667 – CVSS 9.9
  Auch hier geht es um Remote Code Execution durch einen authentifizierten Domain-Benutzer auf dem Backup-Server. Der Fall ist operational deshalb brisant, weil er in der Wirkung praktisch dieselbe Alarmstufe erreicht wie CVE-2026-21666: Angreifer brauchen keine Volladministration, sondern „nur“ einen passenden authentifizierten Zugang im Domänenkontext. Für Verteidiger heißt das, dass klassische Netzgrenzen allein hier nicht als Beruhigung taugen.
• CVE-2026-21668 – CVSS 8.8
  Diese Schwachstelle erlaubt es einem authentifizierten Domain-Benutzer, Restriktionen zu umgehen und beliebige Dateien auf einem Backup-Repository zu manipulieren. Genau das macht den Bug so gefährlich: Es geht nicht primär um sofortige Codeausführung, sondern um die Integrität der Backups. Wer Dateien in einem Repository manipulieren kann, greift damit im Kern die Vertrauensbasis der Wiederherstellung an.
• CVE-2026-21672 – CVSS 8.8
  Hier handelt es sich um eine lokale Rechteausweitung auf Windows-basierten Veeam-Servern. Solche Bugs wirken auf den ersten Blick weniger spektakulär als eine Netzwerk-RCE, sind aber in teilkompromittierten Umgebungen enorm wertvoll. Wer bereits einen begrenzten Fuß auf einem System hat, kann daraus erhöhte Rechte machen und den nächsten Schritt zur vollständigen Übernahme vorbereiten.
• CVE-2026-21708 – CVSS 9.9
  Diese Schwachstelle erlaubt einem Backup Viewer Remote Code Execution als postgres-Benutzer. Genau dieser Punkt sticht heraus: Nicht eine klassische Administratorrolle, sondern eine vermeintlich kleinere Rolle kann hier zum Einfallstor werden. Das ist der eigentliche Kern des Problems, weil viele Unternehmen Viewer-Rollen eher für Kontrolle, Reporting oder Audit-Zwecke vergeben und ihr Risiko damit leicht unterschätzen.

Veeam Backup Sicherheitslücken in Version 13

In Version 13 ist die Lage ähnlich kritisch, zugleich aber etwas breiter gestreut. Neben RCE auf dem Backup-Server tauchen hier noch der Diebstahl gespeicherter SSH-Zugangsdaten sowie ein gesonderter Fall für HA-Deployments der Veeam Software Appliance auf.

• CVE-2026-21669 – CVSS 9.9
  Ein authentifizierter Domain-Benutzer kann Remote Code Execution auf dem Backup-Server erreichen. Das ist die direkte Parallele zu den kritischsten v12-Fällen. Besonders heikel ist daran, dass der Angriff gegen den zentralen Orchestrierungspunkt der Datensicherung läuft und dadurch nicht nur Daten, sondern auch Wiederherstellungsprozesse gefährdet werden.
• CVE-2026-21670 – CVSS 7.7
  Diese Schwachstelle erlaubt es einem niedrig privilegierten Benutzer, gespeicherte SSH-Credentials auszulesen. Der Score liegt unter den 9.x-Fällen, der praktische Wert für Angreifer bleibt aber hoch. Zugangsdaten sind in Backup-Umgebungen oft der Hebel für Seitwärtsbewegungen, für den Zugriff auf Repositories oder für den Sprung in weitere Infrastruktursegmente.
• CVE-2026-21671 – CVSS 9.1
  Hier kann ein authentifizierter Benutzer mit der Rolle Backup Administrator in High-Availability-Deployments der Veeam Software Appliance Code ausführen. Das macht die Schwachstelle besonders, weil sie nicht pauschal jede Installation trifft, sondern gezielt HA-Szenarien. Wer diese Betriebsform nutzt, muss den Fall deshalb nicht nur als generischen Patch, sondern als potenziell geschäftskritische Konfigurationsfrage behandeln.
• CVE-2026-21672 – CVSS 8.8
  Wie in Version 12 geht es um lokale Rechteausweitung auf Windows-basierten Veeam-Servern. Gerade in Kettenangriffen ist so ein Bug wertvoll, weil er aus einer begrenzten Präsenz auf dem System schnell eine höher privilegierte Position machen kann.
• CVE-2026-21708 – CVSS 9.9
  Auch in Version 13 kann ein Backup Viewer Remote Code Execution als postgres-Benutzer auslösen. Für die Priorisierung ist das einer der wichtigsten Punkte überhaupt. Die Schwachstelle zeigt, dass nicht nur klassische Admin-Rollen neu bewertet werden müssen, sondern auch Rollen, die in vielen Umgebungen routinemäßig mit weniger Skepsis vergeben wurden.

Kritikalität der dieser Schwachstellen

Die eigentliche Message hinter dieser Schwachstellenserie lautet nicht nur „hohe Scores“, sondern „mehrere realistische Angriffswege gegen Backup-Infrastruktur“. In Version 12 dominieren die unmittelbaren RCE- und Repository-Risiken, in Version 13 kommt zusätzlich der Appliance- und Credential-Aspekt stärker zum Tragen. Für Patch- und Change-Teams ist genau diese Trennung nützlich, weil sie daraus sofort Maßnahmen ableiten können: Windows-basierte Backup-Server priorisieren, HA-Appliance-Deployments gesondert prüfen, Rollen wie Backup Viewer und Backup Administrator neu bewerten und gespeicherte SSH-Zugangsdaten nach dem Update möglichst rotieren.

Wer Veeam Backup & Replication in Version 12 oder 13 betreibt, sollte nicht nur patchen, sondern gleichzeitig die Rechtevergabe, den Netzwerkzugang zum Backup-Server und den Schutz der Repositories überprüfen. Genau dort entscheidet sich, ob aus einer kritischen Sicherheitsmeldung nur ein administrativer Aufwand wird oder ein echter Resilienz-Fall.

Der Beitrag Veeam Backup Sicherheitslücken in Version 12 und 13 mit CVE- und CVSS-Übersicht erschien zuerst auf Ilja Schlak InfoSec Blog.

5G-Angriffe mit KI in O-RAN-Netzen erkennen

Die University of Surrey hat am 10. März 2026 eine Forschungsarbeit zu einem AI-basierten Verteidigungsansatz für 5G-Netze vorgestellt. Nach Angaben der Hochschule erkannte und blockierte das Framework TwinGuard in zwei Testumgebungen komplexe Angriffe in unter 100 Millisekunden! Im Mittelpunkt stehen dabei Handover-Flooding und E2-Subscription-Flooding, also Angriffe auf Steuerungs- und Signalisierungsprozesse in offenen Mobilfunkarchitekturen. Für die Sicherheitsbewertung ist vor allem relevant, dass die Meldung keine neue Schwachstelle mit CVE-Kennung beschreibt, sondern einen Abwehrmechanismus, der in Forschungsumgebungen überprüft wurde.

TwinGuard kombiniert einen digitalen Zwilling des Netzes mit Reinforcement Learning. Der digitale Zwilling bildet den Zustand der Infrastruktur laufend nach und wird laut den aktuellen Quellen in sehr kurzen Intervallen aktualisiert. Auf dieser Basis soll das System normales Verhalten vom verdächtigen Verhalten unterscheiden und Gegenmaßnahmen auslösen, bevor ein Angriff den Netzbetrieb stärker beeinträchtigt. Der Ansatz zielt damit auf ein Problem, das mit O-RAN und virtualisierten Netzkernen an Bedeutung gewinnt: Je offener und modularer 5G-Architekturen werden, desto größer wird auch die Angriffsfläche an Schnittstellen, Controllern und softwaredefinierten Komponenten.

5G-Angriffe mit KI in zwei Testumgebungen

Die Forscher testeten TwinGuard in zwei unterschiedlichen 5G-Szenarien. Das erste war ein simuliertes Multi-Cell-O-RAN-Setup mit mehreren Funkzellen. Das zweite war ein vollständig virtualisierter 5G-Core auf Basis von OpenAirInterface, der über FlexRIC gesteuert wurde. In beiden Umgebungen soll das System Angriffe in weniger als 100 Millisekunden erkannt und blockiert haben. Beim Handover-Flooding wird die Mobilitätssteuerung durch eine große Zahl manipulierter oder provozierter Übergabeereignisse belastet. Beim E2-Subscription-Flooding wird der Controller mit Anfragen überlastet, um die reguläre Steuerung zu stören. Nach Darstellung der Universität geht es damit ausdrücklich um Angriffe auf die Control Plane und nicht um klassische Schwachstellenmeldungen aus Endgeräten oder Basisstations-Firmware.

Für die Einordnung ist dieser Punkt wichtig, weil aktuelle Schlagzeilen schnell den Eindruck eines unmittelbar einsatzbereiten Schutzprodukts erzeugen. TwinGuard ist derzeit jedoch (noch!) ein wissenschaftlich publizierter Verteidigungsansatz, der in realitätsnahen 5G-Testumgebungen validiert wurde. Ebenso wenig nennen die aktuellen Quellen Hinweise auf eine laufende Ausnutzung dieser beiden Angriffsszenarien in öffentlichen Mobilfunknetzen. Der Exploit-Status bleibt daher auf das beschriebene Forschungsszenario begrenzt.

Wann wäre die Technologie einsatzbereit?

Die aktuellen Quellen nennen keine Kennzahlen zum Dauerbetrieb in produktiven Carrier-Umgebungen. Es fehlen belastbare Angaben zu Fehlalarmen, Ressourcenbedarf, Durchsatz unter Last, Integration in bestehende O-RAN-Deployments und Interoperabilität mit herstellerspezifischen Implementierungen. Auch Aussagen zu regulatorischen oder betrieblichen Anforderungen an den sicheren Einsatz eines digitalen Zwillings im Live-Betrieb bleiben in den frischen Veröffentlichungen offen.

Einordnung für 5G- und 6G-Sicherheit

Der sicherheitstechnische Wert der Arbeit liegt vor allem in der Reaktionszeit und im verhaltensbasierten Ansatz. Klassische Systeme arbeiten häufig signatur- oder regelbasiert und reagieren erst dann zuverlässig, wenn ein Angriffsmuster bekannt ist. TwinGuard soll dagegen Abweichungen vom Normalzustand schon während ihres Verlaufs erkennen. In offenen 5G-Netzen mit vielen softwarebasierten Komponenten ist das grundsätzlich plausibel, weil Angriffe dort nicht immer mit den bekannten Mustern klassischer IT-Umgebungen übereinstimmen. Aus Sicht der Forschung ist die Arbeit daher relevant, weil sie zeigt, dass AI-gestützte Abwehr nicht nur für nachgelagerte Analyse, sondern auch für sehr schnelle Gegenmaßnahmen in der Netzsteuerung gedacht werden kann.

Die aktuellen Veröffentlichungen nennen als nächsten Schritt größere Multi-Cell-Umgebungen. Das deutet darauf hin, dass die Autoren selbst noch nicht von einem abgeschlossenen Übergang in produktive Netze ausgehen. Es gibt derzeit auch keine Herstellerhinweise, dass TwinGuard bereits in kommerzielle O-RAN- oder 5G-Core-Produkte übernommen wurde. Als Mitigation lässt sich daher nur der allgemeine Forschungsansatz benennen: digitale Zwillinge plus Reinforcement Learning zur frühen Erkennung und Blockierung auffälliger Control-Plane-Aktivitäten.

Der Beitrag 5G-Angriffe mit KI erkennen – TwinGuard testet Abwehr in O-RAN und 5G-Core erschien zuerst auf Ilja Schlak InfoSec Blog.