Integration von Snyk und Bitbucket Pipelines für DevSecOps
Simon Maple
Field CTO bei Snyk
Umsetzung von DevSecOps-Prinzipien durch die Integration von Snyk in Bitbucket Pipelines
Zeit
Lesedauer: 5 Minuten.
Zielpublikum
Entwickler, Sicherheits-/Anwendungs-Teams und DevOps-/DevSecOps-Engineers.
Voraussetzungen
Du hast ein Synk-Konto. Lege hier los.
Du hast ein Bitbucket-Konto von Atlassian. Melde dich hier an oder lege hier los.
In diesem Tutorial wird beschrieben, wie du deinen Build-Workflow mit Snyk auf Bitbucket Pipelines sichern kannst. Ein wichtiger Schritt zur Sicherung deiner Umgebung besteht darin, sowohl deine Anwendung als auch dein Linux-basiertes Containerprojekt auf bekannte Schwachstellen zu scannen. So kannst du Sicherheitsschwachstellen einfacher identifizieren und mildern. Die Übungen in diesem Tutorial helfen dabei, deine Anwendung und deinen Container zu sichern, indem du Snyk Pipe for Bitbucket Pipelines nutzt. Damit kannst du die Anwendungsmanifestdatei und das Container-Basisimage auf gegenseitige Abhängigkeiten hin untersuchen.
Der Schwerpunkt des Tutorials So unterstützen Snyk und Bitbucket Cloud DevSecOps waren Abhängigkeiten von Anwendungen. Wenn du jedoch dein Container-Basisimage scannst, kannst du Folgendes erkennen:
- Die vom Paket-Manager installierten und verwalteten Betriebssystempakete
- Schlüsselbinärdateien: Das sind Layer, die nicht über den Paket-Manager installiert wurden.
Basierend auf diesen Ergebnissen bietet Snyk unter anderem folgende Ratschläge und Hinweise:
- Ursprung von Schwachstellen in Betriebssystempaketen und wichtigen Binärdateien
- Details zum Basisimage-Upgrade oder eine Empfehlung zum Neuaufbau des Image
- Dockerfile-Ebene, auf der das betroffene Paket eingeführt wurde
- Feste Version des Betriebssystems und wichtige Binärdateipakete
Scannen von Anwendungen in Bitbucket Pipeline
Die Datei bitbucket-pipelines.yml definiert die Konfiguration deiner Builds für Bitbucket Pipelines. Wenn du erst mit Bitbucket Pipelines anfängst, kannst du hier mehr über die ersten Schritte erfahren.
Dieses Tutorial bietet die Beispieldatei bitbucket-pipelines.yml, die verschiedene Schritte im Zusammenhang mit dem Workflow enthält. Wir scannen zunächst die Anwendung, erstellen das Docker-Image und scannen dann das Container-Image. Im Folgenden gehen wir näher auf den Schritt zum Scannen der Anwendung ein:
scan-app: &scan-app
- step:
name: "Scan open source dependencies"
caches:
- node
script:
- pipe: snyk/snyk-scan:0.4.3
variables:
SNYK_TOKEN: $SNYK_TOKEN
LANGUAGE: "npm"
PROJECT_FOLDER: "app/goof"
TARGET_FILE: "package.json"
CODE_INSIGHTS_RESULTS: "true"
SEVERITY_THRESHOLD: "high"
DONT_BREAK_BUILD: "true"
MONITOR: "false"In diesem Beispiel wird die Snyk Scan-Pipe in der Pipeline verwendet, um einen Scan der Anwendung durchzuführen. Die Quelle enthält eine vollständige YAML-Definition aller unterstützten Variablen, für diesen Zweck sind aber nur die in diesem Ausschnitt enthaltenen erforderlich.
Hier sehen wir uns einige davon genauer an:
1. SNYK_TOKEN wird als Repository-Variable an die Pipe übergeben, die zuvor im Modul [Bitbucket-Konfiguration] definiert wurde.
2. PROJECT_FOLDER ist der Ordner, in dem sich das Projekt befindet und in den es normalerweise abgelegt wird. In diesem Beispiel setzen wir die Variable jedoch auf app/goof und übergeben das als Artefakt an andere Schritte in der Pipeline.
3. CODE_INSIGHTS_RESULTS ist standardmäßig als false (falsch) gesetzt. Da wir jedoch einen Code Insights-Bericht mit Snyk-Testergebnissen erstellen möchten, ändern wir den Wert auf true (wahr).
4. SEVERITY_THRESHOLD meldet Probleme, die der angegebenen Ebene oder den Ebenen darüber entsprechen. Die Standardeinstellung ist low (niedrig). In diesem Fall sind wir jedoch nur an Ergebnissen für high (hoch) interessiert, daher definieren wir diese Variable entsprechend.
5. Der Standardwert DONT_BREAK_BUILD ist false (falsch), was zu erwarten ist. Unter normalen Umständen will man den Build-Vorgang unterbrechen, wenn Probleme erkannt werden. Zu Übungszwecken stellen wir den Wert aber auf true (wahr).
Du kannst die neue Snyk Security Connect-App aus dem Atlassian Marketplace nutzen, um Snyk-Sicherheitsscans für deine Pull-Anfragen auszuführen und die Ergebnisse in Code Insights anzeigen lassen. Der Einstieg ist ganz einfach und du kannst die App mit nur wenigen Klicks installieren.
Scannen der Container-Images
Bis 2022 werden mehr als 75 % der globalen Unternehmen containerisierte Anwendungen in der Produktion ausführen (Gartner). Infolge der breiten Übernahme hat sich die Anzahl der Sicherheitslücken in Containern erhöht. Im Jahr 2018 wurde ein vierfacher Anstieg der Sicherheitslücken in Betriebssystemen gemeldet. Trotzdem geben 80 % der Entwickler zu, dass sie ihre Container-Images während der Entwicklung nicht testen. Entweder betrachten sie es nicht als ihre Aufgabe oder sie gehen davon aus, dass andere zu einem späteren Zeitpunkt Probleme entdecken. Das macht die Skalierung der Containersicherheit zu einer Herausforderung für schnell wachsende Unternehmen.
Scannen von Container-Images in deiner Pipeline
Ähnlich wie im vorherigen Abschnitt über Anwendungsscans konzentriert sich dieser Abschnitt auf die Konfiguration der Datei bitbucket-pipelines.yml, mit der das Docker-Image für die Anwendung erstellt, gescannt und dann an die Registry übertragen wird. Im Folgenden betrachten wir den Schritt zum Scannen von Container-Images etwas genauer:
scan-push-image: &scan-push-image
- step:
name: "Scan and push container image"
services:
- docker
script:
- docker build -t $IMAGE ./app/goof/
- docker tag $IMAGE $IMAGE:${BITBUCKET_COMMIT}
- pipe: snyk/snyk-scan:0.4.3
variables:
SNYK_TOKEN: $SNYK_TOKEN
LANGUAGE: "docker"
IMAGE_NAME: $IMAGE
PROJECT_FOLDER: "app/goof"
TARGET_FILE: "Dockerfile"
CODE_INSIGHTS_RESULTS: "true"
SEVERITY_THRESHOLD: "high"
DONT_BREAK_BUILD: "true"
MONITOR: "false"Hierdurch wird das Container-Image erstellt und gekennzeichnet. Dann wird die Snyk Scan-Pipe in der Pipeline genutzt, um einen Scan des Container-Images durchzuführen. Behalte dieselben Werte für CODE_INSIGHTS_RESULTS, SEVERITY_THRESHOLD und DONT_BREAK_BUILD bei. Dadurch werden einige zusätzliche unterstützte Variablen übergeben, die für die Snyk-Pipe relevant sind, weil damit die Anforderung eines Container-Image-Scans anstelle eines Anwendungsscans nachvollzogen werden kann. Dazu wird LANGUAGE (Sprache) auf docker gesetzt, ein IMAGE_NAME (Image-Name) angegeben, die entsprechende Repository-Variable übergeben und die Variable TARGET_FILE (Zieldatei) als Dockerfile festgelegt.
Deine Pipeline durchsucht jetzt das Container-Image und deinen Anwendungscode nach bekannten Schwachstellen.
Weitere Integrationen für Atlassian Open DevOps anzeigen
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
DevOps-Community
DevOps-Lernpfad
