Checkov vs. tfsec vs. Terrascan: IaC-Scanner 2026

Am 20. November 2025 hat Tenable das GitHub-Repository von Terrascan auf schreibgeschützt gestellt. Für viele DevOps-Teams in Deutschland, Österreich und der Schweiz war das der Moment, an dem eine jahrelange Routine kippte: Das Tool, mit dem sie ihre Terraform- und Kubernetes-Dateien vor jedem Deployment geprüft haben, bekommt keine neuen Regeln mehr. Keine neuen CVEs, keine Provider-Updates, keine Policy-Pflege. Wer jetzt noch auf Terrascan setzt, scannt mit dem Wissensstand von 2025 gegen die Bedrohungslage von 2026.

Gleichzeitig hat sich ein zweites Werkzeug leise verändert: tfsec, lange der Terraform-Spezialist unter den Open-Source-Scannern, wird nicht mehr eigenständig weiterentwickelt. Die Regeln und die aktive Arbeit sind in Trivy von Aqua Security aufgegangen. Nur Checkov, das Bridgecrew-Projekt unter dem Dach von Palo Alto Networks, läuft unverändert als eigenständiges, aktiv gepflegtes Produkt weiter. Wer heute eine Infrastructure-as-Code-Pipeline absichert, muss also nicht mehr zwischen drei gleichwertigen Optionen wählen, sondern zwischen einem aktiven Scanner, einem Nachfolgeprojekt und einem Auslaufmodell. Dieser Vergleich zeigt, was das für Teams in der Praxis bedeutet, mit welchen Kosten zu rechnen ist und wie der Umstieg konkret funktioniert.

Was ist IaC-Sicherheit und warum ist sie 2026 Pflicht?

Infrastructure as Code bedeutet, dass Server, Netzwerke, Firewall-Regeln und Kubernetes-Cluster nicht mehr per Klick in einer Web-Konsole entstehen, sondern als Textdateien in Terraform, CloudFormation oder Helm-Charts beschrieben werden. Das macht Infrastruktur reproduzierbar und versionierbar, öffnet aber auch eine neue Angriffsfläche: Ein offener S3-Bucket, eine Firewall-Regel mit 0.0.0.0/0 oder ein IAM-Nutzer mit Admin-Rechten landet nicht mehr in einer Konsole, sondern in einer Datei, die ein Entwickler committet und die automatisiert in die Produktion rollt.

Genau hier setzen IaC-Security-Scanner an. Sie lesen den Code vor dem Deployment und schlagen Alarm, wenn eine Konfiguration gegen bekannte Sicherheits- oder Compliance-Regeln verstößt, etwa gegen CIS-Benchmarks, PCI-DSS oder interne Policies. Laut dem Marktforschungsportal Dataintelo hatten 2025 bereits rund 58 Prozent der Großunternehmen mindestens eine dedizierte IaC-Security-Plattform im Einsatz, 2021 waren es erst etwa 31 Prozent. Der Treiber dahinter ist simpel: Je mehr Infrastruktur als Code existiert, desto teurer wird ein einzelner übersehener Fehler, weil er sich automatisch über hunderte Umgebungen repliziert. Ein Tippfehler in einer Terraform-Variable kann so binnen Minuten hunderte Server gleichzeitig falsch konfigurieren, statt wie früher nur eine einzelne, manuell eingerichtete Maschine zu betreffen.

Nach Zahlen von Datadogs State of DevSecOps setzen inzwischen 71 Prozent der Organisationen mit AWS-Umgebungen auf Infrastructure as Code, bei Google Cloud liegt der Anteil bei 55 Prozent. Parallel dazu haben laut einer 2026er Auswertung von AppSecSanta rund 68 Prozent der Unternehmen IaC bereits in Produktivumgebungen im Einsatz, 73 Prozent planen für 2026 eine deutliche Ausweitung. Scanner wie Checkov, tfsec und Terrascan sind damit nicht mehr nur ein Nice-to-have für Sicherheitsteams, sondern ein Pflichtbaustein jeder modernen CI/CD-Pipeline.

Die drei in diesem Vergleich betrachteten Werkzeuge, Checkov, tfsec und Terrascan, haben über Jahre genau diese Rolle übernommen und sind in tausenden Pipelines weltweit fest verankert. Sie unterscheiden sich in der Zahl der Prüfregeln, den unterstützten Formaten und vor allem im Reifegrad der Weiterentwicklung. Gerade dieser letzte Punkt hat sich zwischen 2025 und 2026 so stark verschoben, dass eine reine Funktions-Checkliste das Bild verzerren würde. Ein Tool mit 500 Regeln, die seit einem Jahr nicht aktualisiert wurden, schützt in der Praxis schlechter als eines mit 400 aktiv gepflegten Regeln, weil neue Cloud-Dienste und neue Angriffsmuster laufend dazukommen.

Die drei Werkzeuge im Überblick

Checkov ist ein Open-Source-Scanner, den Bridgecrew ursprünglich entwickelt hat und der heute unter dem Dach von Palo Alto Networks weiterlebt. Das Tool arbeitet als statische Analyse über eine Vielzahl von IaC-Formaten hinweg und kombiniert einfache Attribut-Prüfungen mit einer grafenbasierten Analyse, die auch Beziehungen zwischen Ressourcen prüft, etwa ob eine Datenbank, die öffentlich erreichbar ist, gleichzeitig unverschlüsselt läuft.

tfsec stammt von Aqua Security und war lange der schlanke Terraform-Spezialist unter den Scannern. Seit 2025 ist das Projekt offiziell in Trivy aufgegangen, dem breiter aufgestellten Scanner von Aqua, der neben IaC auch Container-Images, Dateisysteme und Abhängigkeiten prüft. Das GitHub-Repository von tfsec trägt mittlerweile den Hinweis, dass die Terraform-Scan-Fähigkeiten vollständig in Trivy übergegangen sind.

Terrascan kam von Accurics und wechselte später zu Tenable. Das Tool deckte Terraform, Kubernetes, Helm, CloudFormation und ARM-Templates ab und baute auf rund 500 Rego-Policies, die zum Zeitpunkt der Archivierung im Repository lagen. Seit dem 20. November 2025 ist das Projekt read-only, die Scan-Fähigkeiten laufen bei Tenable inzwischen unter dem Dach von Tenable Cloud Security weiter, allerdings nicht mehr als eigenständiges Open-Source-Tool mit aktiver Community-Pflege.

Alle drei Tools verfolgen technisch einen ähnlichen Ansatz: Sie parsen die IaC-Datei in eine interne Darstellung, meist einen Baum oder Graphen aus Ressourcen und Attributen, und prüfen diese Darstellung gegen eine Sammlung von Regeln. Checkov schreibt seine Regeln in Python oder YAML, tfsec nutzte vor der Fusion eigene Go-Regeln, die inzwischen in Trivys Rego-basiertes Regelwerk überführt wurden, und Terrascan baute von Anfang an komplett auf der Policy-Sprache Rego der Open Policy Agent-Familie auf. Für Teams, die eigene Regeln schreiben wollen, ist das ein praktischer Unterschied: Rego hat eine steilere Lernkurve als die YAML-basierten Checkov-Regeln, bietet dafür aber eine sehr präzise Kontrolle über komplexe Bedingungen.

Terrascan ist tot: Was die Archivierung am 20. November 2025 bedeutet

Für Teams, die Terrascan seit Jahren in ihrer Pipeline laufen haben, ändert sich auf den ersten Blick wenig. Die CLI startet weiterhin, vorhandene Workflows brechen nicht sofort. Das Problem liegt tiefer: Ein archiviertes Repository bekommt keine Pull Requests, keine neuen Policy-Definitionen und keine Reaktion auf neu entdeckte Fehlkonfigurationsmuster mehr. Wenn AWS, Azure oder Kubernetes neue Ressourcentypen einführen, die anfällig für Fehlkonfiguration sind, taucht das in Terrascan nicht mehr auf.

Das Entwicklerblog Spacelift listet Terrascan in seiner aktuellen Marktübersicht entsprechend nicht mehr als aktive Empfehlung, sondern als Warnbeispiel für Tool-Lifecycle-Risiken. Wer seine Pipeline-Sicherheit heute noch auf ein archiviertes Projekt stützt, verlässt sich auf einen Stand von vor fast einem Jahr, während sich Cloud-Anbieter und Angreifer-Taktiken in dieser Zeit weiterentwickelt haben. Sicherheitsteams sollten die Archivierung als festen Stichtag für eine Migration behandeln, nicht als theoretisches Risiko für die Zukunft.

tfsec geht in Trivy auf: Das Ende der eigenständigen Entwicklung

Anders als Terrascan verschwindet tfsec nicht ersatzlos. Aqua Security hat die Terraform-Scan-Logik, laut eigener Aussage im GitHub-Repository, vollständig in Trivy überführt und dort sogar ausgebaut. Mehr als 1.000 Prüfregeln für AWS, Azure und Google Cloud, die früher unter der tfsec-Marke liefen, sind heute Teil von Trivys Misconfiguration-Scanner. Wer den Befehl tfsec . gewohnt ist, ersetzt ihn im Kern durch trivy config . und bekommt dieselbe Terraform-Abdeckung, dazu aber auch Container- und Abhängigkeits-Scans aus einer einzigen Binärdatei.

Der GitHub-Themenindex weist für das tfsec-Repository aktuell rund 7.000 Sterne aus, während ältere Branchenartikel teils deutlich höhere Zahlen nennen, die sich vermutlich auf unterschiedliche Zählzeitpunkte oder verwandte Projekte beziehen. Für die Praxis zählt ohnehin weniger die Sternezahl als die Tatsache, dass neue Regeln künftig ausschließlich in Trivy entstehen. Teams, die tfsec isoliert für reine Terraform-Scans nutzen, sollten den Umstieg auf Trivy mittelfristig einplanen, auch wenn die alte CLI technisch noch läuft.

Checkov im Detail: Richtlinien, Formate und Graph-Analyse

Checkov bleibt von den drei Projekten das einzige, das 2026 noch als eigenständiges, aktiv weiterentwickeltes Produkt am Markt steht. Die offizielle Dokumentation nennt mehr als 750 vordefinierte Policies, während die Analyseplattform AppSecSanta in einer aktuellen Marktübersicht von über 1.000 Prüfungen spricht, darunter rund 800 grafenbasierte Checks, die Beziehungen zwischen mehreren Ressourcen gleichzeitig bewerten. Die Differenz erklärt sich vermutlich aus unterschiedlichen Zähl- und Versionsständen, zeigt aber in jedem Fall: Checkov deckt inzwischen deutlich mehr ab als eine einfache Zeile-für-Zeile-Prüfung.

Beim Format-Support liegt Checkov klar vorn. Terraform, Terraform-Pläne, OpenTofu, CloudFormation, AWS SAM, Kubernetes-Manifeste, Helm-Charts, Kustomize, ARM-Templates, Bicep, Dockerfiles, Serverless-Framework-Dateien und sogar OpenAPI-Spezifikationen lassen sich mit demselben Tool prüfen. Für Teams mit gemischten Stacks, etwa Terraform für die Cloud-Infrastruktur und Helm für die Kubernetes-Workloads, spart das den Betrieb mehrerer Einzelscanner. Laut AppSecSanta kommt Checkov inzwischen auf mehr als 80 Millionen Downloads, ein Indikator für die Verbreitung in CI/CD-Pipelines weltweit.

Typische Fehlkonfigurationen, die Scanner heute aufspüren

Um zu verstehen, wofür diese Tools überhaupt gebraucht werden, hilft ein Blick auf ein konkretes Beispiel. Das folgende Terraform-Snippet beschreibt einen S3-Bucket ohne Verschlüsselung und ohne Zugriffsbeschränkung, ein Klassiker unter den Fehlkonfigurationen, die in der Praxis zu Datenlecks führen.

resource "aws_s3_bucket" "data" {
  bucket = "firmendaten-2026"
}

resource "aws_s3_bucket_public_access_block" "data" {
  bucket                  = aws_s3_bucket.data.id
  block_public_acls       = false
  block_public_policy     = false
}

Checkov würde hier gleich mehrere Regeln auslösen, etwa den Hinweis auf eine fehlende serverseitige Verschlüsselung und die explizit deaktivierte Public-Access-Blockierung. Trivy im config-Modus erkennt dieselben Muster über die von tfsec geerbten AWS-Regeln. Terrascan hätte diese Muster ebenfalls erkannt, solange sie zum Zeitpunkt der Archivierung im November 2025 bereits als Regel hinterlegt waren. Entdeckt AWS künftig neue Bucket-Einstellungen mit Sicherheitsrelevanz, wie es in den vergangenen Jahren regelmäßig vorkam, fließt das nur noch in Checkov und Trivy ein, nicht mehr in Terrascan.

Ein zweites, häufiges Muster betrifft überprivilegierte IAM-Rollen, etwa eine Policy mit der Aktion "*" auf die Ressource "*". Checkov markiert das über seine grafenbasierte Analyse zusätzlich als kritischer, wenn dieselbe Rolle an eine öffentlich erreichbare Lambda-Funktion oder einen EC2-Dienst gebunden ist, weil das Tool den Zusammenhang zwischen beiden Ressourcen erkennt. Attributbasierte Scanner wie Trivy oder das archivierte Terrascan bewerten die IAM-Policy und die Netzwerk-Exposition dagegen getrennt voneinander und liefern deshalb pro Ressource eine Einzelwarnung statt einer priorisierten Gesamtrisikobewertung.

Pflegezyklus und Reaktionszeit: Warum ein aktives Projekt zählt

Ein Scanner ist nur so gut wie sein letztes Regel-Update. Cloud-Anbieter wie AWS, Azure und Google Cloud veröffentlichen fast wöchentlich neue Dienste, neue Konfigurationsoptionen oder geänderte Standardwerte, und jede dieser Änderungen kann eine neue Fehlkonfigurationsmöglichkeit eröffnen. Aktiv gepflegte Projekte wie Checkov und Trivy reagieren auf solche Änderungen über ihre Community und die dahinterstehenden Unternehmen Palo Alto Networks und Aqua Security, die beide ein kommerzielles Interesse daran haben, ihre Regelbasis aktuell zu halten, weil sie damit auch ihre bezahlten Produkte Prisma Cloud beziehungsweise die kommerzielle Trivy-Plattform stützen.

Bei Terrascan fehlt dieser Mechanismus seit dem Archivierungsdatum vollständig. Zwar bleibt die Sammlung der zuletzt rund 500 Rego-Policies nutzbar, neue Pull Requests werden vom Projekt aber nicht mehr angenommen. Für Teams in regulierten Branchen ist das relevant, weil Auditoren zunehmend danach fragen, mit welchem Werkzeug und welchem Pflegezustand eine IaC-Prüfung durchgeführt wurde. Ein archiviertes Tool als alleinige Kontrolle anzugeben, wird in Sicherheitsaudits zunehmend kritisch hinterfragt, selbst wenn die Scan-Ergebnisse technisch weiterhin erzeugt werden können.

Technische Spezifikationen im direkten Vergleich

Die folgende Tabelle fasst die zentralen technischen Eckdaten zusammen, wie sie aus den offiziellen Projektseiten sowie aktuellen Marktübersichten von Spacelift und AppSecSanta hervorgehen.

Merkmal	Checkov	tfsec (jetzt Trivy)	Terrascan
Status 2026	Aktiv, eigenständig	Eingestellt, in Trivy integriert	Archiviert seit 20.11.2025
Hersteller/Maintainer	Bridgecrew / Palo Alto Networks	Aqua Security	Tenable
Lizenzmodell	Open Source (Apache 2.0) + Prisma Cloud kommerziell	Open Source (Apache 2.0)	Open Source (Apache 2.0, unmaintained)
Eingebaute Policies	750+ laut Doku, 1.000+ laut Drittquellen	1.000+ Checks (AWS, Azure, GCP)	~500 Rego-Policies (Stand Archivierung)
Graph-basierte Checks	Ja, ca. 800 ressourcenübergreifende Checks	Nein	Nein
Terraform	Ja, inkl. Plan-Dateien und OpenTofu	Ja (via Trivy config)	Ja (ungepflegt)
CloudFormation / AWS SAM	Ja	Ja (via Trivy)	Ja (ungepflegt)
Kubernetes / Helm	Ja, inkl. Kustomize	Ja (via Trivy)	Ja (ungepflegt)
ARM / Bicep	Ja	Teilweise (via Trivy)	Ja (ungepflegt)
Dockerfile-Scan	Ja	Ja (nativ in Trivy)	Nein
CI/CD-Integrationen	GitHub Actions, GitLab CI, Jenkins, Azure Pipelines, Bitbucket, CircleCI, Argo Workflows	Breite Trivy-Integrationen (GitHub, GitLab, Jenkins)	GitHub Actions, GitLab CI, Jenkins (nicht mehr gepflegt)
GitHub-Sterne (Richtwert)	Mehrere Zehntausend	~7.000 laut GitHub-Themenindex	Nicht mehr offiziell gepflegt
Downloads	80 Mio.+ laut AppSecSanta	In Trivy-Downloads aufgegangen	Keine aktuellen Zahlen verfügbar

Preise und Lizenzmodelle im Vergleich

Alle drei Projekte sind in ihrer Kernversion kostenlos, der Unterschied liegt im kommerziellen Unterbau. Checkov lässt sich komplett gratis als CLI oder in der CI/CD-Pipeline betreiben, Palo Alto Networks verkauft aber mit Prisma Cloud eine kostenpflichtige Erweiterung, die zentrale Richtlinienverwaltung, Pull-Request-Annotationen über viele Repositories hinweg und Drift-Erkennung in der Laufzeitumgebung ergänzt. Einen öffentlich gelisteten Preis für Prisma Cloud gibt es nicht, Interessenten erhalten ein individuelles Angebot.

tfsec selbst verursacht keine Kosten mehr, weil die Weiterentwicklung komplett in das ebenfalls freie Trivy übergegangen ist. Terrascan bleibt technisch kostenlos nutzbar, wobei Interessenten an einer gepflegten, kommerziellen Variante inzwischen auf Tenable Cloud Security verwiesen werden. Zur Einordnung: Nach einer Marktübersicht des Sicherheitsanbieters Aikido starten kommerzielle IaC-Security-Plattformen am Markt verbreitet bei etwa 350 US-Dollar im Monat, der genaue Preis hängt stark vom Funktionsumfang und der Zahl der gescannten Repositories ab.

Neben der reinen Lizenzgebühr lohnt sich ein Blick auf die versteckten Kosten. Ein Scanner mit vielen Fehlalarmen bindet Entwicklerzeit, weil jedes Finding manuell bewertet werden muss, bevor ein Team entscheidet, ob es sich um einen echten Treffer oder eine zu pauschale Regel handelt. Checkov erlaubt dafür das gezielte Unterdrücken einzelner Checks über Inline-Kommentare oder eine zentrale Konfigurationsdatei, Trivy bietet vergleichbare Suppress-Mechanismen. Bei Terrascan bleibt diese Pflegearbeit zwar möglich, wirkt aber zunehmend wie Arbeit an einem Regelwerk, das ohnehin nicht mehr wächst, was den wirtschaftlichen Nutzen gegenüber einem aktiv gepflegten Scanner schmälert.

Tool / Tier	Preis	Enthaltene Leistung
Checkov (Open Source)	0 €	Vollständige CLI, alle Policies, CI/CD-Plugins
Prisma Cloud (Checkov-Unterbau)	Individuelles Angebot	Zentrales Dashboard, Drift-Erkennung, Multi-Repo-Management
Trivy / vormals tfsec (Open Source)	0 €	IaC-, Container-, Dependency- und Secret-Scan in einem Tool
Terrascan (Open Source, archiviert)	0 €	Letzter Stand: ~500 Policies, keine Updates mehr
Tenable Cloud Security (Terrascan-Nachfolger)	Individuelles Angebot	Cloud-native Sicherheitsplattform inkl. IaC-Scan
Marktdurchschnitt kommerzielle IaC-Plattformen	ab ca. 350 $/Monat	Variiert je nach Anbieter und Repo-Anzahl

Policy-Abdeckung als Benchmark: Was drei unabhängige Quellen zeigen

Ein echter, unter identischen Bedingungen durchgeführter Geschwindigkeits- oder Fehlalarm-Benchmark zwischen Checkov, Trivy und Terrascan existiert aktuell nicht öffentlich, mit gleichen Repositories, gleicher Hardware und manuell geprüften Treffern. Wer im Netz Aussagen wie “Checkov ist 30 Prozent schneller” liest, sollte das mit Vorsicht behandeln, solange die Quelle nicht offenlegt, welche Regeln aktiviert waren und wie viele Ressourcen geprüft wurden. Seriöser lässt sich der Vergleich über die Policy-Abdeckung dreier unabhängiger Analysen führen.

Die offizielle Checkov-Dokumentation nennt mehr als 750 Policies. Die Plattform AppSecSanta kommt in einer eigenen Erhebung auf über 1.000 Checks für Checkov und ordnet Trivy inklusive der absorbierten tfsec-Regeln ebenfalls bei rund 1.000 bis 1.500 Checks ein. Spacelift wiederum bewertet in seiner Marktübersicht der Terraform-Scanner Trivy als das Tool mit der aktuell breitesten aktiven Regelpflege, während Terrascan mit seinen zuletzt rund 500 Rego-Policies explizit als eingefroren markiert wird. Alle drei Quellen kommen unabhängig voneinander zum selben Muster: Checkov und Trivy wachsen weiter, Terrascan steht seit November 2025 still.

Ein Unterschied in der Scan-Tiefe lässt sich dagegen klar belegen: Nur Checkov bietet mit seinen rund 800 grafenbasierten Checks die Fähigkeit, Beziehungen zwischen mehreren Ressourcen gleichzeitig zu bewerten, etwa ob eine öffentlich erreichbare Load-Balancer-Regel auf eine unverschlüsselte Datenbank zeigt. Trivy und das archivierte Terrascan arbeiten dagegen primär attributbasiert und prüfen einzelne Ressourcen für sich, nicht deren Zusammenspiel.

Für die Praxis bedeutet das einen Unterschied in der Priorisierung von Findings, nicht zwangsläufig in deren absoluter Zahl. Ein attributbasierter Scanner liefert bei einem größeren Terraform-Projekt häufig mehrere hundert Einzelwarnungen, die ein Team manuell nach Relevanz sortieren muss. Checkovs Graph-Engine kann einen Teil dieser Sortierarbeit automatisch übernehmen, indem sie Kombinationen aus mehreren riskanten Einstellungen höher gewichtet als isolierte Einzelfunde. Ob sich dieser Vorteil in der Praxis auszahlt, hängt stark von der Größe und Komplexität der jeweiligen Infrastruktur ab, bei kleinen Repositories mit überschaubarer Ressourcenzahl fällt der Unterschied kaum ins Gewicht.

CI/CD-Integration: GitHub Actions, GitLab, Jenkins und Co.

In der Praxis entscheidet sich die Wahl eines Scanners oft nicht an der Policy-Liste, sondern daran, wie reibungslos sich das Tool in bestehende Pipelines einfügt. Checkov bringt mit der offiziellen GitHub Action bridgecrewio/checkov-action eine fertige Integration mit, dazu Support für GitLab CI über ein Container-Image, Jenkins über CLI oder Container, Azure Pipelines sowie Bitbucket Pipelines, CircleCI und Argo Workflows. Für Teams mit heterogener Toolchain ist das ein klarer Vorteil, weil eine einzige Konfigurationslogik für mehrere Pipeline-Typen funktioniert.

Trivy, der faktische Nachfolger von tfsec, bringt ebenfalls breite Integrationen für GitHub, GitLab und Jenkins mit und punktet zusätzlich damit, dass dieselbe Binärdatei neben IaC auch Container-Images und Software-Abhängigkeiten scannt. Wer bereits Trivy für Container-Scans im Einsatz hat, muss für die Terraform-Prüfung keine zweite Pipeline-Stage aufbauen, sondern aktiviert einfach den config-Scanner zusätzlich. Terrascan lässt sich technisch weiterhin in GitHub Actions, GitLab CI, Jenkins oder Azure DevOps einbinden, neue Integrationsarbeit sollte aber nicht mehr auf das archivierte Projekt aufsetzen, sondern direkt auf Checkov oder Trivy zielen.

Neben der reinen CI/CD-Pipeline spielt auch die lokale Entwicklerumgebung eine Rolle. Checkov lässt sich über Pre-Commit-Hooks einbinden, sodass ein Entwickler eine Fehlkonfiguration bereits vor dem Commit sieht, nicht erst Minuten später im Pipeline-Log. Trivy bietet eine vergleichbare Pre-Commit-Integration und zusätzlich eine VS-Code-Erweiterung von Aqua Security, die Fehlkonfigurationen direkt im Editor markiert. Für Terrascan existieren zwar ebenfalls Community-Pre-Commit-Konfigurationen, diese basieren aber auf demselben archivierten Regelstand und bringen entsprechend keine neuen Erkennungsmuster mehr mit, selbst wenn die Hook-Integration technisch funktioniert.

5 Praxisszenarien: Wer welches Tool wählt und warum

Statt einzelne Firmennamen zu nennen, die ihren genauen Tool-Stack selten öffentlich bestätigen, lohnt sich der Blick auf fünf typische Teamkonstellationen, wie sie Marktübersichten von Aikido und AppSecSanta beschreiben.

Kleines Startup-Team mit reinem Terraform-Stack: Schlanke Pipeline, ein Cloud-Anbieter, keine eigene Security-Abteilung. Hier reicht häufig Trivy im config-Modus, weil es ohnehin für Container-Scans läuft und Terraform direkt mit abdeckt.
Plattform-Team nach dem Terrascan-Aus: Teams, die seit Jahren auf Terrascan gesetzt haben, mussten seit November 2025 eine Migrationsentscheidung treffen. Viele wechseln zu Checkov, weil sich bestehende Kubernetes- und CloudFormation-Checks dort am direktesten abbilden lassen.
Multi-Cloud-Unternehmen mit gemischtem Stack: Terraform, Helm, ARM-Templates und Serverless-Konfigurationen parallel. Hier spricht die breite Formatunterstützung von Checkov für sich, weil ein einziges Tool alle Formate abdeckt statt mehrerer Spezialscanner.
Regulierte Branche mit Compliance-Pflicht: Banken- oder Versicherungs-IT, die CIS- oder PCI-Nachweise für Prüfer braucht. Hier zahlt sich die kommerzielle Prisma-Cloud-Schicht über Checkov aus, weil zentrale Dashboards und Audit-Reports über viele Repositories hinweg entstehen.
Open-Source-Projekt mit Fokus auf Container und IaC gemeinsam: Projekte, die ohnehin Container-Images bauen und scannen, konsolidieren auf Trivy, um Image-, Dependency- und IaC-Scan in einer einzigen Pipeline-Stage statt in drei getrennten Tools zu betreiben.

Ein wiederkehrendes Muster über alle fünf Szenarien hinweg: Je heterogener der Stack und je strenger die Compliance-Anforderung, desto eher fällt die Wahl auf Checkov, weil die breite Formatabdeckung und die zentrale Prisma-Cloud-Verwaltung den organisatorischen Aufwand reduzieren. Je stärker ein Team bereits auf Container-native Werkzeuge setzt, desto eher gewinnt Trivy, weil es den IaC-Scan ohne zusätzliche Pipeline-Stage mitliefert. Terrascan taucht in keinem der fünf aktuellen Szenarien mehr als Neuauswahl auf, sondern ausschließlich als Altlast, die abgelöst werden muss.

Vor- und Nachteile im Überblick

Checkov punktet mit der breitesten Formatabdeckung, der einzigen grafenbasierten Analyse im Vergleichsfeld und aktiver Weiterentwicklung durch Palo Alto Networks. Der Nachteil: Die Python-Basis macht das Tool bei sehr großen Repositories spürbar langsamer als schlankere, in Go geschriebene Scanner, und wer die volle Funktionsbreite inklusive zentraler Verwaltung will, landet schnell bei der kostenpflichtigen Prisma-Cloud-Schicht.

Checkov Vorteile: breiteste Formatabdeckung, einzige Graph-Analyse im Vergleich, aktive Weiterentwicklung, komplett kostenlose Kernversion, 80 Millionen+ Downloads laut AppSecSanta.
Checkov Nachteile: spürbar höherer Ressourcenverbrauch bei großen Monorepos, volle Enterprise-Funktionen nur über kostenpflichtige Prisma Cloud, Python-Abhängigkeiten müssen gepflegt werden.
Trivy (vormals tfsec) Vorteile: ein Tool für IaC-, Container-, Dependency- und Secret-Scans, mehr als 1.000 übernommene Terraform-Regeln, sehr aktive Entwicklung bei Aqua Security, schnelle Go-Binärdatei.
Trivy Nachteile: keine grafenbasierte, ressourcenübergreifende Analyse, für Teams mit reinem IaC-Fokus funktional überdimensioniert, Umstellung der tfsec-Konfigurationssyntax nötig.
Terrascan Vorteile: läuft technisch unverändert weiter, bestehende Pipelines müssen nicht sofort umgebaut werden, weiterhin kostenlos nutzbar.
Terrascan Nachteile: archiviert seit 20. November 2025, keine neuen Policies, keine Reaktion auf neue Cloud-Ressourcentypen, keine Sicherheitsupdates für das Projekt selbst, zunehmend kritisch bei Audits.

Trivy, der Nachfolger von tfsec, überzeugt in der Summe durch die Konsolidierung mehrerer Scan-Arten in einem Tool und durch die mehr als 1.000 übernommenen Terraform-Regeln. Der Nachteil liegt im fehlenden grafenbasierten Check und darin, dass Teams, die ausschließlich IaC scannen wollen, mit Trivy ein größeres, vielseitigeres Werkzeug einsetzen als unbedingt nötig. Terrascan schließlich punktet nur noch mit Bestandsschutz für bestehende Pipelines. Der entscheidende Nachteil überwiegt klar: Seit der Archivierung im November 2025 gibt es keine neuen Policies, keine Reaktion auf neue Cloud-Ressourcentypen und keine Sicherheitsupdates mehr für das Projekt selbst.

Für wen eignet sich welches Tool? Konkrete Empfehlungen

Die Wahl hängt stärker vom bestehenden Tech-Stack ab als von abstrakten Policy-Zahlen. Wer ein Tool völlig neu einführt, sollte zunächst prüfen, welche IaC-Formate im eigenen Unternehmen überhaupt im Einsatz sind, und erst danach die Frage nach Graph-Analyse oder Konsolidierung mit Container-Scans stellen. Die folgende Tabelle ordnet die drei Werkzeuge nach Einsatzszenario ein.

Szenario	Empfehlung	Begründung
Reiner Terraform-Stack, bereits Trivy im Einsatz	Trivy (config-Scanner)	Keine zusätzliche Pipeline-Stage nötig
Gemischter Stack (Terraform, Helm, ARM, Serverless)	Checkov	Breiteste Formatabdeckung aus einer Hand
Compliance-Nachweise für Prüfer/Auditoren	Checkov + Prisma Cloud	Zentrale Reports über viele Repositories
Bestehende Terrascan-Pipeline	Migration zu Checkov oder Trivy	Terrascan erhält keine neuen Regeln mehr
Kleines Team ohne dedizierte Security-Rolle	Checkov (Open Source) oder Trivy	Kostenlos, einfache CI/CD-Integration
Fokus auf ressourcenübergreifende Risiken	Checkov	Einziges Tool mit Graph-Analyse im Vergleich
Container- und IaC-Scan konsolidieren	Trivy	Ein Tool für Images, Dependencies und IaC

Compliance-Rahmenwerke: Wie CIS, PCI-DSS und NIST abgedeckt werden

Für viele Unternehmen entscheidet nicht die reine Regelzahl über die Tool-Wahl, sondern die Frage, ob sich ein Scan-Ergebnis direkt einem anerkannten Rahmenwerk zuordnen lässt. Checkov liefert dafür vorgefertigte Prüfpakete, die sich an CIS-Benchmarks für AWS, Azure und Google Cloud orientieren, zusätzlich an PCI-DSS-relevanten Kontrollen für Umgebungen mit Zahlungsdaten. Weil Checkov die Ergebnisse pro Ressource mit einer eindeutigen Check-ID ausgibt, lässt sich jede Policy einem konkreten Compliance-Punkt zuordnen, was Audit-Dokumentation erheblich vereinfacht.

Trivy bringt über die geerbten tfsec-Regeln ebenfalls CIS-orientierte Prüfungen mit und ergänzt sie um eigene Kontrollen, die ursprünglich für Container- und Kubernetes-Sicherheit entstanden sind, etwa Pod-Security-Standards. Das macht Trivy besonders für Teams interessant, die Compliance nicht nur auf Infrastrukturebene, sondern auch für Workloads und Images nachweisen müssen. Terrascan folgte historisch einem ähnlichen Ansatz über seine Rego-Policies, allerdings ohne dass seit der Archivierung neue regulatorische Anforderungen, etwa aus aktualisierten CIS-Benchmark-Versionen, noch einfließen. Für Unternehmen, die unter NIS2 oder vergleichbaren Vorgaben dokumentieren müssen, mit welchem Werkzeug und welchem Pflegestand ihre Infrastruktur geprüft wird, ist das ein Punkt, der in Audit-Gesprächen zunehmend zur Sprache kommt.

In deutschen und österreichischen Unternehmen kommt häufig noch eine zweite Anforderung dazu: der Nachweis gegenüber internen Datenschutzbeauftragten, dass personenbezogene Daten verarbeitende Systeme ausreichend abgesichert sind, bevor sie produktiv geschaltet werden. Ein IaC-Scanner ersetzt keine Datenschutz-Folgenabschätzung, kann aber als technischer Baustein in der Dokumentation dienen, wenn er nachweislich vor jedem Deployment lief und die Ergebnisse archiviert wurden. Checkov und Trivy unterstützen das über maschinenlesbare JSON- und SARIF-Exporte, die sich direkt in eine Compliance-Ablage einspeisen lassen, ohne dass ein Mitarbeiter Scan-Ergebnisse manuell zusammenfassen muss.

Grenzen von IaC-Scannern: Was Checkov, Trivy und Terrascan nicht abdecken

So nützlich diese drei Werkzeuge sind, sie lösen nicht jedes Sicherheitsproblem rund um Infrastructure as Code. Alle drei analysieren den deklarierten Code, nicht den tatsächlichen Zustand der Cloud-Umgebung nach dem Deployment. Ändert jemand eine Sicherheitsgruppe manuell über die AWS-Konsole, entsteht eine Abweichung, die keiner der drei Scanner automatisch bemerkt, weil sie nur beim nächsten Commit erneut greifen. Genau diese Lücke beschreibt der bereits erwähnte Firefly-Report, wenn er feststellt, dass weniger als ein Drittel der Unternehmen Drift kontinuierlich überwacht.

Ein zweiter blinder Fleck betrifft Geheimnisse wie API-Schlüssel oder Datenbank-Passwörter, die versehentlich im Klartext in einer Terraform-Variablen oder einem Terraform-State-File landen. Checkov und Trivy erkennen zwar offensichtliche Muster wie hartkodierte AWS-Zugangsschlüssel in Variablen, ein dediziertes Secret-Scanning über den gesamten Commit-Verlauf hinweg leisten spezialisierte Tools jedoch gründlicher. Wer eine vollständige Absicherung der Pipeline will, kombiniert einen IaC-Scanner deshalb sinnvollerweise mit einem Secret-Scanner und einer separaten Drift-Erkennung, statt sich auf ein einzelnes Tool als Rundum-Lösung zu verlassen.

Migrationsleitfaden: Weg von tfsec oder Terrascan

Der Umstieg von tfsec auf Trivy lässt sich in wenigen, klar abgrenzbaren Schritten durchziehen. Wichtig ist dabei, die alte und neue Konfiguration eine Zeit lang parallel laufen zu lassen, statt den Schnitt an einem einzigen Tag zu vollziehen.

Eine feste Trivy-Version in der CI/CD-Pipeline pinnen, nicht latest verwenden.
Den Befehl tfsec . durch trivy config . ersetzen und zunächst nur Terraform-Verzeichnisse scannen.
Mit trivy config --scanners misconfig --severity HIGH,CRITICAL . den bisherigen Scope nachbilden.
Ergebnisse von tfsec und Trivy auf einem Referenz-Repository parallel vergleichen.
Bestehende Inline-Suppressions aus tfsec manuell prüfen und auf Trivys Syntax übertragen, nicht automatisch übernehmen.
SARIF- oder JSON-Ausgabe beibehalten und CI-Annotationen entsprechend anpassen.
Findings erst nach Prüfung geänderter Regel-IDs und Schweregrade neu baselinen.
Die Pipeline zunächst nur bei High- und Critical-Findings fehlschlagen lassen, danach schrittweise verschärfen.
tfsec erst entfernen, wenn Trivy-Ergebnisse und Suppressions vollständig validiert sind.

Für den Wechsel von Terrascan läuft der Prozess ähnlich, braucht aber einen zusätzlichen Schritt für die Inventur bestehender Policies. Zunächst alle aktiven Terrascan-Policies, Schwellenwerte und Ausnahmen dokumentieren, dann einen Baseline-Export in JSON oder SARIF sichern. Anschließend Checkov oder Trivy parallel auf denselben Repositories laufen lassen und die Policy-Absicht abgleichen, nicht nur die Regel-IDs, weil gleichwertige Kontrollen bei unterschiedlichen Tools oft andere Bezeichnungen tragen. Die neue Pipeline-Stage startet im Warn-Modus, bevor sie produktiv blockierend geschaltet wird, und alte Terrascan-Reports bleiben für Audit-Zwecke archiviert, auch wenn das Tool selbst keine neuen Scans mehr liefert.

Markttrends: Wie groß ist der IaC-Security-Markt 2026?

Der globale Markt für Infrastructure-as-Code-Technologien lag laut unterschiedlichen Marktforschungsquellen 2025 zwischen rund 1,0 und 1,24 Milliarden US-Dollar und soll 2026 je nach Abgrenzung zwischen 1,2 und knapp 2 Milliarden US-Dollar erreichen. Übereinstimmend gehen mehrere Research-Häuser von einer jährlichen Wachstumsrate zwischen etwa 21,8 und 24,3 Prozent für die kommenden Jahre aus. Innerhalb dieses Marktes wächst der Teilbereich für dedizierte Security-Scanning-Plattformen überdurchschnittlich, weil Unternehmen zunehmend automatisierte Compliance-Prüfungen direkt in ihre CI/CD-Pipelines integrieren: Laut einer Erhebung von Marketintelo hatten bis 2026 rund 60 Prozent der Unternehmen mit IaC-Einsatz entsprechende automatisierte Checks eingebaut.

Gleichzeitig zeigt der State-of-IaC-Report 2025 des Anbieters Firefly eine Schwachstelle im Betrieb: Weniger als ein Drittel der Organisationen überwacht Konfigurations-Drift kontinuierlich, der Rest reagiert erst, wenn eine Abweichung bereits ein Problem verursacht hat. Ein Scanner, der vor dem Merge prüft, löst dieses Problem nur teilweise, weil Infrastruktur sich auch nach dem Deployment manuell oder über andere Automatisierungen verändern kann. Wer 2026 in IaC-Sicherheit investiert, sollte Pre-Merge-Scanning und Drift-Erkennung deshalb als zwei getrennte, sich ergänzende Bausteine behandeln.

Die Schätzungen zur Marktgröße schwanken zwischen den Research-Häusern spürbar, was vor allem daran liegt, dass manche Berichte den breiten IaC-Gesamtmarkt mit Tools wie Terraform und Pulumi selbst erfassen, während andere ausschließlich die Security-Scanning-Schicht darüber messen. Gminsights beziffert den IaC-Gesamtmarkt für 2025 auf rund eine Milliarde US-Dollar mit einer Wachstumsprognose bis 2035 auf 8,6 Milliarden US-Dollar, während ResearchAndMarkets für das engere GitOps-und-IaC-Softwaresegment 2025 bereits 1,96 Milliarden US-Dollar ansetzt. Für die hier verglichenen Scanner heißt das in der Praxis vor allem eines: Der Markt für automatisierte IaC-Prüfung wächst in jeder Lesart zweistellig, und Unternehmen, die jetzt auf ein archiviertes Tool wie Terrascan setzen, verpassen einen Markt, der sich in den kommenden Jahren spürbar weiterentwickelt.

Unser Urteil: Welcher Scanner gewinnt den Vergleich?

Auf Basis der verfügbaren Daten gibt es für Terrascan keinen Weg zurück: Eine Archivierung seit November 2025 bedeutet im Sicherheitskontext automatisch sinkenden Schutz, unabhängig davon, wie gut das Tool früher war. Teams sollten die Migration weg von Terrascan als abgeschlossene, nicht als offene Entscheidung behandeln.

Zwischen Checkov und Trivy fällt das Urteil differenzierter aus. Checkov gewinnt bei reiner IaC-Abdeckungsbreite und bei der einzigartigen grafenbasierten Analyse, die Risiken über mehrere Ressourcen hinweg erkennt, ein Punkt, den weder Trivy noch das eingefrorene Terrascan bieten. Trivy gewinnt dort, wo Teams ohnehin schon Container-Images oder Software-Abhängigkeiten scannen und eine Konsolidierung auf ein einziges Tool wichtiger ist als die letzte Policy mehr. Für die meisten Teams mit gemischten IaC-Formaten und Compliance-Anforderungen bleibt Checkov nach den vorliegenden Daten die solidere Wahl, für reine Container-First-Organisationen ist Trivy die pragmatischere.

Entscheidend ist am Ende weniger die Marke auf der CLI, sondern die Frage, ob ein Team den gewählten Scanner auch tatsächlich pflegt: Regeln aktuell hält, Ausnahmen regelmäßig überprüft und die Ergebnisse nicht nur protokolliert, sondern auch abarbeitet. Ein aktiv gepflegtes Tool mit halbherziger Nutzung schützt am Ende nicht besser als ein archiviertes Tool mit konsequenter Nachverfolgung. Die Daten aus diesem Vergleich liefern dafür die Grundlage, die Umsetzung bleibt Teamarbeit.

Häufig gestellte Fragen

Ist Terrascan jetzt komplett unbrauchbar?
Nein, die CLI funktioniert technisch weiter und liefert mit den zuletzt rund 500 Rego-Policies weiterhin Ergebnisse. Das Projekt erhält seit dem 20. November 2025 aber keine neuen Policies, CVE-Reaktionen oder Provider-Updates mehr, weshalb es für neue Sicherheitsanforderungen ungeeignet ist und schrittweise abgelöst werden sollte.

Muss ich tfsec sofort deinstallieren?
Nicht zwingend sofort, aber mittelfristig. Neue Regeln entstehen laut Aqua Security ausschließlich in Trivy, die alte tfsec-CLI bekommt keine inhaltliche Weiterentwicklung mehr. Ein harter Cutover an einem einzigen Tag ist selten nötig, ein geplanter Umstieg über mehrere Wochen mit Parallelbetrieb reduziert aber das Risiko falsch übertragener Ausnahmeregeln.

Ist Checkov wirklich komplett kostenlos?
Die CLI mit allen Policies ja. Kostenpflichtig wird es erst bei der Prisma-Cloud-Erweiterung mit zentralem Dashboard, Drift-Erkennung und Multi-Repo-Verwaltung.

Kann ich Checkov und Trivy parallel einsetzen?
Ja, einige Teams nutzen beide Scanner parallel während der Migrationsphase, um Findings abzugleichen, bevor sie sich endgültig auf ein Tool festlegen.

Welches Tool eignet sich am besten für Kubernetes-Manifeste?
Checkov deckt Kubernetes, Helm und Kustomize nativ ab und bietet dafür die breiteste Regelbasis unter den drei verglichenen Tools. Trivy prüft Kubernetes-Ressourcen ebenfalls, bringt den Vorteil aber vor allem dann, wenn dieselben Cluster bereits über Trivy auf Container-Image-Schwachstellen gescannt werden.

Gibt es eine offizielle, unabhängige Geschwindigkeitsmessung zwischen den Tools?
Nein, aktuell existiert kein öffentlicher Benchmark, der Checkov, Trivy und Terrascan unter identischen Bedingungen mit gleicher Hardware und denselben Repositories vergleicht.

Wie lange dauert eine Migration von Terrascan auf Checkov in der Praxis?
Das hängt von der Zahl der Repositories und individuellen Policies ab. Kleinere Teams mit wenigen Ausnahmen schaffen eine Parallelphase mit Vergleich und Umstellung oft innerhalb weniger Wochen.

Reicht ein einzelner Scanner, oder brauche ich zusätzlich Drift-Erkennung?
Ein Pre-Merge-Scanner wie Checkov oder Trivy prüft nur den Code vor dem Deployment. Laut dem State-of-IaC-Report 2025 von Firefly überwacht weniger als ein Drittel der Unternehmen Konfigurations-Drift nach dem Deployment kontinuierlich, ein Bereich, den ein reiner IaC-Scanner nicht abdeckt.

Checkov vs. tfsec vs. Terrascan: 500 Policies tot [2026]