Wenn AI-Velocity Security-Governance überholt: Tenable Report zeigt 18% überprivilegierte AI-Service-Rollen

Der Tenable Cloud and AI Security Risk Report 2026 dokumentiert ein Phänomen, das viele Security-Teams nur zu gut kennen: Engineering Velocity überholt Security Governance. Das Resultat ist eine systemische Exposure-Schicht, die sich durch alle Cloud-Ebenen zieht – von überprivilegierten IAM-Rollen für AI-Services (18% der Organisationen) über 86% mit kritischen Supply-Chain-Schwachstellen bis zu 82%, die bekannte exploitierte CVEs in Production betreiben. Der Report liefert nicht nur erschreckende Zahlen, sondern auch eine klare Diagnose: Das Problem ist nicht fehlende Tools, sondern fehlendes Governance-Framework für eine Welt, in der AI-Tools mit Geschwindigkeit deployed werden, die klassische Control-Prozesse überfordert.

Die vier Pfeiler der Cloud-Exposure: Ein konvergierender Angriffspfad

Tenable Research analysierte zwischen April und Oktober 2025 diverse Cloud-Umgebungen (AWS, Azure, GCP) mit Fokus auf vier zentrale Risiko-Vektoren. Die Befunde zeigen: Diese Risiken existieren nicht isoliert – sie bilden einen einheitlichen Exposure-Path, der AI-Velocity als Einstiegspunkt, Supply Chain als Entry-Vector, Identity-Dormancy als Lateral-Movement-Layer und Unpatched-Workloads als Final-Target nutzt.

1. AI Services Governance Gap: 18% überprivilegierte Rollen für sofortigen Zugriff

Kernproblem: 18% der Organisationen, die AWS-AI-Services wie Amazon SageMaker oder Amazon Bedrock nutzen, haben IAM-Rollen mit kritischen oder hohen Excessive Permissions konfiguriert, die diese Services sofort annehmen können – ohne weitere Authentifizierung oder Genehmigung.

Detailbefunde:

• 13% halten kritische Permissions (z.B. Admin-Zugriff, Daten-Exfiltration)
• 8% halten hohe Permissions (z.B. Modify-Access, Cross-Account-Assume)
• 73% der Default-Execution-Rollen für SageMaker sind inaktiv (dormant identities)
• 70% der Default-Execution-Rollen für Bedrock sind inaktiv
• 3% exponieren AI-API-Keys (OpenAI, Anthropic, Google) direkt in Cloud-Storage (S3, Blob Storage)

Warum ist das kritisch?
AI-Services wie SageMaker oder Bedrock werden oft mit breiten Permissions deployed, um "schnell zu starten" – eine klassische DevOps-Praxis. Das Problem: Diese Rollen bleiben nach dem Deployment aktiv, oft mit Full-Admin-Access zu S3-Buckets, Datenbanken oder anderen Services. Ein kompromittierter AI-Workload oder ein malicious Model kann diese Permissions sofort nutzen, um Lateral Movement durchzuführen oder Daten zu exfiltrieren.

Beispiel-Szenario:
Ein ML-Engineer erstellt eine SageMaker-Notebook-Instance mit Admin-Access zu allen S3-Buckets, um "schnell Daten zu explorieren". Nach Projektabschluss wird die Instance deaktiviert, aber die IAM-Rolle bleibt aktiv. Sechs Monate später kompromittiert ein Angreifer die (inaktive) Role via exposed AWS-Keys in einem GitHub-Repo – und hat sofortigen Admin-Zugriff auf alle S3-Buckets.

2. Supply Chain Exposure: 86% mit kritischen Vulnerabilities in Third-Party-Paketen

Kernproblem: 86% aller Organisationen haben Third-Party-Code-Pakete (npm, PyPI, Maven, etc.) mit kritischen Schwachstellen installiert. Jede achte Organisation (13%) hat mindestens ein kompromittiertes Paket deployed – d.h. ein Paket mit History of Malicious Code Injection oder Backdoors.

Externe Access-Risiken:

• 53% erlauben externen Accounts, kritische Excessive Permissions anzunehmen
• 14% exponieren über 75% ihrer Cloud-Ressourcen an externe Accounts
• 5% haben bereits Guest- oder External-Usern in Entra ID/GCP kritische Permissions erteilt

Warum ist das kritisch?
Supply-Chain-Angriffe wie SolarWinds (2020) oder die npm-Package-Kompromittierungen (2021-2023) haben gezeigt: Ein einziger kompromittierter Vendor oder ein malicious Package kann Tausende von Downstream-Organisationen betreffen. Der Tenable-Befund zeigt: Die Exposure ist nicht kleiner geworden – sie ist strukturell geworden.

Real-World-Case:
Tenable Research identifizierte zwei konkrete Supply-Chain-Angriffe in den analysierten Umgebungen:

1. Shai-Hulud (Python-Paket): Ein kompromittiertes Python-Paket, das Environment-Variables ausliest und an einen C2-Server sendet. Betroffen waren 7% der analysierten Python-Workloads.
2. s1ngularity (npm-Paket): Ein npm-Paket mit Backdoor-Funktionalität, das SSH-Keys und AWS-Credentials exfiltriert. Betroffen waren 4% der Node.js-Workloads.

Beide Pakete waren für mehrere Monate in Production, bevor sie entdeckt wurden – ein klarer Indikator für fehlendes Continuous Monitoring.

3. Identity & Credentials Risk: 49% dormant Admin-Identitäten

Kernproblem: Im Durchschnitt sind 49% aller Identitäten mit kritischen Permissions (Admin-Rechte, Escalation-Capabilities) seit 90+ Tagen inaktiv. Diese "dormant identities" schaffen eine massive, unnötige Attack Surface.

Detailbefunde:

• 52% der Non-Human-Identitäten (Service Accounts, ML/AI-Services, Automation) halten kritische Permissions
• 37% der Human-Identitäten halten kritische Permissions
• 65% exponieren High-Value-Assets durch "vergessene" Cloud-Credentials (ungenutzte oder nicht rotierte Keys)
• 17% haben solche Keys mit administrativen Privileges verknüpft – ein statischer Vektor für Major Identity Compromise

Warum ist das kritisch?
Least Privilege ist ein Grundprinzip von Security-by-Design – aber in der Praxis wird es oft ignoriert. DevOps-Teams erstellen Service Accounts mit breiten Permissions, um "schnell zu deployen", und vergessen dann, diese nach Projektabschluss zu deprovisionen. Das Resultat: Eine wachsende Sammlung von dormant Identities, die nur darauf warten, kompromittiert zu werden.

Ghost Secrets:
Tenable identifiziert einen besonders kritischen Sub-Case: "Ghost Secrets" – vergessene Credentials (AWS Access Keys, Azure Service Principal Secrets, GCP Service Account Keys), die mit überprivilegierten Identitäten verknüpft sind. 17% der Organisationen haben solche Keys mit Admin-Privileges – oft hardcoded in alten Config-Files, CI/CD-Pipelines oder Developer-Laptops.

4. Workload Exposure: 82% betreiben bekannte exploitierte CVEs

Kernproblem: 82% der Organisationen betreiben Cloud-Workloads mit bekannten, exploitierten kritischen CVEs – d.h. Vulnerabilities, die aktiv von Threat Actors genutzt werden und für die Exploits öffentlich verfügbar sind.

Lifecycle-Risiko:

• 57% betreiben Systeme at or near End-of-Life (EoL), die keine Security-Updates mehr erhalten
• React2Shell: Tenable analysierte die "Time-to-Patch"-Metrik für kritische RCE-Vulnerabilities und fand: Durchschnitt 45 Tage zwischen CVE-Publication und Patch-Deployment – lange genug für Automated Exploitation

Warum ist das kritisch?
Die Kombination aus Known Exploited Vulnerabilities (KEV) und EoL-Systemen schafft ein "Sitting Duck"-Szenario: Workloads, die für automatisierte Angriffe offen stehen, ohne Möglichkeit zur Remediation. Die CISA KEV-Katalog listet aktuell über 1.100 CVEs, die aktiv exploitiert werden – und 82% der Organisationen betreiben mindestens eine davon.

Beispiel-Cases:

• Log4Shell (CVE-2021-44228): Über 18 Monate nach Disclosure noch in 23% der analysierten Java-Workloads gefunden
• ProxyShell (CVE-2021-34473): Exchange-Server-RCE, noch in 15% der On-Prem-Exchange-Instances aktiv
• Spring4Shell (CVE-2022-22965): Spring Framework RCE, in 12% der Spring-Boot-Applikationen gefunden

Der AI-MCP-Faktor: Neue Backbone, neue Risiken

Ein besonders interessanter Befund: 70% der Organisationen haben mindestens ein AI- oder Model Context Protocol (MCP) Third-Party-Paket integriert. MCP ist eine neue Architektur-Schicht, die AI-Agents ermöglicht, mit externen Datenquellen und Tools zu interagieren – ähnlich wie APIs, aber mit direktem Access zu lokalen Daten.

Das Problem: MCP-Packages werden oft von Community-Entwicklern bereitgestellt und unterliegen keiner zentralen Security-Review. Tenable fand mehrere MCP-Packages mit:

• Unverschlüsselter Credential-Übertragung
• Fehlenden Input-Validations (SQL-Injection-Risiko)
• Overprivileged File-System-Access

Investment-Implikation: MCP ist der "neue CORS" – eine Architektur-Schicht, die Convenience über Security stellt und wahrscheinlich in 2-3 Jahren zu Major Breaches führen wird.

Mitigation Strategies: Von Reactive zu Proactive

Tenable empfiehlt einen fundamentalen Shift von reaktivem Patching zu proaktivem Exposure Management:

AI Governance Framework

1. IAM-Role-Audits: Regelmäßige Reviews aller IAM-Rollen, die AI-Services annehmen können
2. Least-Privilege-by-Default: Keine Default-Admin-Rollen für AI-Workloads
3. API-Key-Rotation: Automatisierte Rotation alle 30-60 Tage
4. Secrets-Scanning: Continuous Monitoring von Cloud-Storage für exposed Keys

Supply Chain Visibility

1. SBOM-basierte Scans: Software Bill of Materials für alle Third-Party-Pakete
2. Dependency-Pinning: Keine Wildcard-Versions in Package-Manifests
3. External-Account-Reviews: Vierteljährliche Audits aller externen Assume-Role-Permissions
4. Vendor-Security-Questionnaires: Strikte Due-Diligence für neue Vendors

Identity Hygiene

1. 90-Tage-Inaktivitäts-Reviews: Automatisierte Deprovisioning-Workflows
2. Non-Human-Identity-Audits: Monatliche Reviews aller Service Accounts
3. Credential-Rotation-Policies: Mandatory Rotation alle 60-90 Tage
4. Ghost-Secrets-Detection: Secrets-Scanning in Git-Repos, Config-Files, CI/CD

Workload Hardening

1. KEV-Priorisierung: CISA Known Exploited Vulnerabilities als Patch-Priority
2. EoL-Lifecycle-Management: Mandatory Upgrades oder Decommissioning
3. Attack-Path-Analysis: Identifikation von High-Risk-Workloads mit Lateral-Movement-Potential
4. Continuous Vulnerability Scanning: Shift-Left-Ansatz mit Pre-Production-Scans

Fazit: Governance-Gap als strukturelles Risiko

Der Tenable Report diagnostiziert nicht nur technische Schwachstellen, sondern ein strukturelles Governance-Problem: Engineering-Teams deployen mit Geschwindigkeit, die klassische Security-Controls überfordert. Das Resultat ist eine systemische Exposure-Schicht, die von AI-Velocity über Supply-Chain-Kompromittierung bis zu dormant Identities und unpatched Workloads reicht.

Die Lösung ist nicht "mehr Tools", sondern bessere Prozesse: Least-Privilege-by-Default, Continuous Monitoring, automatisierte Deprovisioning, und – vor allem – eine Kultur, die Security nicht als Blocker, sondern als Enabler versteht.

Für Security-Teams bedeutet der Report: Proaktive Exposure Management wird zur Pflichtausstattung. Reaktives Patching reicht nicht mehr – die Attack Surface ist zu groß, die Time-to-Exploit zu kurz, und die Blast Radius zu verheerend.

Tenable liefert die Daten. Die Frage ist: Wer handelt?

Quelle: Tenable Cloud and AI Security Risk Report 2026 (Analyse April-Oktober 2025, AI-Findings bis Dezember 2025)

Relevante Ticker: $TENB, $CRWD, $PANW, $ZS, $GOOGL, $MSFT, $AMZN