Checkov: Fehlkonfigurationen in Infrastructure-as-Code vor dem Merge erkennen

Checkov, gepflegt von Bridgecrew im GitHub-Projekt bridgecrewio/checkov, ist ein Open-Source-Tool für statische Analyse, das Infrastructure-as-Code – Terraform, Terraform-Pläne, Kubernetes-Manifeste, CloudFormation, Helm-Charts, Bicep und mehrere andere Formate – auf Sicherheits- und Compliance-Fehlkonfigurationen prüft, bevor diese Infrastruktur überhaupt bereitgestellt wird.

Wo es in der Pipeline eines MSPs passt

Der natürliche Einsatzort von Checkov ist die Pull-Request-CI: Man führt es gegen einen Terraform-Plan oder ein Kubernetes-Manifest als Teil des Merge-Checks aus und behandelt einen Richtlinienverstoß als Merge-Blocker statt als Warnung, die später behoben werden kann. Die Prüfungen sind graphbasiert, das heißt, sie können Beziehungen zwischen Ressourcen verifizieren – zum Beispiel, dass eine EC2-Instanz tatsächlich an eine Netzwerkschnittstelle in einem VPC-Subnetz angeschlossen ist – anstatt nur die Attribute einer Ressource isoliert zu betrachten. Außerdem führt es eine grundlegende Erkennung von Secrets durch, erkennt bekannte Zugangsdatenformate wie AWS-Zugriffsschlüssel und markiert Strings mit hoher Entropie, die wie zufällig generierte Secrets aussehen.

Eine andere Disziplin als das Container-Scanning

Es lohnt sich, genau zu sagen, was Checkov nicht ist: Es scannt keine Container-Images oder Open-Source-Paketabhängigkeiten auf bekannte CVEs – das ist die Aufgabe von Tools wie Grype oder OSV-Scanner, die die meisten MSPs wahrscheinlich bereits irgendwo in ihrer Pipeline einsetzen. Checkovs Disziplin ist der Konfigurationsstatus im Infrastrukturcode selbst, bevor überhaupt eine Cloud-Ressource zum Scannen existiert. Beides zusammen ist komplementär, nicht redundant.

Die CLI ist unter der Apache-2.0-Lizenz kostenlos, ohne Scan-Limits oder Telemetrie-Einschränkungen bei den Ergebnissen, und wird mit offiziellen Integrationen für GitHub Actions, GitLab und JetBrains-IDEs ausgeliefert. Die Ergänzung in einer bestehenden Pipeline ist daher weitgehend eine Frage des Einbindens der Action, statt neue Infrastruktur aufzusetzen. Für MSPs, die IaC im Auftrag von Kunden betreiben, ist ein fail-closed Checkov-Gate in der CI ein günstiger Weg, einen öffentlichen S3-Bucket oder eine zu permissive Sicherheitsgruppe abzufangen, bevor sie überhaupt zum Einsatz kommen.

Quellen: GitHub — bridgecrewio/checkov.