Infrastructure as CodeScanning.
IaC-Scanner prüfen Terraform, CloudFormation, Kubernetes-Manifeste und weitere Infrastrukturdefinitionen vor dem Deployment auf Fehlkonfigurationen und Policy-Verstösse. Sie bewerten den Code und teilweise den Plan. Ob die produktive Cloud später davon abweicht, zeigt erst ein Abgleich mit dem tatsächlichen Zustand.
Marktbild: hohe Priorität in automatisierten Cloud-Umgebungen. Der Markt ist breit und durch Open Source, AppSec-Plattformen und CNAPPs stark fragmentiert. Der Vergleich umfasst elf Werkzeuge und Plattformen.
Fehler vor dem Apply stoppen.
IaC-Scanning erkennt offene Netzregeln, unverschlüsselte Ressourcen, riskante Identitäten und fehlende Schutzfunktionen im Pull Request. Gute Ergebnisse zeigen Datei, Ressource, Regel, Begründung und eine umsetzbare Korrektur.
Prüfe Quellcode, Module, Variablen und wenn möglich den erzeugten Plan. Dynamisch gebildete Werte, externe Module und manuelle Änderungen in der Cloud können der statischen Analyse entgehen.
Der Fehler steht schon im Code.
Infrastructure as Code (IaC) beschreibt Netze, Server, Datenbanken, Rollen und Cluster als Textdateien: Terraform oder OpenTofu in HCL, CloudFormation in YAML oder JSON, ARM und Bicep für Azure, Kubernetes-Manifeste und Helm-Charts. Ein IaC-Scanner liest diese Dateien, bevor sie angewendet werden, und vergleicht jede beschriebene Ressource mit Regeln: Ist der Speicher verschlüsselt, steht eine Sicherheitsgruppe für 0.0.0.0/0 offen, erhält ein Container Root-Rechte? Der Befund nennt Datei, Zeile, Ressource und Regel, sodass die Korrektur dort erfolgt, wo der Fehler entsteht.[1,2]
Die Regeln sind selbst Code. Open-Source-Werkzeuge wie Checkov liefern Python- und YAML-Richtlinien, Trivy und KICS nutzen Rego, die Sprache von Open Policy Agent (OPA), und Conftest wendet eigene Rego-Regeln auf beliebige Konfigurationsdateien an. Einfache Regeln prüfen ein Attribut, graphbasierte Regeln prüfen Beziehungen, etwa ob eine Datenbank nur über ein bestimmtes Netz erreichbar ist. Eine wichtige Variante ist der Plan-Scan: Statt der Vorlage mit Variablen und Modulen prüft der Scanner den von Terraform berechneten Plan, in dem die tatsächlichen Werte stehen.[3,4,5,6,7]
Eingesetzt wird die Prüfung an mehreren Stellen: in der Entwicklungsumgebung beim Schreiben, als Pre-Commit-Hook, im Pull Request und als Pflichtschritt in der Pipeline, der einen Build bei kritischen Befunden anhält. Architektonisch gibt es zwei Varianten. Im ersten Fall läuft der Scanner als Kommandozeilenwerkzeug oder Container im eigenen Pipeline-Runner, und Quelltext wie Befunde bleiben in der eigenen Umgebung. Im zweiten Fall liest eine SaaS-Plattform die Repositories über eine Integration der Quellcodeverwaltung, sammelt die Befunde vieler Teams zentral, verwaltet Ausnahmen und Nachweise und verknüpft sie mit der laufenden Cloud.[8,9,10]
Der statische Scan sieht nur, was im Repository steht. Wer eine Ressource später von Hand in der Konsole ändert, erzeugt Drift: Code und Wirklichkeit laufen auseinander. Drift-Erkennung vergleicht deshalb State oder Code mit dem tatsächlichen Cloud-Zustand und meldet geänderte oder gar nicht verwaltete Ressourcen. Code-zu-Cloud-Funktionen gehen den umgekehrten Weg und führen einen Befund in der Cloud auf die Vorlage zurück, die ihn verursacht hat.[11,12]
Typische Probleme
| Problem | Wie man es löst |
|---|---|
| Vorlage geprüft, Plan nicht | Variablen, Module und berechnete Werte zeigen sich erst im Plan. Lösung: zusätzlich den erzeugten Terraform-Plan scannen.[7] |
| Lücken bei Ressourcentypen | Ein Scanner meldet nur, wofür er Regeln hat; seltene Provider und private Modulregister fallen durch. Lösung: Abdeckung je Provider im Pilot prüfen und fehlende Regeln selbst schreiben.[9] |
| Globale Unterdrückung | Teams schalten störende Regeln ganz ab. Lösung: Ausnahmen pro Ressource, mit Begründung, Verantwortlichem und Ablaufdatum. |
| Drift ausserhalb des Repositorys | Manuelle Änderungen in der Konsole umgehen jede Code-Prüfung. Lösung: regelmässige Drift-Erkennung und Schreibrechte in der Konsole beschränken.[11] |
| Der Scanner als Angriffsweg | Am 19.03.2026 veröffentlichte ein Angreifer mit kompromittierten Zugangsdaten manipulierte Versionen des Open-Source-Scanners Trivy und der zugehörigen GitHub Actions; Pipelines mit beweglichen Versions-Tags luden den Schadcode. In den Tagen danach folgten weitere manipulierte Container-Images, zudem war die GitHub Action des Open-Source-Scanners KICS betroffen. Lösung: Werkzeuge und Actions auf Commit-Hashes oder geprüfte Versionen festlegen.[14] |
| Verwaiste Projekte | Auch verbreitete Scanner werden eingestellt, Terrascan wurde am 20.11.2025 archiviert. Lösung: Pflegezustand und Ablöseplan Teil der Werkzeugwahl machen.[15] |
Auswahlfragen
| Frage | Worauf die Antwort hinweisen sollte |
|---|---|
| Welche IaC-Formate und Provider nutzen wir wirklich? | Die Antwort sollte eine Liste mit Terraform-Providern, Kubernetes, Cloud-Vorlagen und Modulquellen sein, gegen die jeder Kandidat im Pilot getestet wird. |
| Prüft das Werkzeug den Plan oder nur die Quelltexte? | Hinweis auf echte Plan-Unterstützung, sonst bleiben berechnete Werte unsichtbar. |
| Wie schreiben und testen wir eigene Regeln? | Die Antwort sollte eine Richtliniensprache nennen, die sich versionieren und automatisiert testen lässt. |
| Wie werden Ausnahmen verwaltet und nachgewiesen? | Erwartet werden ressourcengenaue, befristete Ausnahmen mit Begründung und Bericht für Audit und Revision. |
| Erkennt das Werkzeug Drift oder führt es Cloud-Befunde zum Code zurück? | Ohne diesen Abgleich braucht es einen zweiten Prozess für die laufende Umgebung. |
| Wie gelangt der Scanner in die Pipeline, und wer pflegt ihn? | Die Antwort sollte feste Versionen, signierte Artefakte und einen aktiven Pflegezustand belegen. |
| Wo werden Quelltext und Befunde verarbeitet? | Lokal laufende Scanner halten den Code im Haus, SaaS-Plattformen brauchen eine geklärte Datenregion. |
Betrieb und Verantwortung
Das Plattform- oder DevOps-Team betreibt den Scanner und die Pipeline-Integration, die Security-Architektur legt Regelwerk und Schwellen fest. Befunde korrigieren die Teams, die den Code besitzen; Ausnahmen genehmigt eine benannte Stelle. Sinnvolle Kennzahlen sind Anteil der Repositories mit Pflichtprüfung, offene kritische Befunde, Zahl und Alter der Ausnahmen sowie erkannte Drift-Fälle pro Monat.
Regulatorischer Bezug
ISO/IEC 27001:2022 adressiert das Thema in Annex A vor allem über 8.9 «Configuration management», 8.25 «Secure development life cycle» und 8.32 «Change management». NIS2 verlangt in Art. 21 Abs. 2 Bst. e Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen; DORA fordert in Art. 9 Abs. 4 Bst. e dokumentierte Verfahren für das IKT-Änderungsmanagement, damit Änderungen erfasst, getestet, freigegeben und überprüft werden. Im IT-Grundschutz sind die Bausteine CON.8 «Software-Entwicklung», OPS.1.1.3 «Patch- und Änderungsmanagement» und OPS.2.2 «Cloud-Nutzung» einschlägig.[16,17,18,19,20,21]
Quellen: [1] checkov.io · [2] aikido.dev · [3] checkov.io · [4] trivy.dev · [5] docs.kics.io · [6] conftest.dev · [7] checkov.io · [8] docs.kics.io · [9] docs.gitlab.com · [10] cortex-docs.paloaltonetworks.com · [11] developer.hashicorp.com · [12] docs.snyk.io · [13] developer.hashicorp.com · [14] aquasec.com · [15] github.com · [16] isms.online · [17] isms.online · [18] isms.online · [19] nis-2-directive.com · [20] digital-operational-resilience-act.com · [21] bsi.bund.de
Vierzehn Werkzeuge im Vergleich.
IaC-Scanner gibt es in drei Formen: als frei nutzbare Kommandozeilenwerkzeuge mit offenem Regelwerk, als Funktion von Entwickler- und DevSecOps-Plattformen und als Code-Modul einer CNAPP, die Befunde aus dem Repository mit der laufenden Cloud verknüpft. Mehrere kommerzielle Produkte bauen auf offenen Engines auf: GitLab nutzt KICS, Microsoft Security DevOps bindet Checkov, Terrascan, Trivy und Template Analyzer ein, Checkov wird von Prisma Cloud gepflegt. Der Markt konsolidiert: Palo Alto Networks hat Cortex Cloud am 13.02.2025 als nächste Version von Prisma Cloud vorgestellt (Prisma Cloud mit Cortex CDR zusammengeführt), Google hat die Übernahme von Wiz am 11.03.2026 abgeschlossen, IBM jene von HashiCorp am 27.02.2025. Im Open-Source-Lager bündelt Aqua Security die Terraform-Prüfung von tfsec in Trivy, und Tenable hat Terrascan am 20.11.2025 archiviert. Drift-Erkennung, also der Abgleich mit dem tatsächlichen Cloud-Zustand, liefern vor allem Plattformen mit Cloud-Anbindung und Terraform-Betriebsdienste.
Terraform: Terraform · Kubernetes: Kubernetes-Manifeste/Helm · CFN/ARM/Bicep: CloudFormation, ARM oder Bicep · CI/CD: CI/CD-Integration · IDE: IDE-Integration · Drift: Drift-Erkennung · Open Source: Open Source. ● = auf offizieller Hersteller- oder Projektseite beschrieben, – = nicht belegt (nicht zwingend nicht vorhanden). Auswahl nicht abschliessend, keine Rangliste. Stand: Oktober 2026.
Checkov
Prisma Cloud / Palo Alto Networks (Open-Source-Projekt)
Terraform inklusive Plan und OpenTofu, CloudFormation, AWS SAM, ARM, Bicep, Kubernetes, Helm, Kustomize, Dockerfile, Serverless und Ansible, dazu Workflow-Dateien von GitHub Actions, GitLab CI und weiteren CI-Systemen.
Statische Analyse der Konfigurationsdateien; für zusammengesetzte Richtlinien baut Checkov einen Verbindungsgraphen der Ressourcen. Eigene Richtlinien entstehen in Python oder YAML.
Mitgelieferte Prüfungen orientieren sich unter anderem an CIS-Benchmarks; der Plan-Scan bewertet die von Terraform berechneten Werte statt nur der Quelltexte.
Dokumentierte Einbindung in Jenkins, GitHub Actions, GitLab CI, Bitbucket Pipelines und Pre-Commit-Hooks; in VS Code über die Erweiterung von Prisma Cloud nutzbar.
Läuft lokal als Kommandozeilenwerkzeug oder Container, Quelltext und Befunde bleiben in der eigenen Umgebung; das Projekt wird von Prisma Cloud gepflegt.
Prüfschritt in der Pipeline, der Pull Requests mit Fehlkonfigurationen markiert oder den Build anhält.
Breite Formatabdeckung und graphbasierte Richtlinien in einem frei nutzbaren Werkzeug.
Den Abgleich mit der laufenden Cloud und die Drift-Erkennung liefert erst die kommerzielle Plattform von Palo Alto Networks.
Trivy (Misconfiguration Scanning)
Aqua Security (Open-Source-Projekt)
Der Befehl trivy config prüft Terraform, CloudFormation, ARM-Vorlagen, Helm-Charts, Kubernetes-Manifeste und Dockerfiles; derselbe Scanner prüft auch Images, Abhängigkeiten und Secrets.
Mitgelieferte Prüfungen erkennen Fehlkonfigurationen in den Dateien; eigene Prüfungen werden in Rego geschrieben, der Richtliniensprache von Open Policy Agent.
Die Terraform-Prüfung stammt aus tfsec, dessen Weiterentwicklung Aqua Security in Trivy gebündelt hat.
Offizielle GitHub Action, Kubernetes-Operator und VS-Code-Erweiterung.
Läuft lokal als Binary oder Container; am 19.03.2026 wurden mit kompromittierten Zugangsdaten manipulierte Versionen von Trivy, trivy-action und setup-trivy veröffentlicht und bis zum 20.03.2026 entfernt, am 22.03.2026 folgten weitere manipulierte Docker-Images; das Projekt empfiehlt, Actions auf den vollständigen Commit-Hash festzulegen.
Ein gemeinsamer Pipeline-Schritt für IaC, Container-Images und Secrets.
Ein Werkzeug deckt IaC, Images, SBOM und Secrets ab, was die Zahl der Pipeline-Schritte senkt.
Pipelines sollten den Scanner und die zugehörige Action auf geprüfte Versionen oder Commit-Hashes festlegen.
KICS
Checkmarx (Open-Source-Projekt)
Terraform und OpenTofu, CloudFormation, ARM, Bicep, Kubernetes, Helm, Ansible, Pulumi, Crossplane, Docker, Google Deployment Manager, AWS CDK und SAM sowie GitHub Workflows.
KICS (Keeping Infrastructure as Code Secure) wertet die Dateien mit anpassbaren Abfragen aus, die in Rego geschrieben sind; neue Formate lassen sich über die Architektur ergänzen.
Die Abfragebibliothek deckt Fehlkonfigurationen, Compliance-Verstösse und eingebettete Passwörter oder Secrets ab; Version 2.0 führte den Schweregrad «Critical» mit eigenem Exit-Code ein.
Plugins oder Anleitungen für Azure Pipelines, Bamboo, Bitbucket, CircleCI, GitHub Actions, GitLab CI, Jenkins, TeamCity, Terraform Cloud, AWS CodeBuild und eine VS-Code-Erweiterung.
Läuft lokal; Checkmarx betreibt das Projekt und nutzt es auch kommerziell, GitLab setzt KICS als Engine seiner IaC-Prüfung ein.
Prüfung heterogener Repositories, in denen mehrere IaC-Formate nebeneinander vorkommen.
Breite Formatliste und Abfragen in Rego, die sich mit Werkzeugen von Open Policy Agent testen lassen.
KICS meldet Befunde nur für Ressourcentypen, für die Abfragen existieren; bei seltenen Providern greifen nur die anbieterunabhängigen Prüfungen.
Conftest
Open Policy Agent (CNCF-Projekt)
Testet beliebige strukturierte Konfigurationsdateien, darunter HCL und HCL2 von Terraform, Kubernetes-Konfigurationen, Dockerfiles, JSON, YAML, INI und weitere Formate.
Die Prüfregeln schreibt das Team selbst in Rego, der Sprache von Open Policy Agent; Conftest wendet sie auf die eingelesenen Dateien an.
Deny- und Warn-Regeln melden Verstösse gegen interne Vorgaben, etwa einen Load Balancer mit HTTP statt HTTPS.
Die Funktion parse_config erlaubt Tests der Richtlinien selbst, sodass Regeln wie Code geprüft und versioniert werden.
Lokal ausgeführtes Werkzeug im Umfeld von Open Policy Agent; Lizenz Apache 2.0.
Durchsetzung hauseigener Architekturvorgaben, die kein Standardkatalog abdeckt.
Eine Richtliniensprache für Terraform, Kubernetes und viele andere Konfigurationsformate.
Alle Prüfregeln entstehen im eigenen Team und müssen dort geschrieben, getestet und gepflegt werden.
Snyk IaC
Snyk
Terraform, CloudFormation, Kubernetes, Helm-Charts und ARM-Vorlagen; zusätzlich Scans bereitgestellter Umgebungen in AWS, Azure und Google Cloud.
Eingebaute Regelsätze für die Formate und Cloud-Anbieter, gestützt auf Best Practices und CIS-Benchmarks; eigene Regeln entstehen mit Open Policy Agent.
Der Befehl snyk iac describe meldet Ressourcen, die in der Cloud existieren, aber nicht im Terraform-State stehen.
IDE, CLI, Quellcodeverwaltung, CI/CD sowie Terraform Cloud und Enterprise-Integrationen.
SaaS-Plattform mit wählbarer Datenregion, darunter EU, US und AU.
Entwicklungsteams erhalten Befunde und Korrekturvorschläge direkt im Code, bevor eine Änderung zusammengeführt wird.
Befunde erscheinen in den Werkzeugen der Entwickler und lassen sich in Pipelines als Sperre einsetzen.
Die Drift-Funktion meldet nicht verwaltete Ressourcen; für Abweichungen verwalteter Ressourcen verweist Snyk auf terraform plan.
SonarQube (IaC-Analyse)
Sonar (SonarSource, Genf und Austin)
SonarQube Server 2026.5 analysiert IaC-Sprachen wie CloudFormation, Kubernetes und Terraform; für Terraform werden AWS, Azure und Google Cloud unterstützt.
IaC-Dateien laufen durch dieselbe statische Analyse wie Anwendungscode; für Terraform werden AWS, Azure und Google Cloud als Plattformen unterstützt.
Die Pull-Request- und Branch-Analyse zeigt IaC-Befunde zusammen mit den übrigen Code-Befunden, bevor eine Änderung zusammengeführt wird.
Analyse von Pull Requests und Branches in gängigen CI-Systemen; die kostenlose Erweiterung SonarQube for IDE zeigt Befunde beim Schreiben.
Wahlweise als Cloud-Dienst oder selbst betriebener Server; Sonar hat Hauptsitze in Genf (Vernier) und Austin.
Organisationen, die SonarQube bereits für Codequalität nutzen, ergänzen IaC-Prüfungen ohne weiteres Werkzeug.
IaC-Prüfung im selben Werkzeug und Freigabeprozess wie Code-Qualität und Code-Sicherheit.
Einen Abgleich mit dem laufenden Cloud-Zustand bietet das Produkt laut den geprüften Seiten nicht.
Aikido Infrastructure as Code
Aikido Security BV (Gent, Belgien)
Terraform, CloudFormation, Pulumi, Kubernetes-Manifeste, Helm-Charts sowie Azure ARM- und Bicep-Vorlagen.
Der Scanner prüft HCL, YAML und JSON gegen Best Practices und eigene Regeln, zum Beispiel «S3-Buckets müssen Logging haben».
Meldet öffentliche Speicher-Buckets, offene Sicherheitsgruppen, unverschlüsselte Datenbanken, übermässige IAM-Rechte und öffentliche VMs; Korrekturen lassen sich als Pull Request erzeugen.
CI/CD-Systeme wie GitHub Actions, GitLab und Jenkins, Pre-Commit-Hooks und IDE-Erweiterungen.
SaaS-Plattform eines belgischen Unternehmens mit Sitz in Gent; IaC ist ein Modul neben SAST, SCA, Secrets und Cloud-Posture.
Entwicklungsteams, die IaC-, Code- und Abhängigkeitsprüfung in einer Plattform bündeln wollen.
IaC-Befunde lassen sich als Pull Request mit Korrekturvorschlag zurück ins Repository geben.
Ein Drift-Abgleich ist auf der Produktseite nicht beschrieben; die Verknüpfung mit der Cloud dient der Priorisierung.
GitLab IaC Scanning
GitLab
Ansible, CloudFormation, ARM-Vorlagen im JSON-Format, Dockerfile, Google Deployment Manager, Kubernetes, OpenAPI und Terraform; Bicep muss vorher nach JSON übersetzt werden.
Die Prüfung läuft als Job in der GitLab-Pipeline und nutzt KICS als Engine; Projekte mit mehreren IaC-Formaten werden gemeinsam geprüft.
Befunde erscheinen vor dem Zusammenführen in den Standard-Branch; in der Stufe Ultimate lassen sich Regeln deaktivieren und Schweregrade überschreiben.
Befunde fliessen in das Schwachstellenmanagement von GitLab; Regelanpassung über die Datei sast-ruleset.toml.
Verfügbar in den Stufen Free, Premium und Ultimate auf GitLab.com, GitLab Self-Managed und GitLab Dedicated.
Teams, die ihre Pipelines in GitLab betreiben und IaC-Prüfung ohne zusätzlichen Dienst einführen wollen.
Bereits in der Gratisstufe in der eigenen Pipeline verfügbar, auch selbst betrieben.
Eigene Regeln lassen sich laut Dokumentation nicht hinzufügen; Terraform-Module aus privaten Registries werden nicht geprüft.
Cortex Cloud Application Security (IaC Security)
Palo Alto Networks
Ansible, Dockerfile, OpenAPI, ARM, Helm, OpenTofu, Bicep, Kubernetes, Terraform inklusive Plan, CloudFormation und Kustomize.
Code Security analysiert Quelltexte, Abhängigkeiten und IaC-Vorlagen, bevor sie einen geschützten Branch oder eine Cloud-Ressource erreichen; ASPM steuert Richtlinien und Priorisierung.
Verknüpft IaC-Vorlagen mit bereitgestellten Ressourcen und Laufzeitkontext, erkennt Drift und prüft Ressourcen gegen freigegebene Richtlinien.
Quellcodeverwaltung GitHub, GitLab, Bitbucket und Azure DevOps, CI-Systeme wie GitHub Actions, GitLab CI, Azure Pipelines, Jenkins und CircleCI sowie Erweiterungen für VS Code und JetBrains.
Cloud-Dienst als Zusatzmodul von Cortex Cloud; die Code-zu-Cloud-Herleitung stützt sich bei IaC auf Terraform- und CloudFormation-Dateien.
Unternehmen mit Prisma Cloud oder Cortex Cloud, die Laufzeitbefunde bis zur verursachenden Vorlage zurückverfolgen wollen.
Code-, Pipeline- und Laufzeitkontext werden in einer Plattform verknüpft, inklusive Drift-Erkennung.
Die Herleitung von der Cloud-Ressource zum Code ist für IaC auf Terraform und CloudFormation dokumentiert.
Wiz Code
Wiz (Google)
IaC-Prüfung für Terraform, CloudFormation, Azure Resource Manager, Kubernetes, Docker und weitere Formate mit über 1000 Regeln.
Wiz Code ordnet Ressourcen in der Cloud ihrem Quellcode zu und schlägt Korrekturen an der Stelle im Code vor, aus der das Risiko stammt.
Erkennt Drift zwischen Code und Cloud und prüft neben IaC auch Abhängigkeiten, Secrets, Malware sowie die Konfiguration von VCS- und CI/CD-Systemen.
IDE-Scans, Pull-Request-Prüfung in GitHub, CI/CD-Einbindung, Slack-Integration und ein MCP-Server.
Cloud-Dienst; Wiz unterstützt nach eigenen Angaben weiterhin AWS, Azure, GCP und OCI.
Organisationen, die Wiz für die Cloud-Posture nutzen und Befunde bis ins Repository zurückführen wollen.
Die Verknüpfung von Cloud-Befund und Quellcode zeigt, welche Vorlage eine Fehlkonfiguration erzeugt hat.
Der Abgleich zwischen Code und Cloud setzt die angebundene Wiz-Cloud-Plattform voraus.
Orca IaC Security
Orca Security
Terraform, AWS CloudFormation, Azure Resource Manager, Google Deployment Manager, Ansible, Pulumi und Kubernetes.
Scannt IaC-Artefakte beim Einchecken und bei jedem Pull Request; Richtlinien werden laut Hersteller (2024) aus über 1100 Kontrollen zusammengestellt und nach Plattform, Risiko oder Compliance-Rahmen gefiltert.
Richtlinien können einen riskanten Build blockieren oder nur Entwickler benachrichtigen.
Laut Hersteller (2024) über 50 Integrationen zu Ticketsystemen und CI/CD-Werkzeugen; Cloud-to-Dev führt Cloud-Risiken auf IaC-Code in Git zurück.
Teil der agentenlosen Orca-Plattform, die IaC-Prüfung zusammen mit SCA, SAST, Secrets und Image-Scan anbietet.
Cloud-Teams mit Orca, die Befunde aus der Produktion in Pull Requests umwandeln wollen.
Laufzeitbefunde lassen sich bis zur Codezeile und zum verantwortlichen Repository zurückverfolgen.
IDE-Integration und Drift-Erkennung sind auf den geprüften Seiten nicht beschrieben.
Microsoft Defender for Cloud (DevOps-Sicherheit)
Microsoft
Microsoft Security DevOps bündelt Checkov, Terrascan, Trivy und Template Analyzer und deckt damit Terraform, CloudFormation, Kubernetes, Helm, ARM und Bicep ab.
Die Pipeline-Erweiterung führt die Analysatoren aus; IaCFileScanner ordnet Terraform-, CloudFormation-, ARM- und Bicep-Vorlagen den Cloud-Ressourcen zu.
IaC-Befunde erscheinen in der DevOps-Sicherheitskonsole und als Pull-Request-Anmerkungen; Code-zu-Cloud-Kontext hilft bei der Priorisierung.
GitHub Action und Azure-DevOps-Erweiterung; Repositories aus Azure DevOps, GitHub und GitLab lassen sich anbinden.
Teil von Defender for Cloud; die meisten eingebundenen Analysatoren stehen unter offenen Lizenzen, IaCFileScanner nicht.
Azure-orientierte Organisationen, die IaC-Befunde zusammen mit Cloud-Posture im Defender-Portal führen.
IaC-Befunde und Cloud-Posture laufen im selben Microsoft-Portal zusammen.
Die Prüfung beruht auf eingebundenen Drittwerkzeugen, darunter das seit 20.11.2025 archivierte Terrascan.
Mondoo IaC Security (cnspec)
Mondoo (Mondoo, Inc., Berkeley; Mondoo GmbH, Berlin)
Terraform als HCL, Plan und State, Azure Bicep, CloudFormation, Helm-Charts und Kubernetes-Manifeste; dieselbe Engine prüft auch Cloud-Konten und Betriebssysteme.
cnspec bewertet Ressourcen mit Richtlinien in YAML und der Abfragesprache MQL; dieselben Richtlinien gelten für Entwicklung, Deployment und Produktion.
Pull-Request-Kontrollen mit Korrekturhinweisen und Freigabe-Gates in CI/CD blockieren nicht konforme Infrastruktur.
Pipeline-Gates und Pull-Request-Prüfung; die Plattform ergänzt die Engine um weitere Richtlinien, darunter zertifizierte CIS-, NIST- und BSI-Benchmarks.
cnspec steht unter der Business Source License 1.1; Mondoo hat neben dem US-Sitz eine GmbH in Berlin.
Gleiche Richtlinien für Vorlagen vor dem Deployment und für bereits laufende Cloud-, Kubernetes- und On-Prem-Systeme.
Eine Richtliniensprache für IaC, Cloud-Konten und Server erleichtert den Nachweis über den ganzen Lebenszyklus.
Die BUSL-Lizenz von cnspec ist keine Open-Source-Lizenz im Sinne der OSI; die Nutzungsbedingungen sind vor Einsatz zu prüfen.
HCP Terraform (Policy Enforcement und Health)
HashiCorp (IBM)
Terraform-Workspaces und Stacks, die in HCP Terraform ausgeführt werden.
Richtlinien in Sentinel, OPA oder dem Terraform-eigenen Policy-Framework prüfen jeden Plan, bevor er angewendet wird.
Health Assessments erkennen Drift zwischen realer Infrastruktur und Konfiguration und prüfen mit Continuous Validation, ob definierte Bedingungen nach dem Provisioning weiter gelten.
Policy Sets lassen sich Workspaces zuordnen; Sentinel- und OPA-Policy-Sets unterstützen nur Workspaces.
Health Assessments sind in den Editionen Standard und Premium verfügbar.
Plattformteams, die Terraform zentral ausführen und Vorgaben sowie Drift im Betriebswerkzeug selbst durchsetzen.
Richtlinienprüfung und Drift-Erkennung sitzen dort, wo Terraform-Änderungen tatsächlich angewendet werden.
Beschränkt auf Terraform-Läufe in HCP Terraform; andere IaC-Formate und lokale Läufe liegen ausserhalb.
Weitere Anbieter
Kurz eingeordnet, ausserhalb der Vergleichsmatrix.
- Terrascan (Tenable): Open Source (Apache 2.0), seit 20.11.2025 archiviert und laut Repository nicht mehr gepflegt
- tfsec (Aqua Security): Terraform-Prüfung wird laut Projekt in Trivy weitergeführt; Nutzer sollen zu Trivy wechseln
- Checkmarx One IaC Security: kommerzielle Plattform von Checkmarx mit IaC-Prüfung und IDE-Plugin; im Vergleich über das Open-Source-Projekt KICS vertreten
- Semgrep, GitHub Code Scanning (SARIF): Code-Analyse bzw. Integrationsplattform für Scan-Ergebnisse im SARIF-Format
- Datadog IaC Security, Tenable Cloud Security, SentinelOne, CrowdStrike: IaC-Prüfung als Modul grösserer Cloud-Plattformen
- Spacelift, env0, Scalr: Terraform-Betriebsplattformen mit Richtlinien und Drift-Funktionen
- Ein Scan des Templates übersieht Risiken, die erst im erzeugten Plan sichtbar werden.
- Teams unterdrücken Regeln global, weil Ausnahmen nicht ressourcengenau verwaltet werden.
- Manuelle Cloud-Änderungen erzeugen Drift ausserhalb des Repositorys.
Teste reale Module, Variablen, einen erzeugten Terraform-Plan, eine zeitlich befristete Ausnahme und eine absichtliche Cloud-Abweichung. Das Ergebnis muss Entwicklerfeedback und zentralen Nachweis verbinden.
Security Tool Navigator · Gebiet 06
Im Gebiet Cloud und Infrastructure Security einordnen.
Diese Werkzeugklasse gehört zum Gebiet Cloud und Infrastructure Security. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.