Verwendung des Snyk-Vulnerabilitäts-Scanning-Tools

Einführung

Snyk wurde entwickelt, um als Sicherheitsplattform für Entwickler mit Flexibilität zu dienen. Ihr Hauptziel ist es, Ihnen dabei zu helfen, Schwachstellen in Ihrem Anwendungsquellcode, in Abhängigkeiten von Drittanbietern, Container-Images und Infrastrukturkonfigurationsdateien (z. B. Kubernetes, Terraform usw.) zu erkennen und zu beheben.

Snyk ist in vier Komponenten unterteilt:

1. Snyk Code – hilft Ihnen dabei, Schwachstellen in Ihrem Anwendungsquellcode zu finden und zu beheben.
2. Snyk Open Source – hilft Ihnen dabei, Schwachstellen in beliebigen Bibliotheken oder Abhängigkeiten von Drittanbietern zu finden und zu beheben, auf die Ihre Anwendung angewiesen ist.
3. Snyk Container – hilft Ihnen dabei, Schwachstellen in Container-Images oder Kubernetes-Workloads zu finden und zu beheben, die in Ihrem Cluster verwendet werden.
4. Snyk Infrastructure as Code – hilft Ihnen dabei, Fehlkonfigurationen in Ihren Kubernetes-Manifesten zu finden und zu beheben (Terraform, CloudFormation und Azure werden ebenfalls unterstützt).

Snyk kann auf verschiedene Arten ausgeführt werden:

• Über die Befehlszeilenschnittstelle mit Snyk CLI. Dies ist die bevorzugte Methode, um sie in Skripten und verschiedenen Automatisierungen, einschließlich CI/CD-Pipelines, auszuführen.
• Im Browser als Snyk Web UI. Snyk bietet auch eine Cloud-basierte Plattform an, mit der Sie Scan-Berichte untersuchen, Hinweise erhalten und erforderliche Maßnahmen zur Behebung gemeldeter Probleme ergreifen können usw. Sie können auch GitHub-Repositories verbinden und Scans/Audits über die Web-Benutzeroberfläche durchführen.
• Über IDE-Plugins. Auf diese Weise können Sie Probleme frühzeitig erkennen, während Sie mit Ihrer bevorzugten IDE (z. B. Visual Studio Code) entwickeln.
• Programmgesteuert über die Snyk API. Die Snyk-API steht Kunden mit bezahlten Plänen zur Verfügung und ermöglicht es Ihnen, sich programmgesteuert mit Snyk zu integrieren.

Ist Snyk kostenlos?

Ja, die Tools sind kostenlos, außer der Snyk API und einigen erweiterten Funktionen der Web-Benutzeroberfläche (wie erweiterte Berichterstellung). Es gibt auch eine Begrenzung für die Anzahl der Tests, die Sie pro Monat durchführen können.

Sehen Sie sich die Preispläne für weitere Informationen an.

Ist Snyk Open Source?

Ja, die Tools und sicherlich Snyk CLI sind es. Sie können die Snyk GitHub-Startseite besuchen, um weitere Details zur Implementierung jedes einzelnen Komponenten zu finden. Das Cloud-Portal und alle kostenpflichtigen Funktionen wie die Implementierung der REST-API sind nicht Open Source.

Ein weiterer wichtiger Satz von Konzepten, den Snyk verwendet, sind Ziele und Projekte.

Ziele repräsentieren eine externe Ressource, die Snyk durch eine Integration, die Befehlszeilenschnittstelle (CLI), die Benutzeroberfläche (UI) oder die API gescannt hat. Beispiele für Ziele sind ein SCM-Repository, eine Kubernetes-Workload usw.

Projekte hingegen definieren die Elemente, die Snyk bei einem bestimmten Ziel scannt. Ein Projekt umfasst:

• A scannable item external to Snyk.
• Konfiguration, um zu definieren, wie dieser Scan ausgeführt werden soll.

Mehr über die Kernkonzepte von Snyk erfahren Sie hier.

In diesem Leitfaden verwenden Sie Snyk CLI, um eine Risikoanalyse für Ihre Kubernetes-Anwendungslieferkette (Container-Images, Kubernetes-YAML-Manifeste) durchzuführen. Anschließend erfahren Sie, wie Sie die entsprechenden Maßnahmen ergreifen, um die Situation zu beheben. Schließlich lernen Sie, wie Sie Snyk in eine CI/CD-Pipeline integrieren, um frühzeitig im Entwicklungsprozess nach Sicherheitslücken zu scannen.

Inhaltsverzeichnis

• Einführung
• Anforderungen
• Schritt 1 – Kennenlernen des Snyk CLI
• Schritt 2 – Kennenlernen der Snyk-Webbenutzeroberfläche
  • Verständnis der Snyk-Schweregradstufen
  • Unterstützte Fehlerbehebung für gemeldete Sicherheitsprobleme
• Schritt 3 – Verwendung von Snyk zum Scannen nach Kubernetes-Konfigurationsschwachstellen in einem CI/CD-Pipeline
  • Implementierung des GitHub Actions CI/CD-Workflows
• Schritt 4 – Untersuchung der Snyk-Scanergebnisse und Behebung gemeldeter Probleme
  • Untersuchung und Behebung von Sicherheitslücken in Container-Images
  • Untersuchung und Behebung von Sicherheitslücken in Kubernetes-Manifesten
  • Überwachen Sie Ihre Projekte regelmäßig
  • Ausnahmen behandeln
  • Snyk für IDEs
• Schritt 5 – Auslösen des Snyk CI/CD-Workflows automatisch
• Schritt 6 – Aktivierung von Slack-Benachrichtigungen
• Fazit
• Zusätzliche Ressourcen

Voraussetzungen

Um alle Schritte dieses Leitfadens abzuschließen, benötigen Sie:

1. A working DOKS cluster running Kubernetes version >=1.21 that you have access to. For additional instructions on configuring a DigitalOcean Kubernetes cluster, see: How to Set Up a DigitalOcean Managed Kubernetes Cluster (DOKS).
2. A DigitalOcean Docker Registry. A free plan is enough to complete this tutorial. Also, make sure it is integrated with your DOKS cluster as explained here.
3. Kubectl-CLI für die Interaktion mit Kubernetes. Befolgen Sie diese Anleitungen, um sich mit Ihrem Cluster über kubectl und doctl zu verbinden.
4. Snyk CLI zur Interaktion mit dem Snyk-Schwachstellen-Scanner.
5. A free Snyk cloud account account used to periodically publish scan results for your Kubernetes cluster to a nice dashboard. Also, the Snyk web interface helps you with investigations and risk analysis. Please follow How to Create a Snyk Account documentation page.
6. A Slack workspace you own, and a dedicated Slack app to get notified of vulnerability scan issues reported by Snyk.

Schritt 1 – Kennenlernen der Snyk-Befehlszeilenschnittstelle

Sie können manuell nach Schwachstellen über die Befehlszeilenschnittstelle snyk scannen. Die Snyk CLI ist darauf ausgelegt, in verschiedenen Skripten und Automatisierungen verwendet zu werden. Ein praktisches Beispiel ist eine CI/CD-Pipeline, die mit verschiedenen Tools wie Tekton, Jenkins, GitHub Workflows usw. implementiert ist.

Wenn die Snyk CLI aufgerufen wird, startet sie sofort den Scanvorgang und meldet Probleme in einem bestimmten Format zurück. Standardmäßig wird eine Zusammenfassungstabelle über die Standardausgabe oder die Konsole ausgegeben. Snyk kann auch Berichte in anderen Formaten generieren, wie z.B. JSON, HTML, SARIF usw.

Sie können wählen, die Ergebnisse über das Snyk Cloud-Portal (oder die Web-Oberfläche) mithilfe des --report-Flags zu speichern und später anzuzeigen.

Die Snyk CLI ist in mehrere Unterbefehle unterteilt. Jeder Unterbefehl ist einem bestimmten Feature gewidmet, wie zum Beispiel:

• Open-Source-Scannen – identifiziert aktuelle Projektabhängigkeiten und meldet gefundene Sicherheitsprobleme.
• Code-Scannen – meldet Sicherheitsprobleme, die im Quellcode Ihrer Anwendung gefunden wurden.
• Bild-Scannen – meldet Sicherheitsprobleme, die in Containerbildern (z.B. Docker) gefunden wurden.
• Scannen von Infrastruktur als Code-Dateien – meldet Sicherheitsprobleme, die in Konfigurationsdateien gefunden wurden, die von Kubernetes, Terraform usw. verwendet werden.

Bevor Sie fortfahren, stellen Sie bitte sicher, dass Sie ein kostenloses Konto über die Snyk-Web-Oberfläche erstellen. Außerdem muss die Snyk-Befehlszeilenschnittstelle ebenfalls mit Ihrem Cloud-Konto authentifiziert werden, damit einige Befehle/Unterbefehle funktionieren (z.B. snyk code test).

A few examples to try with Snyk CLI:

1. Open-Source-Scannen:

# Scannen Sie den Quellcode Ihres Projekts aus dem aktuellen Verzeichnis
snyk test
# Scannen Sie einen bestimmten Pfad aus Ihrem Projektverzeichnis (stellen Sie sicher, dass Sie die Platzhalter `<>` entsprechend ersetzen)
snyk test <path/to/dir>

2. Code-Scannen:

# Scannen Sie Ihren Projektcode vom aktuellen Verzeichnis aus
snyk code test

# Scannen Sie einen bestimmten Pfad aus Ihrem Projektverzeichnis (stellen Sie sicher, dass Sie die Platzhalter `<>` entsprechend ersetzen)
snyk code test <path/to/dir>

3. Bildscannen:

# Scannen Sie das Debian-Docker-Image, indem Sie es zuerst herunterladen
snyk container debian

# Geben Sie dem Scanner mehr Kontext, indem Sie ein Dockerfile bereitstellen (stellen Sie sicher, dass Sie die Platzhalter `<>` entsprechend ersetzen)
snyk container debian --file=<path/to/dockerfile>

4. Scannen von Infrastruktur als Code:

# Scannen Sie Ihren Projektcode vom aktuellen Verzeichnis aus
snyk iac test

# Scannen Sie einen bestimmten Pfad aus Ihrem Projektverzeichnis (stellen Sie sicher, dass Sie die Platzhalter `<>` entsprechend ersetzen)
snyk iac test <path/to/dir>

# Scannen von Kustomize-basierten Projekten (zuerst müssen Sie die endgültige Vorlage rendern und sie dann an den Scanner übergeben)
kustomize build > kubernetes.yaml
snyk iac test kubernetes.yaml

Der Snyk CLI bietet Hilfeseiten für alle verfügbaren Optionen. Der folgende Befehl kann verwendet werden, um die Haupt-Hilfeseite auszugeben:

snyk --help

Die Ausgabe sieht ähnlich aus wie:

Output
CLI commands help
  Snyk CLI scans and monitors your projects for security vulnerabilities and license issues.

  For more information visit the Snyk website https://snyk.io

  For details see the CLI documentation https://docs.snyk.io/features/snyk-cli

How to get started
  1. Authenticate by running snyk auth
  2. Test your local project with snyk test
  3. Get alerted for new vulnerabilities with snyk monitor

Available commands
  To learn more about each Snyk CLI command, use the --help option, for example, snyk auth --help or 
  snyk container --help

  snyk auth
    Authenticate Snyk CLI with a Snyk account.

  snyk test
    Test a project for open source vulnerabilities and license issues.

Jeder Snyk CLI-Befehl (oder Unterbefehl) hat auch eine zugehörige Hilfeseite, die über snyk [Befehl] --help aufgerufen werden kann.

Bitte besuchen Sie die offizielle Snyk CLI-Dokumentationsseite für weitere Beispiele.

Schritt 2 – Kennenlernen der Snyk Web-Benutzeroberfläche

Nachdem Sie sich für ein Snyk-Konto registriert, sich authentifiziert und bei Snyk angemeldet haben, öffnet sich die Web-Benutzeroberfläche zum Dashboard mit einem Assistenten, der Sie durch die Einrichtungsschritte führt:

• Festlegen, wo sich der Code befindet, den Sie in Snyk überwachen möchten.
• Definieren, welche Projekte innerhalb Ihres Codes Sie möchten, dass Snyk sie überprüft.
• Verbindung von Snyk mit den relevanten Projekten, um sie zu überprüfen.
• Überprüfung der Ergebnisse Ihres Snyk-Scans.

Die folgenden Funktionen stehen über die Web-Benutzeroberfläche zur Verfügung:

• Dashboard erkunden
• Berichte untersuchen
• Projekte verwalten
• Integrationen verwalten
• Gruppen- oder Organisationsmitglieder verwalten
• Zeige Snyk-Updates
• Holen Sie sich Hilfe
• Verwalten Sie Ihr Benutzerkonto

Bitte besuchen Sie die offizielle Dokumentationsseite, um mehr über die Snyk-Webbenutzeroberfläche zu erfahren.

Verständnis der Snyk-Schweregradstufen

Bei jedem Scan überprüft snyk Ihre Ressourcen auf potenzielle Sicherheitsrisiken und wie sich jedes Risiko auf Ihr System auswirkt. Ein Schweregrad wird einer Schwachstelle zugewiesen, um das Risiko dieser Schwachstelle in einer Anwendung anzugeben.

Schweregrade können einen der folgenden Werte annehmen:

• Niedrig: Die Anwendung kann einige Daten preisgeben, die zur Zuordnung von Schwachstellen verwendet werden können, die zusammen mit anderen Schwachstellen zur Angriffsausführung auf die Anwendung verwendet werden können.
• Mittel: Kann Angreifern unter bestimmten Bedingungen den Zugriff auf sensible Daten Ihrer Anwendung ermöglichen.
• Hoch: Kann Angreifern den Zugriff auf sensible Daten Ihrer Anwendung ermöglichen.
• Kritisch: Kann Angreifern den Zugriff auf sensible Daten ermöglichen und das Ausführen von Code in Ihrer Anwendung ermöglichen.

Das Common Vulnerability Scoring System (CVSS) bestimmt das Schweregradniveau einer Schwachstelle. Snyk verwendet das CVSS-Framework Version 3.1, um die Eigenschaften und den Schweregrad von Schwachstellen zu kommunizieren.

Die untenstehende Tabelle zeigt die Zuordnung für jedes Schweregradniveau:

In diesem Leitfaden wird der Schwellenwert für das Niveau mittel als Standardwert im verwendeten Beispiel-CI/CD-Pipeline verwendet. In der Regel möchten Sie zunächst hoch- und kritische Probleme bewerten, aber in einigen Fällen erfordert auch das mittlere Niveau Aufmerksamkeit. In Bezug auf Sicherheit und als Faustregel möchten Sie normalerweise sehr streng sein.

Bitte besuchen Sie die offizielle Dokumentation-Seite, um mehr über Schweregrade zu erfahren.

Unterstützte Behebung für gemeldete Sicherheitsprobleme

Eine weitere nützliche Funktion, die von der Snyk-Webbenutzeroberfläche bereitgestellt wird, ist die Unterstützung bei der Behebung von Sicherheitsproblemen. Das bedeutet, dass Sie eine Empfehlung erhalten, wie Sie jedes Sicherheitsproblem beheben können, das vom snyk-Scanner gefunden wurde. Dies ist sehr wichtig, da es den Prozess vereinfacht und den Zyklus für jede Iteration schließt, die Sie durchführen müssen, um jedes gemeldete Sicherheitsproblem zu beheben.

Das untenstehende Bild veranschaulicht diesen Prozess besser:

Für jede gemeldete Problem gibt es eine Schaltfläche, auf die Sie klicken können, um Unterstützung bei der Fehlerbehebung zu erhalten:

Das Hauptverfahren ist für jedes gemeldete Problem gleich. Das bedeutet, dass Sie auf die Schaltfläche „Details anzeigen“ klicken und dann die vorgeschlagenen Schritte ausführen, um die Lösung anzuwenden.

Schritt 3 – Verwendung von Snyk zum Scannen von Kubernetes-Konfigurationsschwachstellen in einem CI/CD-Pipeline

Wie profitieren Sie davon, ein Sicherheits-Compliance-Scanning-Tool in Ihre CI/CD-Pipeline zu integrieren und unangenehme Situationen in einer Produktionsumgebung zu vermeiden?

Alles beginnt auf der Grundlage, wo die Softwareentwicklung beginnt. Im Allgemeinen möchten Sie für jede Phase eine dedizierte Umgebung verwenden. In den frühen Entwicklungsphasen, wenn sich der Anwendungscode sehr oft ändert, sollten Sie eine dedizierte Entwicklungsumgebung verwenden (normalerweise als untere Umgebung bezeichnet). Dann wird die Anwendung in der QA-Umgebung immer weiter verfeinert, wo QA-Teams manuelle und/oder automatisierte Tests durchführen. Als nächstes, wenn die Anwendung die Zustimmung des QA-Teams erhält, wird sie in die oberen Umgebungen wie Staging und schließlich in die Produktion befördert. In diesem Prozess, in dem die Anwendung von einer Umgebung in eine andere befördert wird, läuft ein dedizierter Pipeline, der Anwendungsartefakte kontinuierlich scannt und den Schweregrad überprüft. Wenn der Schweregrad einen bestimmten Schwellenwert nicht erreicht, schlägt die Pipeline sofort fehl und die Beförderung der Anwendungsartefakte in die Produktion wird in den frühen Phasen gestoppt.

Das Sicherheitsscanning-Tool (z. B. snyk) fungiert daher als Türsteher, der unerwünschte Artefakte daran hindert, von den frühen Entwicklungsphasen in Ihre Produktionsumgebung zu gelangen. Auf ähnliche Weise verwenden Pipelines in den oberen Umgebungen snyk, um Anwendungsartefakte am Eintreten in die endgültige Produktionsstufe zu erlauben oder zu verbieten.

GitHub Actions CI/CD Workflow Implementierung

In diesem Schritt lernen Sie, wie Sie eine Beispiel-CI/CD-Pipeline mit integriertem Schwachstellen-Scannen über GitHub-Workflows erstellen und testen. Um die Grundlagen der Verwendung von Github Actions mit DigitalOcean Kubernetes zu erlernen, verweisen Sie auf dieses Tutorial.

Die in dem folgenden Abschnitt bereitgestellte Pipeline baut und verteilt die Anwendung game-2048-example aus dem DigitalOcean kubernetes-sample-apps Repository.

Auf einer oberen Ebene betrachtet besteht der game-2048 CI/CD-Workflow, der im kubernetes-sample-apps Repo bereitgestellt wird, aus den folgenden Phasen:

1. Anwendungs-Build- und Testphase – erstellt Hauptanwendungsartefakte und führt automatisierte Tests aus.
2. Snyk Anwendungs-Image-Scan-Phase – scannt das Anwendungs-Docker-Image nach bekannten Schwachstellen. Es fungiert als Gate, und der finale Pipeline-Zustand (bestanden/nicht bestanden) hängt von diesem Schritt ab. Im Falle eines Fehlers wird eine Slack-Benachrichtigung gesendet.
3. Anwendungs-Image-Build- und Push-Phase – erstellt und taggt das Anwendungs-Image mit dem neuesten Git-Commit-SHA. Anschließend wird das Image an DOCR übertragen.
4. Snyk Infrastruktur als Code (IAC) Scan-Stufe – scannt nach bekannten Schwachstellen in den Kubernetes-YAML-Manifesten, die mit der Anwendung verbunden sind. Dient als Gate, und der endgültige Pipeline-Zustand (bestanden/nicht bestanden) hängt von diesem Schritt ab. Im Falle eines Fehlers wird auch eine Slack-Benachrichtigung gesendet.
5. Anwendungsdeploymentschritt – deployt die Anwendung auf Kubernetes (DOKS).

Das untenstehende Diagramm veranschaulicht jeden Job aus der Pipeline und die zugehörigen Schritte mit Aktionen (nur relevante Konfiguration wird gezeigt):

Wie lässt sich die Pipeline fehlschlagen, wenn ein bestimmtes Sicherheits-Compliance-Level nicht erreicht wird?

Die Snyk CLI bietet hierfür eine Flagge namens --severity-threshold. Diese Flagge korreliert mit dem insgesamt berechneten Schweregrad nach jedem Scan. Im Fall von Snyk nimmt der Schweregrad einen der folgenden Werte an: niedrig, mittel, hoch oder kritisch. Sie können den Pipelinevorgang basierend auf dem Schweregradwert fehlschlagen oder bestehen lassen und die Anwendungsbereitstellung stoppen, wenn die Bedingungen nicht erfüllt sind.

Das unten stehende Bild veranschaulicht den Ablauf für den Beispiel-CI/CD-Pipeline, der in dieser Anleitung verwendet wird:

Bitte befolgen Sie die folgenden Schritte, um den Snyk-CI/CD-GitHub-Workflow zu erstellen und zu testen, der im kubernetes-sample-apps-GitHub-Repository bereitgestellt wird:

1. Forke das kubernetes-sample-apps-GitHub-Repository.
2. Erstellen Sie die folgenden GitHub-verschlüsselten Secrets für Ihre kubernetes-sample-apps-Kopie (Einstellungen-Tab -> Secrets -> Actions):
   • DIGITALOCEAN_ACCESS_TOKEN – enthält Ihr DigitalOcean-Kontozugriffstoken.
   • DOCKER_REGISTRY – enthält Ihren DigitalOcean-Docker-Registry-Namen einschließlich des Endpunkts (z. B. registry.digitalocean.com/sample-apps).
   • DOKS_CLUSTER – enthält Ihren DOKS-Cluster-Namen. Sie können den folgenden Befehl ausführen, um Ihren DOKS-Cluster-Namen zu erhalten: doctl k8s cluster list --no-header --format Name.
   • SNYK_TOKEN – enthält Ihre Snyk-Benutzerkontonummer – führen Sie aus: snyk config get api, um die ID zu erhalten. Wenn das nicht funktioniert, können Sie den Token von Ihrer Benutzerkontoeinstellungs-Seite abrufen.
   • SLACK_WEBHOOK_URL – enthält Ihre Slack eingehende Webhook-URL, die für Snyk-Scan-Benachrichtigungen verwendet wird.
3. Navigieren Sie zum Aktionen-Tab Ihrer geklonten Repo und wählen Sie den Game 2048 Snyk CI/CD Beispiel-Workflow:
   
4. Klicken Sie auf die Schaltfläche Workflow ausführen und lassen Sie die Standardwerte stehen:
   

A new entry should appear in the below list after clicking the Run Workflow green button. Select the running workflow to observe the pipeline progress:

Die Pipeline wird fehlschlagen und anhalten, wenn der snyk-container-security-check-Job ausgeführt wird. Dies ist zu erwarten, da der Standardwert für die Schweregradstufe, der im Workflow-Eingang verwendet wird, nämlich mittel, nicht den Erwartungen entspricht. Sie sollten auch eine Slack-Benachrichtigung mit Details zum Workflow-Lauf erhalten:

In den nächsten Schritten lernen Sie, wie Sie den snyk-Scan-Bericht untersuchen, um die Probleme zu beheben, den Schweregrad zu senken und die Pipeline zu bestehen.

Schritt 4 – Untersuchung der Snyk-Scan-Ergebnisse und Behebung gemeldeter Probleme

Wenn der Schwellenwert für den Schweregrad nicht erreicht wird, schlägt der GitHub-Workflow für game-2048 fehl, und es wird eine Slack-Benachrichtigung mit zusätzlichen Details gesendet. Sie erhalten auch Sicherheitsberichte, die im Sicherheits-Tab Ihres Projekt-Repositories auf GitHub veröffentlicht und zugänglich sind.

Der Workflow für game-2048 führt zwei Sicherheitsüberprüfungen durch:

1. Überprüfung der Sicherheit von Container-Images – der Job snyk-container-security-check wird zu diesem Zweck verwendet. Der entsprechende snyk-Befehl lautet – snyk container test <GAME-2048-IMAGE>:<TAG> --file=/path/to/game-2048/Dockerfile.
2. Überprüfung von Konfigurationsfehlern in Kubernetes-Manifesten – der Job snyk-iac-security-check wird zu diesem Zweck verwendet. Der entsprechende snyk-Befehl lautet – snyk iac test /path/to/project/kubernetes/manifests.

Das Absenken des Schweregrads und das Bestehen des Workflows bestehen daher aus:

1. Untersuchung und Behebung der von dem Job snyk-container-security-check gemeldeten Probleme.
2. Untersuchung und Behebung der von dem Job snyk-iac-security-check gemeldeten Probleme.

Als Nächstes lernen Sie, wie Sie jeden Schritt einzeln angehen.

Untersuchung und Behebung von Sicherheitslücken in Container-Images

Die im Leitfaden verwendete Beispielpipeline führt Sicherheitsüberprüfungen für das Container-Image game-2048 und das zugehörige Dockerfile über den Job snyk-container-security-check durch.

Der Job snyk-container-security-check führt die folgenden Schritte aus:

1. Erstellt das Docker-Image der Anwendung game-2048 lokal. Dieser Schritt wird mit der GitHub-Aktion docker-build-push implementiert.
2. Führt Snyk-Sicherheitsprüfungen für das Anwendungs-Container-Image und das Dockerfile durch. Dieser Schritt wird mit dem Befehl snyk container test implementiert. Die Scan-Ergebnisse werden im GitHub SARIF-Format exportiert. Die Sicherheitsstufen-Schwelle wird über das Argument –severity-threshold gesteuert – entweder wird sie auf den Eingabeparameter snyk_fail_threshold gesetzt, wenn der Workflow manuell ausgelöst wird, oder auf die Umgebungsvariable SNYK_FAIL_THRESHOLD, wenn der Workflow automatisch ausgeführt wird.
3. Die Scan-Ergebnisse (im SARIF-Format) werden im Sicherheits-Tab Ihres Anwendungs-Repositories veröffentlicht. Dieser Schritt wird mithilfe der GitHub-Aktion codeql implementiert.

Der folgende Ausschnitt zeigt die Hauptlogik des Jobs snyk-container-security-check:

- name: Build App Image for Snyk container scanning
  uses: docker/build-push-action@v3
  with:
    context: ${{ env.PROJECT_DIR }}
    push: false
    tags: "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}"

- name: Check application container vulnerabilities
  run: |
    snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
      --file=Dockerfile \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-container-scan.sarif
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk report SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-container-scan.sarif
    category: snyk-container-scan

–file=Dockerfile \

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–sarif –sarif-file-output=snyk-container-scan.sarif

Um die gemeldeten Probleme zu beheben, müssen Sie zunächst den Sicherheits-Tab Ihres Repository-Forks kubernetes-sample-apps überprüfen:

FROM node:18.6.0-slim AS builder
WORKDIR /usr/src/app
COPY . .
RUN npm install --include=dev
Sie sehen in diesem Fall eine Reihe von Schwachstellen für das Basis-Docker-Image. Klicken Sie auf jede, um sie zu erweitern und weitere Details zu sehen:
Um die Untersuchungen abzuschließen und Empfehlungen von Snyk zu sehen, müssen Sie die Ausgabe des Jobs snyk-container-security-check aus dem Haupt-Workflow überprüfen:
Hinweis:Snyk Container Testbietet die Möglichkeit, Ergebnisse im SARIF-Format zu exportieren, weiß jedoch nicht, wie man Berichte in das Snyk Cloud-Portal hochlädt. Andererseits bietet Snyk Container Monitor die Möglichkeit, Ergebnisse in das Snyk Cloud-Portal hochzuladen, kann jedoch kein SARIF exportieren. Daher verwendet diese Anleitung snyk container test mit der SARIF-Exportfunktion. Einige Empfehlungen sind leider nicht im SARIF-Output verfügbar. Daher müssen Sie auch in der Konsolenausgabe des Jobs nach Empfehlungen suchen.
Die Ausgabe des snyk-container-security-check-Jobs zeigt, dass Snyk empfiehlt, die Basismodellversion von node:16-slim auf node:18.6.0-slim zu aktualisieren. Diese Änderung beseitigt das bzw. die hochriskante(n) Problem(e) und senkt auch die Anzahl anderer gemeldeter Schwachstellen von 70 auf 44 - dies ist eine erhebliche Reduzierung um fast 50% !!!
ENV NODE_ENV=development
RUN npm run build

FROM node:18.6.0-slim
RUN npm install http-server -g
RUN mkdir /public
WORKDIR /public
COPY --from=builder /usr/src/app/dist/ ./
EXPOSE 8080
USER 1000
CMD ["http-server"]

Öffnen Sie nun die Dockerdatei Dockerfile der Anwendung game-2048 in Ihrem Fork und ändern Sie die FROM-Anweisungen, um auf die neue Version (node:18.6.0-slim zum Zeitpunkt dieses Schreibens) zu verweisen:

#

# Der Build-Modus kann über die Umgebungsvariable NODE_ENV festgelegt werden (Entwicklung oder Produktion)

# Siehe Projekt package.json und webpack.config.js

#

Zuletzt commiten Sie die Änderungen in Ihr GitHub-Repository und starten Sie den Workflow erneut (lassen Sie die Standardwerte unverändert). Diesmal sollte der snyk-container-security-check-Job bestehen:

Wenn Sie zum Sicherheits-Tab Ihres Projekts gehen, sollten keine Probleme gemeldet werden.

Wie stellen Sie sicher, dass Sie zukünftig die Anzahl der Schwachstellen in der Basismodell verringern?

1. Der beste Ansatz besteht darin, ein Basisbild mit minimalem Footprint zu verwenden – je weniger Binärdateien oder Abhängigkeiten im Basisbild vorhanden sind, desto besser. Eine weitere bewährte Praxis ist es, Ihre Projekte kontinuierlich zu überwachen, wie im Abschnitt „Überwachen Sie Ihre Projekte regelmäßig“ dieses Leitfadens erklärt.
2. Sie werden feststellen, dass die Pipeline immer noch fehlschlägt, aber diesmal in der Phase „snyk-iac-security-check“. Dies ist zu erwarten, da es Sicherheitsprobleme mit den Kubernetes-Manifesten gibt, die zur Bereitstellung der Anwendung verwendet werden. Im nächsten Abschnitt erfahren Sie, wie Sie diese Situation untersuchen und Snyk-Sicherheitsempfehlungen anwenden, um die gemeldeten Probleme zu beheben.

Untersuchung und Behebung von Schwachstellen in Kubernetes-Manifesten

- name: Check for Kubernetes manifests vulnerabilities
  run: |
    snyk iac test \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-iac-scan.sarif \
      --report
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk IAC SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-iac-scan.sarif
    category: snyk-iac-scan

Die Pipeline schlägt immer noch fehl und stoppt beim Job „snyk-iac-security-check“. Dies ist zu erwarten, da der im Workflow-Eingang verwendete Standardwert für die Schweregradstufe, nämlich „mittel“, nicht den Sicherheitsanforderungen des Projekts entspricht.

1. Der Job „snyk-iac-security-check“ überprüft Schwachstellen (oder Fehlkonfigurationen) in Kubernetes-Manifesten und führt die folgenden Schritte aus:
2. Snyk führt Sicherheitsprüfungen für Kubernetes-Manifeste aus dem Projektverzeichnis game-2048-example durch. Dieser Schritt wird mithilfe des Befehls snyk iac test implementiert. Die Scan-Ergebnisse werden im Format GitHub SARIF exportiert. Die Sicherheitsstufenschwelle wird über das Argument –severity-threshold gesteuert – entweder wird sie auf den Eingabeparameter snyk_fail_threshold gesetzt, wenn der Workflow manuell ausgelöst wird, oder auf die Umgebungsvariable SNYK_FAIL_THRESHOLD, wenn der Workflow automatisch ausgeführt wird. Schließlich wird das Argument –report ebenfalls verwendet, um die Scan-Ergebnisse an das Snyk-Cloud-Portal zu senden.

Die Scan-Ergebnisse (SARIF-Format) werden im Sicherheits-Tab des Anwendungs-Repositories veröffentlicht. Dieser Schritt wird mithilfe der GitHub-Aktion codeql implementiert.

Im folgenden Ausschnitt wird die tatsächliche Implementierung jedes Schrittes aus dem Job snyk-iac-security-check gezeigt:

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: game-2048
spec:
  replicas: 1
  selector:
    matchLabels:
      app: game-2048
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: game-2048
    spec:
      containers:
        - name: backend
          --sarif --sarif-file-output=snyk-iac-scan.sarif \
          image: registry.digitalocean.com/sample-apps/2048-game:latest
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 200m
              memory: 100Mi
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - all

Um die gemeldeten Probleme zu beheben, haben Sie zwei Möglichkeiten:

• Verwenden Sie das Snyk-Cloud-Portal und greifen Sie auf das Projekt game-2048 zu, um Details zu überprüfen:
  
• Verwenden Sie den Sicherheits-Tab Ihres Game-2048-App-Repositorys, um Details zu überprüfen:
  
• Auf jeden Fall erhalten Sie Empfehlungen, wie Sie die gemeldeten Probleme beheben können.
• Für diese Anleitung verwenden Sie das Snyk-Cloud-Portal, um die gemeldeten Sicherheitsprobleme zu untersuchen. Klicken Sie zunächst auf den Eintrag game-2048-example aus der Projektliste und wählen Sie dann die Datei kustomize/resources/deployment.yaml aus:

Markieren Sie anschließend das Kontrollkästchen Mittel im Untermenü Schweregrad links, um nur Probleme auf Mittel -Ebene anzuzeigen:

Dann können Sie jede gemeldete Problemkarte überprüfen und die Details überprüfen. Klicken Sie auf die Schaltfläche Weitere Details anzeigen von der Karte Container wird ohne Kontrolle des Root-Benutzers ausgeführt – Sie erhalten weitere Details zum aktuellen Problem und wichtige Hinweise, wie es zu beheben ist:

A few final checks can be performed as well on the Kubernetes side to verify if the reported issues were fixed:

1. Nachdem Sie alle Informationen von jeder Karte gesammelt haben, können Sie die Datei deployment.yaml aus Ihrem Repository bearbeiten (befindet sich im Unterordner game-2048-example/kustomize/resources). Die Fixes sind bereits vorhanden, Sie müssen nur die letzten Zeilen in der Datei auskommentieren. Die endgültige deployment.yaml-Datei sollte wie folgt aussehen:
2. readOnlyRootFilesystem – Führt das Container-Image schreibgeschützt aus (Dateien können nicht durch kubectl exec im Container geändert werden).

allowPrivilegeEscalation – Das Setzen von allowPrivilegeEscalation auf false stellt sicher, dass kein Kindprozess eines Containers mehr Berechtigungen erlangen kann als sein Elternprozess.

capabilities.drop – Um Container sicherer zu machen, sollten Sie Containern nur die minimalen Berechtigungen geben, die sie zum Ausführen benötigen. In der Praxis verwerfen Sie standardmäßig alles und fügen dann Schritt für Schritt erforderliche Berechtigungen hinzu. Weitere Informationen zu Container-Berechtigungen finden Sie hier.

Schließlich übernehmen Sie die Änderungen für die Datei deployment.yaml und pushen sie in den Hauptzweig. Nachdem Sie den Workflow manuell ausgelöst haben, sollte er diesmal erfolgreich abgeschlossen werden:

Sie sollten auch eine grüne Slack-Benachrichtigung vom Snyk-Scan-Job erhalten. Navigieren Sie zum Snyk-Portal-Link und überprüfen Sie, ob die kürzlich behobenen Probleme verschwunden sind – es sollten keine mittelgroßen Probleme gemeldet werden.

Überprüfen Sie, ob das Spiel-2048-Deployment ein schreibgeschütztes (unveränderliches) Dateisystem hat, indem Sie die Datei index.html beschreiben, die von der Spiel-2048-Anwendung verwendet wird:

kubectl exec -it deployment/game-2048 -n game-2048 -- /bin/bash -c "echo > /public/index.html"

Die Ausgabe sieht ähnlich aus:

Ausgabe
/bin/bash: /public/index.html: Schreibgeschütztes Dateisystem
Befehl mit Exit-Code 1 beendet

Überprüfen Sie, ob das Spiel-2048-Deployment ein schreibgeschütztes (unveränderliches) Dateisystem hat, indem Sie die Datei index.html beschreiben, die von der Spiel-2048-Anwendung verwendet wird:

Die Ausgabe sieht ähnlich aus:

snyk-container-security-check:
    runs-on: ubuntu-latest
    needs: build-and-test-application

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      ...

      - name: Check application container vulnerabilities
        run: |
          snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile \
            --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
            --target-name=${{ env.PROJECT_NAME }} \
            --target-reference=${{ env.ENVIRONMENT }} \
            --sarif-file-output=snyk-container-scan.sarif
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Monitor the application container using Snyk
        run: |
          snyk container monitor "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      
      ...

Überprüfen Sie, ob der Container als Nicht-Root-Benutzer läuft (sollte eine ganze Zahl ungleich Null ausgeben – z.B. 1000):

kubectl exec -it deployment/game-2048 -n game-2048 -- id -u

Überprüfen Sie, ob der Container als Nicht-Root-Benutzer läuft (sollte eine ganze Zahl ungleich Null ausgeben – z.B. 1000):

Wenn alle Überprüfungen erfolgreich sind, haben Sie die erforderlichen Sicherheitsempfehlungen erfolgreich angewendet.

build-and-test-application:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm test
        working-directory: ${{ env.PROJECT_DIR }}

      - name: Snyk code test and monitoring
        run: |
          snyk test ${{ env.PROJECT_DIR }}
          snyk monitor ${{ env.PROJECT_DIR }}
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Überwachen Sie Ihre Projekte regelmäßig

Die von Ihnen bisher implementierte Schwachstellen-Scan-Automatisierung ist ein guter Ausgangspunkt, aber nicht perfekt. Warum?

Ein Problem bei dem aktuellen Ansatz ist, dass Sie nie wissen, wann neue Probleme für die Assets gemeldet werden, die Sie bereits in Ihren Umgebungen bereitgestellt haben. Mit anderen Worten, Sie haben die Sicherheitsrisiken bewertet und die Maßnahmen ergriffen, um die Probleme zu beheben, zu einem bestimmten Zeitpunkt – wenn Ihre CI/CD-Automatisierung ausgeführt wurde.

Aber was ist, wenn in der Zwischenzeit neue Probleme gemeldet werden und Ihre Anwendung erneut verwundbar ist? Snyk hilft Ihnen, diese Situation über die Überwachungsfunktion zu überwinden. Die Überwachungsfunktion von Snyk hilft Ihnen dabei, neue Sicherheitslücken anzugehen, die ständig bekannt gegeben werden. In Verbindung mit der Snyk Slack-Integration (erklärt in Schritt 6 – Aktivieren von Slack-Benachrichtigungen) können Sie sofort Maßnahmen ergreifen, um neu bekannt gegebene Probleme zu beheben, die sich auf Ihre Anwendung in einer Produktionsumgebung auswirken können.

Um von dieser Funktion zu profitieren, müssen Sie lediglich den Befehl snyk monitor vor allen Bereitstellungsschritten in Ihrer CI/CD-Pipeline verwenden. Die Syntax ist sehr ähnlich zu den snyk test Befehlen (eine der coolen Eigenschaften der Snyk CLI ist, dass sie mit Einheitlichkeit im Sinn entwickelt wurde). Der Befehl snyk monitor sendet einen Schnappschuss an das Snyk-Cloud-Portal, und von dort aus werden Sie über neu bekannt gegebene Sicherheitslücken für Ihr Projekt benachrichtigt.

A more efficient approach is where you integrate vulnerability scan tools directly in your favorite IDE (or Integrated Development Environment). This way, you can detect and fix security issues ahead of time in the software development cycle.

In Bezug auf die GitHub-Workflow-Automatisierung können Sie Ihre Anwendungscontainer im snyk-container-security-check Job überwachen, nachdem Sie auf Sicherheitslücken getestet haben. Der folgende Ausschnitt zeigt eine praktische Implementierung für die in diesem Leitfaden verwendete Pipeline (einige Schritte wurden der Klarheit halber ausgelassen):

1. –file=${{ env.PROJECT_DIR }}/Dockerfile \
2. –severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
3. –target-name=${{ env.PROJECT_NAME }} \
4. –target-reference=${{ env.ENVIRONMENT }} \

–sarif-file-output=snyk-container-scan.sarif

–file=${{ env.PROJECT_DIR }}/Dockerfile

Obenstehender Ausschnitt zeigt einen zusätzlichen Schritt namens Überwachen Sie den Anwendungscontainer mit Snyk, wo der tatsächliche Snyk-Containermonitor läuft.

Nachdem der Befehl „snyk monitor“ ausgeführt wurde, können Sie sich im Snyk-Web-UI anmelden, um den neuesten Schnappschuss und die Historie Ihres Projekts einzusehen:

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

Sie können auch Ihren Anwendungsquellcode im Build- und Testanwendungs-Job testen und überwachen. Unten sehen Sie eine Beispielimplementierung für den in diesem Leitfaden verwendeten GitHub-Workflow:

Als nächstes erhalten Sie regelmäßig Slack-Benachrichtigungen über neu veröffentlichte Schwachstellen für Ihr Projekt.

Ausnahmen behandeln

Es gibt Situationen, in denen Sie nicht möchten, dass der endgültige Bericht von einigen Problemen beeinflusst wird, die Ihr Team als sicher zu ignorieren betrachtet. Snyk bietet eine integrierte Funktion zur Verwaltung von Ausnahmen und zur Bewältigung dieser Situation.

Sie können mehr über dieses Feature hier lesen.

Snyk für IDEs

Snyk bietet Unterstützung für eine Vielzahl von IDEs, wie zum Beispiel:

Eclipse-Plugin.

JetBrains-Plugin.

• Visual Studio-Erweiterung.
• Visual Studio Code-Erweiterung.
• Die oben genannten Plugins helfen Ihnen, Probleme bereits in den frühen Entwicklungsphasen zu erkennen und zu beheben, wodurch Frustrationen, Kosten und Sicherheitsmängel in Produktionssystemen vermieden werden. Außerdem hilft es Ihnen, die Iterationen und den menschlichen Aufwand langfristig zu reduzieren. Als Beispiel müssen Sie für jedes von Ihrer CI/CD-Automatisierung gemeldete Sicherheitsproblem zurückgehen, das Problem in Ihrem Code beheben, Änderungen übernehmen, erneut auf die CI/CD-Automatisierung warten und im Falle eines Fehlers den Vorgang wiederholen.
• Auf der offiziellen Dokumentationsseite können Sie mehr über diese Funktionen auf der Seite Snyk für IDEs lesen.
• Schritt 5 – Automatisches Auslösen des Snyk CI/CD-Workflows
• Sie können den Workflow so einstellen, dass er automatisch bei jedem Commit oder PR gegen den Hauptbranch ausgelöst wird, indem Sie die folgenden Zeilen am Anfang der Datei game-2048-snyk.yaml auskommentieren:
• Nachdem Sie die Datei bearbeitet haben, übernehmen Sie die Änderungen in Ihren Hauptbranch und Sie sollten bereit sein.
• Schritt 6 – Aktivieren von Slack-Benachrichtigungen
• Sie können Snyk so einrichten, dass Slack-Benachrichtigungen über neue Sicherheitslücken in Ihren Projekten und über neue Upgrades oder Patches, die verfügbar geworden sind, gesendet werden.
• Um dies einzurichten, müssen Sie einen Slack-Webhook generieren. Dies können Sie entweder über Incoming WebHooks oder durch Erstellen Ihrer eigenen Slack-App tun. Sobald Sie Ihre Slack-Webhook-URL generiert haben, gehen Sie zu Ihren Einstellungen für ‚Organisation verwalten‘, geben Sie die URL ein und klicken Sie auf die Schaltfläche Verbinden: