Snyk CLI-Cheatsheet

Die Snyk CLI ist ein hervorragendes und leistungsfähiges Tool, um Ihre Anwendungen, Container und die Infrastructure as Code auf Sicherheitslücken zu scannen. In diesem Cheatsheet sehen wir uns die leistungsfähigsten Features an, die unsere CLI zu bieten hat. Sie können die CLI zum Scannen und Überwachen auf Ihrem lokalen System verwenden, und darüber hinaus auch in Ihre Pipeline integrieren. Unabhängig davon, wie Sie die Snyk CLI verwenden, ist es das ideale Tool zum Testen, Überwachen und Beheben bekannter Schwachstellen in Ihren Anwendungen.

Wir verbessern unsere CLI ständig, und sie ist weitaus leistungsfähiger, als wir sie jemals in einem einzigen Cheatsheet behandeln könnten. Einen detaillierteren Überblick über unsere CLI finden Sie in unserer Snyk CLI-Dokumentation. Wenn Sie mehr darüber wissen möchten, was die CLI für eine bestimmte Sprache oder ein bestimmtes Build beitragen kann, besuchen Sie unsere Sprachsupport-Seite:

• JavaScript (npm, yarn)

• Java und Kotlin (maven | Gradle)

• .Net (Nuget, Paket)

• Python (Pip, Poetry)

• PHP (composer)

• Ruby (Bundler)

• Go (dep, govendor)

• Viele weitere…

Cheatsheet herunterladen

Installation

Fangen wir von vorne an. Wenn Sie die Snyk CLI noch nicht installiert haben, sollten Sie dies zuerst tun. Derzeit haben Sie die Möglichkeit, die Snyk CLI entweder mit npm, Homebrew, Scoop oder durch Herunterladen einer bestimmten Binärdatei von GitHub zu installieren.

npm

npm install snyk -g

Homebrew

brew tap snyk/tap && brew install snyk

Scoop

scoop bucket add snyk https://github.com/snyk/scoop-snyk
scoop install snyk

Manuelle Installation

Ein manuelles Installationsprogramm ist auf der GitHub-Seite von Snyk verfügbar.

Authentifizierung

Wenn Sie die CLI installiert haben, müssen Sie sich mit Ihrem Snyk-Account authentifizieren. Hierfür gibt es mehrere Möglichkeiten.

Wenn Sie snyk auth aufrufen, wird der Browser auf die Registrierungs- oder Anmeldeseite umgeleitet, auf der Sie sich authentifizieren oder registrieren können.

Alternativ können Sie mit snyk auth ein API-Token-Argument von Snyk starten, das Sie von Ihrer Account-Seite abrufen können.

Die letzte Option, die wir speziell für CI-Tests empfehlen, ist die Erstellung einer Umgebungsvariable namens SNYK_TOKEN. Alle Snyk CLI-Befehle verwenden sie, ohne explizit snyk auth auszuführen.

Expertentipp: Stellen Sie sicher, dass Sie die CLI regelmäßig aktualisieren und neu installieren. Wir überarbeiten und veröffentlichen laufend neue Versionen der CLI. Verpassen Sie nicht die neuen und verbesserten Features.

CLI-Befehle

Die Snyk CLI nimmt einen Befehl an, auf den verschiedene Optionen folgen. Stellen Sie sicher, dass Sie die CLI-Befehle innerhalb des Projektordners ausführen. Sehen wir uns an, was diese Befehle bewirken.

Test von Snyk

Der Befehl snyk test testet ein lokales Projekt auf bekannte Schwachstellen. Der Bericht enthält Informationen über diese Schwachstellen, deren Schweregrad, Typen und Beschreibungen, die Anzahl der gefährdeten Pfade, Abhilfemaßnahmen und vieles mehr. Die Snyk CLI erkennt Ihre Manifest-Dateien automatisch und testet die erste gefundene Datei. Beachten Sie, dass Snyk nach lokalen Abhängigkeiten sucht, um auf Schwachstellen zu testen. Daher müssen Sie die notwendigen Schritte wie npm install, mvn install, dotnet restore oder dep ensurezum Herunterladen Ihrer Abhängigkeitsstruktur ausführen, bevor Sie den snyk test starten.

Snyk Test ist auch innerhalb einer CI-Pipeline nützlich. Die Ausführung eines snyk test beim Erstellen der Binärdatei zeigt Ihnen direkt, ob Ihr Projekt Schwachstellen enthält. Wenn Sie möchten, können Sie sogar die Pipeline unterbrechen und einen Abbruch erzwingen. Wenn Sie snyk test von einem Skript aus aufrufen, müssen Sie nur den Exit-Code überprüfen. Falls der Exit-Code 0 ist, ist alles in Ordnung und es wurden keine Schwachstellen gefunden. Ist dies nicht der Fall ist, haben Sie wahrscheinlich noch einiges zu tun.

Sie können ein bestimmtes Manifest testen, wenn Sie ein Projekt haben, das mehrere umfasst. Verwenden Sie das Flag --file, um die zu scannende Datei zu bestimmen.

$ snyk [cmd] --file=package.json

In ähnlicher Weise können Sie den Package-Manager mit dem Flag --package-manager angeben. Dies ist für den Ausnahmefall nützlich, wenn Snyk den Package-Manager nicht automatisch erkennt.

$ snyk test --file=req.txt --package-manager=pip

Sollen alle Projekte in einem Ordner geprüft werden, können Sie dafür das Flag --all-projects verwenden. Es wird eine automatische Erkennung durchgeführt, um das aktuelle Verzeichnis zu durchsuchen und alle gefundenen Manifest-Dateien zu testen. Standardmäßig durchsucht Snyk das aktuelle Verzeichnis sowie drei weitere Ebenen. Die Prüfebene können Sie ganz einfach mit der Option --detection-depth wechseln.

$ snyk test --all-projects --detection-depth=4

Snyk testet standardmäßig jedoch nicht Ihre Entwicklungsabhängigkeiten, da viele dies im Vergleich zu Schwachstellen in der Anwendung als unbedeutend ansehen. Wenn Sie möchten, dass Snyk auch Ihre Entwicklungsabhängigkeiten einbezieht, verwenden Sie das Flag --dev.

$ snyk test --dev

Ein weiteres nützliches Flag für den Prüfbefehl und andere Befehle von Snyk ist --org. Damit wird ein Test oder ein beliebiger Befehl von Snyk mit einer bestimmten Organisation verknüpft. Organisationen sind Container, in denen Sie Projekte gruppieren und denen mehrere Benutzende zugeordnet werden können. Dies ist besonders nützlich, wenn Sie in Teams arbeiten und Snapshots mit snyk monitor erstellen. Wenn Sie keine Organisation angeben, werden Ihre Ergebnisse mit Ihrer Standardorganisation verknüpft.

$ snyk [cmd] --org=<org_id>

Wenn Sie öffentliche Repositorys von der Befehlszeile aus testen möchten, haben wir genau das Richtige für Sie. Sie können die URL des öffentlichen Repositorys direkt in den Befehl integrieren. Es funktioniert nur mit npm-Repositorys, wenn das package-lock.json verfügbar ist. Probieren Sie es aus:

$ snyk test https://github.com/snyk/goof

Sie können Pakete in npm auch remote testen, indem Sie nur die Paketbezeichnung angeben und damit die letzte Version testen, oder den Paketnamen und die Version vollständig angeben.

$ snyk test lodash
$ snyk test ionic@1.6.5

Nachdem Sie einen Test von Snyk für ein Projekt durchgeführt haben, erhalten Sie die Ausgabe in drei Abschnitten.

• Fehler, die durch Aktualisierung zu beheben sind: Wenn Sie die Bibliothek wie vorgeschlagen aktualisieren, beseitigen Sie eine oder mehrere Schwachstellen, die in Ihrem Projekt gefunden wurden.

• Patchbarer Fehler: Es ist kein Update verfügbar, das das Problem behebt. Allerdings hat Snyk einen Patch zur Behebung der Sicherheitslücke entwickelt.

• Probleme ohne direkte Aktualisierungsmöglichkeit oder Patch: Für die von Ihnen importierte Abhängigkeit ist kein Update verfügbar. Eine Schwachstelle könnte tatsächlich in einer der transitiven Abhängigkeiten liegen. Wenn es bereits eine neuere Version der transitiven Abhängigkeit gibt, die die Schwachstelle behebt, zeigen wir Ihnen auch diese an. Eine nützliche Information, denn in einigen Ökosystemen können Sie transitive Abhängigkeiten manuell ersetzen.

Für jede Schwachstelle, die die CLI in einem der drei Abschnitte anzeigt, können Sie eine Beschreibung, den Schweregrad und einen Link sehen, über den Sie mehr über das spezifische Problem der Schwachstelle erfahren können. 

Wenn Sie die CLI-Ausgabe im JSON-Format bevorzugen, haben wir ein Flag dafür: --json. Sie können die JSON-Ausgabe verwenden, um die Ergebnisse nach Belieben zu formatieren.

$ snyk test --json

Das Speichern der Scan-Ergebnisse in einer JSON-Datei ist sogar noch unkomplizierter. Mit dem --json-file-output flag können Sie das Ergebnis direkt unter dem von Ihnen gewünschten Dateinamen zur späteren Überprüfung speichern. Zwischenzeitlich erhalten Sie – wie oben angezeigt – die lesbare Darstellung in der Konsole. Dies ist eine perfekte Lösung für CI-Pipelines, wenn Sie z.B. die Ergebnisse für einen bestimmten Build in einem Dashboard anzeigen möchten. Probieren Sie es aus:

$ snyk test --json-file-output=vuln.json

Beachten Sie auch, dass wir einen Snyk JSON-HTML-Mapper haben, der Ihre Ergebnisse in einen schönen HTML-basierten Bericht formatieren kann, den Sie Ihrem Manager vorlegen können.

Sie können die CLI-Ausgabe nach Schweregrad mit dem Flag --severity-threshold steuern. Wenn Sie nicht an den geringfügigen bis mittleren Schwachstellen interessiert sind, können Sie diese aus der Betrachtung herausnehmen, indem Sie wie folgt vorgehen:

$ snyk [cmd] --severity-threshold=high

Snyk Monitor

Der Befehl snyk monitor erstellt einen Snapshot Ihres Projekts und lädt die Ergebnisse auf die Website von Snyk hoch. Obwohl snyk monitor unter der Oberfläche snyk test verwendet, ist es wichtig zu wissen, dass dies kein Ersatz darstellt: Snyk Monitor erstellt einen Snapshot und verfolgt diesen über die Zeit. Wenn neue Schwachstellen oder Abhilfemaßnahmen gefunden werden, von denen Ihr Projekt profitiert, werden Sie über den von Ihnen gewählten Kommunikationskanal benachrichtigt.

In einer CI-Umgebung führen Sie in der Regel zuerst einen snyk test durch, um zu sehen, ob es zu diesem Zeitpunkt Schwachstellen gibt. Wenn es welche gibt, könnten Sie je nach Anwendungsfall Ihren Build zerstören. Wenn Sie fortfahren, wird snyk monitor in der Regel verwendet, um einen Snapshot für diese Version zu erstellen, sodass sie laufend überwacht wird. Der optimale Zeitpunkt dafür ist kurz vor der Produktion. Wenn Sie sich mit einem gewissen Grad an Schwachstellen vertraut gemacht haben, hilft Ihnen snyk monitor dabei, im Laufe der Zeit nicht nachzulassen.

Es ist wichtig, dass Sie bei der Ausführung von snyk monitor genügend Informationen angeben, um sicherzustellen, dass Ihr Snapshot an der erwarteten Stelle landet. Wenn Sie bei mehreren Organisationen Mitglied sind, müssen Sie mit dem Flag --org angeben, an welche Organisation Sie Ihren Snapshot senden möchten. Wenn Sie ähnliche Projektnamen haben, können Sie den Standardnamen, den Snyk Ihren Snapshots gibt, überschreiben, indem Sie den gewünschten Namen mit dem Flag --project-name eingeben.

$ snyk monitor --file=package.json --project-name=myapp --org=myorg

Snyk Ignore

Angenommen, Ihre Anwendung enthält eine Schwachstelle, für die kein Patch oder Update verfügbar ist, oder eine Schwachstelle, von der Sie glauben, dass sie in Ihrer Anwendung derzeit nicht ausgenutzt werden kann. In diesem Fall können Sie Snyk anweisen, die Schwachstelle für eine bestimmte Zeit zu ignorieren. Um den Befehl ignore zu verwenden, führen Sie zunächst snyk test aus und rufen die ID der Schwachstelle ab, die Sie in der CLI-Ausgabe finden können. Jetzt können Sie diese Schwachstelle mit folgendem Befehl ignorieren:

$ snyk ignore --id=npm:tough-cookie:20160722 --expiry=2019-04-30 --reason='Not currently exploitable'

Die Flags --expiry und --reason sind optional. Standardweise wird die Sicherheitslücke 30 Tage lang ignoriert.

Hinweis: Der Befehl snyk ignore erstellt eine .snyk-Datei mit den Informationen über die zu ignorierende Sicherheitslücke.

Snyk Container

Snyk Container ist eine CLI-Funktion zum Scannen von Container-Images wie Docker-Images. Bislang war dies über das Flag --docker in der CLI möglich.

Ähnlich wie beim Scannen und Überwachen Ihrer Anwendung können Sie auch Ihre Docker-Images mit Snyk scannen.

Wenn Sie Images für Docker Hub herunterladen, können Sie das Image wie folgt scannen und überwachen:

$ snyk container test <image>:<tag>
$ snyk container monitor <image>:<tag>

Falls Sie einem dieser Befehle ein Dockerfile hinzufügen, gibt Ihnen Snyk unter anderem Ratschläge zur Behebung des Problems für das von Ihnen verwendete Basis-Image. Wenn für das von Ihnen erstellte Image andere Basis-Images verfügbar sind, können wir Sie auf diese Alternativen hinweisen.

Snyk Container unterstützt nicht nur Docker-Container, sondern auch Distroless-Images. Diese Images können wie folgt gescannt werden:

$ snyk container test gcr.io/distroless/base | head

Außerdem können Container-Archive mit den Container-Funktionen von Snyk gescannt und überwacht werden. Das Scannen funktioniert sowohl für Docker-Container-Archive als auch für Open Container Initiative (OCI)-Images.

$ snyk container test docker-archive:container.tar
$ snyk container test oci-archive:container.tar

Wie beim Scannen Ihrer Anwendungen sind die Flags --json und --json-file-output für eine nahtlose Integration in Ihre eigenen Systeme verfügbar.

Mehr über den Snyk CLI-Container

Snyk Infrastructure as Code (Snyk IaC)

Mit den Snyk Infrastructure As Code-Scanfunktionen können Entwicklungsteams Fehlkonfigurationen finden und beheben, die zu Sicherheitsproblemen führen können. Mit dem Befehl snyk iac können Sie diese Funktion auch in der Snyk CLI auf Ihrem lokalen Rechner oder in Ihrer CI-Umgebung nutzen. Nun erhalten Sie so früh wie möglich in Ihrem Entwicklungszyklus Feedback.  Snyk IaC ist mit Unterstützung für Kubernetes, Helm Charts und Terraform AWS-Ressourcen verfügbar.

Wenn Sie eine Kubernetes- oder Terraform-Datei scannen möchten, können Sie dies folgendermaßen tun:

$ snyk iac test /path/to/Kubernetes.yaml
$ snyk iac test /path/to/terraform_file.tf

Ähnlich wie bei Snyk Test werden die mit Snyk IaC gefundenen Probleme mit einer entsprechenden Beschreibung und Schweregrad angezeigt. Wenn Sie diese Ausgabe in einem JSON-Format benötigen, um sie in Ihr System zu integrieren, sind die Flags --json und --json-file-output auch hier verfügbar:

$ snyk iac test /path/to/Kubernetes.yaml --json

Mit Snyk IaC können Sie auch Infrastrukturabweichungen und nicht verwaltete Ressourcen erkennen, tracken und melden:

$ snyk iac describe <OPTIONS>

Mehr zum Snyk CLI IaC

Troubleshooting

Wenn Sie sich nicht sicher sind, welchen Befehl Sie verwenden sollen oder wie ein bestimmtes Flag funktioniert, können Sie immer --help verwenden oder snyk help aufrufen.

$ snyk auth --help
$ snyk container --help

Debugging

Wenn etwas nicht funktioniert, können Sie die CLI mit dem Flag -d auffordern, die Debug-Protokollierung auszugeben. Wenn Sie mit unserem ausgezeichneten Support-Team sprechen, wird es Sie höchstwahrscheinlich bitten, dies auch zu tun:

$ snyk [cmd] -d

Für ein Open-Source-Projekt stehen keine Tests mehr zur Verfügung?

Das Scannen mit Snyk ist kostenlos und uneingeschränkt für die Open-Source-Entwicklung nutzbar. Allerdings erkennen wir ein Open-Source-Projekt nicht immer. Wenn Sie in der CLI-Ausgabe darauf hingewiesen werden, dass keine Tests mehr zur Verfügung stehen, können Sie die folgenden Schritte unternehmen, um zu bestätigen, dass Ihr Projekt tatsächlich Open Source ist.

1. Führen Sie snyk monitor aus

2. Navigieren Sie im Browser zu Ihrer Anwendung. (Die direkte URL befindet sich in der CLI-Ausgabe)

3. Klicken Sie im Menü auf Einstellungen

4. Geben Sie die URL für Ihr Open-Source-Repository in das Feld „Git remote URI“ ein.

Unerwartete Testergebnisse?

Um ein optimales Ergebnis zu erzielen, sollten Sie Ihr gesamtes Projekt neu erstellen, bevor Sie einen der CLI-Befehle ausführen. Wenn die Ausgabe von snyk test bzw. snyk monitor nicht wie erwartet ausfällt, führen Sie bitte Ihr Build-Tool aus, um alle Abhängigkeiten herunterzuladen und zu installieren.

Einige Beispiele:

$ npm install
$ mvn install
$ dotnet restore
$ dep ensure

Entfernen des API-Keys und Konfiguration

Wenn Sie Ihre CLI mit snyk auth authentifiziert haben, können Sie Ihr Token mit folgendem Befehl aus der Konfiguration entfernen:

$ snyk config unset api

Für weitere Informationen über andere Konfigurationseinstellungen rufen Sie bitte an:

$ snyk help config

Prüfen Sie Ihre Version

Bitte verwenden Sie stets die neueste Version unserer CLI. Wir veröffentlichen mehrmals pro Woche eine neue Version, manchmal sogar noch häufiger.

Stellen Sie sicher, dass Sie die neueste Version mit Ihrem Package-Manager wie im ersten Abschnitt beschrieben (erneut) installieren, oder suchen Sie in unserem GitHub repo nach dem neuesten Build.

Überprüfen Sie Ihre aktuelle Version einfach hiermit:

$ snyk --version

Die Dokumentation prüfen

Spezifische Projekte und Ökosysteme haben unterschiedliche Anforderungen. Bitte rufen Sie die CLI-Dokumentation und die Dokumentation der unterstützen Sprachen auf, um Hilfe für einen spezifischeren Anwendungsfall zu finden.