Warum Ihre Pipeline Sicherheit und Compliance prüfen sollte

Wenn Ihr Team zum ersten Mal eine CI/CD-Pipeline aufsetzt, sind die Checks, die Sie hinzufügen, meist die offensichtlichen technischen: Kompiliert der Code? Bestehen die Unit-Tests? Startet die Anwendung? Das ist sinnvoll. In dieser Phase sind die größten Probleme Code, der bricht, und Features, die nicht funktionieren.

Sobald jedoch echte Nutzer Ihre Anwendung verwenden, tauchen neue Fragen auf. Hat dieser Code ein Sicherheitsloch? Hat diese Bibliothek eine bekannte Schwachstelle? Folgt die Serverkonfiguration den Unternehmensrichtlinien? Hat jemand versehentlich ein Passwort committed?

Die meisten Teams beantworten diese Fragen manuell. Ein Sicherheitsteam führt regelmäßige Audits durch. Jemand füllt vor jedem Release eine Compliance-Checkliste aus. Dieser manuelle Ansatz hat drei Probleme.

Erstens finden die Checks statt, nachdem der Code fertig ist, manchmal sogar nachdem er bereits in Produktion ist. Wenn Sie ein Problem finden, bedeutet die Behebung Hin und Her zwischen Entwicklungsteam und Sicherheitsteam. Das ist teuer und langsam.

Zweitens sind manuelle Checks inkonsistent. Dieselbe Person kann an verschiedenen Tagen unterschiedliche Dinge übersehen. Zwei Personen können dieselbe Regel unterschiedlich interpretieren.

Drittens können manuelle Prozesse nicht mithalten, wenn Ihr Team mehrmals täglich ausrollt. Der Engpass verschiebt sich vom Schreiben von Code zum Warten auf Freigaben und Checklisten.

Die Pipeline als automatisierter Gatekeeper

Aus diesem Grund müssen Sicherheits- und Compliance-Checks in Ihrer Pipeline leben. Die Idee ist einfach: Jedes Mal, wenn jemand eine Änderung pusht, führt die Pipeline dieselben Checks auf dieselbe Weise durch und liefert konsistente Ergebnisse.

Wenn es eine Sicherheitslücke gibt, informiert Sie die Pipeline, bevor der Code in Produktion geht. Wenn eine Konfiguration gegen Unternehmensrichtlinien verstößt, stoppt die Pipeline den Prozess, bevor sich das Problem ausbreitet.

Es geht nicht darum, Ihr Sicherheitsteam zu ersetzen. Es geht darum, die offensichtlichen Probleme automatisch zu erkennen, damit sich das Sicherheitsteam auf die schwierigeren Fragen konzentrieren kann, die menschliches Urteilsvermögen erfordern.

Das Geschwindigkeitsproblem

Viele Teams befürchten, dass zusätzliche Sicherheitschecks die Pipeline verlangsamen. Diese Sorge ist berechtigt, aber das Problem sind nicht die Checks selbst. Das Problem ist, jeden Check bei jedem Commit auszuführen, ohne zu überlegen, welche Checks wann relevant sind.

Einen vollständigen Dependency-Vulnerability-Scan, der fünfzehn Minuten dauert, bei jedem einzelnen Commit auszuführen, wird Ihre Entwickler definitiv frustrieren. Aber denselben schweren Scan einmal täglich oder nur vor dem Merge in den Hauptbranch auszuführen, hat minimale Auswirkungen auf die Entwicklungsgeschwindigkeit.

Der Schlüssel liegt darin, schnelle von langsamen Checks zu trennen.

Schnelle Checks sind in Sekunden abgeschlossen. Das Scannen nach versehentlich committeden Secrets dauert kaum Zeit. Die Prüfung, ob Bibliothekslizenzen akzeptabel sind, ist ebenso schnell. Diese Checks sollten bei jedem Commit laufen. Sie erkennen Probleme frühzeitig und sind günstig genug, dass niemand die Verzögerung bemerkt.

Langsame Checks dauern Minuten oder länger. Das Scannen von Abhängigkeiten gegen eine Schwachstellendatenbank erfordert das Herunterladen und Vergleichen von Daten. Das Scannen von Container-Images auf bekannte CVEs umfasst die Analyse von Layern und installierten Paketen. Diese Checks sind wertvoll, müssen aber nicht bei jedem Code-Push laufen. Führen Sie sie aus, wenn jemand einen Pull-Request öffnet, oder vor dem Deployment in eine Staging-Umgebung.

Wie Sicherheitschecks in einer Pipeline tatsächlich aussehen

Machen wir das konkret. Hier sind die gängigen Kategorien von Sicherheits- und Compliance-Checks, die in eine Pipeline gehören:

Secret Scanning. Tools, die API-Keys, Passwörter, Tokens und Zertifikate im Repository erkennen. Diese laufen schnell und sollten bei jedem Commit ausgeführt werden. Wenn jemand versehentlich eine Anmeldeinformation committed, möchten Sie das sofort wissen, nicht erst, wenn der Code in Produktion ist.

Dependency Scanning. Checks, die die Abhängigkeiten Ihres Projekts mit Datenbanken bekannter Schwachstellen vergleichen. Sie zeigen an, ob eine von Ihnen verwendete Bibliothek ein veröffentlichtes CVE hat. Führen Sie diese bei Pull-Requests und vor Produktions-Deployments aus.

Static Application Security Testing (SAST). Tools, die Ihren Quellcode auf Sicherheitsmuster analysieren, ohne den Code auszuführen. Sie suchen nach SQL-Injection-Risiken, Cross-Site-Scripting-Schwachstellen, unsicheren kryptografischen Funktionen und ähnlichen Problemen. SAST-Tools variieren in der Geschwindigkeit, aber viele können bei angemessen großen Codebasen innerhalb von ein bis zwei Minuten laufen.

Container Image Scanning. Wenn Sie Container-Images bauen, scannen Sie diese auf Schwachstellen im Basis-Image und in installierten Paketen. Dies erfasst Probleme in der Betriebssystemschicht und Laufzeitabhängigkeiten, die Ihr Anwendungscode nicht direkt verwaltet.

So sieht ein Container-Image-Scan-Schritt in einem GitHub Actions-Workflow aus:

- name: Scan container image for vulnerabilities
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'my-app:${{ github.sha }}'
    format: 'table'
    exit-code: '1'
    severity: 'CRITICAL,HIGH'

Dieser Schritt führt Trivy gegen das gebaute Image aus, gibt eine Tabelle mit Ergebnissen aus und lässt den Job fehlschlagen, wenn kritische oder hohe Schwachstellen gefunden werden. Das exit-code: '1' stellt sicher, dass die Pipeline stoppt und als automatisierter Gatekeeper fungiert.

Infrastructure as Code Scanning. Wenn Sie Infrastruktur mit Terraform, CloudFormation oder ähnlichen Tools definieren, scannen Sie diese Definitionen auf Fehlkonfigurationen. Dinge wie offene Sicherheitsgruppen, unverschlüsselter Speicher oder zu permissive IAM-Richtlinien.

License Compliance. Prüfung, ob die Lizenzen Ihrer Abhängigkeiten mit der Lizenzierung Ihres Projekts und den Unternehmensrichtlinien kompatibel sind. Dies ist besonders wichtig für kommerzielle Produkte oder Projekte, die extern verteilt werden.

Ein praktischer Ansatz für den Einstieg

Sie müssen nicht alle diese Checks auf einmal implementieren. Beginnen Sie mit den Checks, die Ihre unmittelbarsten Risiken adressieren.

Wenn Ihr Team bereits versehentlich Secrets committed hat, beginnen Sie mit Secret Scanning. Wenn Sie von einer verwundbaren Bibliothek überrascht wurden, beginnen Sie mit Dependency Scanning. Wenn Ihr Infrastrukturteam Fehlkonfigurationen in der Produktion gefunden hat, beginnen Sie mit IaC-Scanning.

Fügen Sie Checks inkrementell hinzu. Führen Sie die schnellen Checks bei jedem Commit aus. Planen Sie die langsamen Checks zum Zeitpunkt des Pull-Requests oder vor Staging-Deployments ein. Lassen Sie die Pipeline Sie informieren, wenn ein Check fehlschlägt, und stellen Sie sicher, dass die Fehlermeldung klar genug ist, damit der Entwickler weiß, was zu beheben ist.

Eine kurze Checkliste für Ihre Pipeline

• Secret Scanning läuft bei jedem Commit
• Dependency Scanning läuft bei Pull-Requests und vor Produktions-Deployment
• SAST läuft bei Pull-Requests
• Container Image Scanning läuft vor Staging-Deployment
• Infrastructure as Code Scanning läuft bei Infrastrukturänderungen
• License Compliance läuft bei Pull-Requests
• Schnelle Checks (Sekunden) laufen bei jedem Commit
• Langsame Checks (Minuten) laufen bei Pull-Request oder vor Staging

Der wahre Wert

Sicherheits- und Compliance-Checks in Ihrer Pipeline sind keine zusätzliche Bürokratie, die Sie ausbremst. Sie sind Leitplanken, die Ihrem Team ermöglichen, schneller und mit Vertrauen zu arbeiten. Wenn jede Änderung dieselben automatisierten Checks besteht, müssen Sie nicht rätseln, ob dieses Release eine bekannte Schwachstelle hat oder gegen Unternehmensrichtlinien verstößt. Die Pipeline hat diese Fragen bereits beantwortet.

Ihr Team kann sich auf das Entwickeln von Features und das Beheben von Bugs konzentrieren, in dem Wissen, dass die grundlegenden Sicherheits- und Compliance-Filter automatisch, konsistent und sofort laufen. Das ist der Unterschied zwischen der Hoffnung, dass nichts schiefgeht, und dem Wissen, dass nichts Offensichtliches schiefgegangen ist.