Ein Schwachstellenscanner für Container-Images und Dateisysteme. Installieren Sie einfach die Binärdatei, um es auszuprobieren. Funktioniert mit Syft, dem leistungsstarken SBOM-Tool (Software Bill of Materials) für Container-Images und Dateisysteme.
Agenda: https://docs.google.com/document/d/1ZtSAa6fj2a6KRWviTn3WoJm09edvrNUp4Iz_dOjjyY8/edit?usp=sharing (treten Sie dieser Gruppe für Schreibzugriff bei)
Alle sind willkommen!
Für kommerzielle Supportoptionen mit Syft oder Grype wenden Sie sich bitte an Anchore
Merkmale
Scannen Sie den Inhalt eines Container-Images oder Dateisystems, um bekannte Schwachstellen zu finden.
Finden Sie Schwachstellen für wichtige Betriebssystempakete:
alpin
Amazon Linux
BusyBox
CentOS
CBL-Mariner
Debian
Distroless
Oracle Linux
Red Hat (RHEL)
Ubuntu
Wolfi
Finden Sie Schwachstellen für sprachspezifische Pakete:
Unterstützt die Bildformate Docker, OCI und Singularity.
OpenVEX-Unterstützung zum Filtern und Erweitern von Scanergebnissen.
Wenn Sie auf ein Problem stoßen, teilen Sie uns dies bitte über den Issue-Tracker mit.
Installation
Empfohlen
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
Skriptoptionen installieren:
-b : Geben Sie ein benutzerdefiniertes Installationsverzeichnis an (standardmäßig ./bin ).
-d : Ausführlichere Protokollierungsebenen ( -d für Debug, -dd für Trace)
-v : Überprüfen Sie die Signatur des heruntergeladenen Artefakts vor der Installation (erfordert die Installation von cosign ).
Schokoladend
Die schokoladige Verteilung von Grype wird von der Community gepflegt und nicht vom Anchore-Team verteilt.
choco install grype -y
Homebrew
Brauhahn Anchore/Grype
brew install grype
MacPorts
Unter macOS kann Grype zusätzlich über den von der Community verwalteten Port über MacPorts installiert werden:
Sudo-Port-Installation von Grype
Hinweis : Derzeit ist Grype nur für macOS und Linux entwickelt.
Aus der Quelle
Anweisungen zum Erstellen und Ausführen aus dem Quellcode finden Sie unter DEVELOPING.md.
GitHub-Aktionen
Wenn Sie GitHub Actions verwenden, können Sie unsere Grype-basierte Aktion verwenden, um während Ihrer CI-Workflows Schwachstellenscans für Ihren Code oder Container-Images durchzuführen.
Überprüfung der Artefakte
Prüfsummen werden auf alle Artefakte angewendet und die resultierende Prüfsummendatei wird mit cosign signiert.
Zur Signaturprüfung benötigen Sie folgendes Tool:
Cosign
Die Verifizierungsschritte lauten wie folgt:
Laden Sie die gewünschten Dateien sowie die Dateien checksums.txt, checksums.txt.pem und checksums.txt.sig von der Release-Seite herunter:
Sobald die Signatur als gültig bestätigt wurde, können Sie mit der Überprüfung fortfahren, ob die SHA256-Summen mit dem heruntergeladenen Artefakt übereinstimmen:
sha256sum --ignore-missing -c checksums.txt
Erste Schritte
Installieren Sie die Binärdatei und stellen Sie sicher, dass grype in Ihrem Pfad verfügbar ist. So scannen Sie ein Bild auf Schwachstellen:
grype
Der obige Befehl sucht nach sichtbaren Schwachstellen im Container (d. h. in der gestauchten Darstellung des Bildes). Um Software aus allen Image-Ebenen in den Schwachstellenscan einzubeziehen, unabhängig von ihrer Präsenz im endgültigen Image, stellen Sie --scope all-layers bereit:
grype --scope all-layers
Um Grype von einem Docker-Container aus auszuführen, damit es einen laufenden Container scannen kann, verwenden Sie den folgenden Befehl:
docker run --rm --volume /var/run/docker.sock:/var/run/docker.sock --name Grype Anchore/grype:latest $(ImageName):$(ImageTag)
Unterstützte Quellen
Grype kann eine Vielzahl von Quellen scannen, die über die in Docker hinausgehenden Quellen hinausgehen.
# scan a container image archive (from the result of `docker image save ...`, `podman save ...`, or `skopeo copy` commands)
grype path/to/image.tar
# scan a Singularity Image Format (SIF) container
grype path/to/image.sif
# scan a directory
grype dir:path/to/dir
Quellen können explizit mit einem Schema versehen werden:
podman:yourrepo/yourimage:tag use images from the Podman daemon
docker:yourrepo/yourimage:tag use images from the Docker daemon
docker-archive:path/to/yourimage.tar use a tarball from disk for archives created from "docker save"
oci-archive:path/to/yourimage.tar use a tarball from disk for OCI archives (from Skopeo or otherwise)
oci-dir:path/to/yourimage read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
singularity:path/to/yourimage.sif read directly from a Singularity Image Format (SIF) container on disk
dir:path/to/yourproject read directly from a path on disk (any directory)
file:path/to/yourfile read directly from a file on disk
sbom:path/to/syft.json read Syft JSON from path on disk
registry:yourrepo/yourimage:tag pull image directly from a registry (no container runtime required)
Wenn keine Bildquelle angegeben ist und anhand der angegebenen Referenz nicht erkannt werden kann, wird davon ausgegangen, dass das Bild vom Docker-Daemon abgerufen werden sollte. Wenn Docker nicht vorhanden ist, wird als nächstes versucht, den Podman-Daemon zu verwenden, gefolgt von der direkten Kontaktaufnahme mit der Image-Registrierung.
Dieses Standardverhalten kann mit der Konfigurationsoption default-image-pull-source überschrieben werden (weitere Einzelheiten finden Sie unter „Konfiguration“).
Verwenden Sie SBOMs für noch schnelleres Schwachstellen-Scannen in Grype:
# Then scan for new vulnerabilities as frequently as needed
grype sbom:./sbom.json
# (You can also pipe the SBOM into Grype)
cat ./sbom.json | grype
Grype unterstützt die Eingabe der SBOM-Formate Syft, SPDX und CycloneDX. Wenn Syft einen dieser Dateitypen generiert hat, sollte es über die entsprechenden Informationen verfügen, um ordnungsgemäß mit Grype zu funktionieren. Mit unterschiedlichem Erfolg ist es auch möglich, von anderen Tools generierte SBOMs zu verwenden. Zwei Dinge, die den Grype-Abgleich erfolgreicher machen, sind die Einbeziehung von CPE- und Linux-Distributionsinformationen. Wenn eine SBOM keine CPE-Informationen enthält, können diese mithilfe des Flags --add-cpes-if-none basierend auf Paketinformationen generiert werden. Um eine Distribution anzugeben, verwenden Sie das Flag --distro : . Ein vollständiges Beispiel ist:
Grype-Versionen vor v0.40.1 werden nicht unterstützt. Nicht unterstützte Versionen erhalten keine Software-Updates oder Aktualisierungen der Schwachstellendatenbank. Sie können weiterhin Schwachstellendatenbanken für nicht unterstützte Grype-Versionen erstellen, indem Sie frühere Versionen von vunnel verwenden, um die Upstream-Daten zu sammeln, und grype-db verwenden, um Datenbanken für nicht unterstützte Schemas zu erstellen.
Arbeiten mit Attesten
Grype unterstützt das Scannen von SBOMs als Eingabe über stdin. Benutzer können cosign verwenden, um Bescheinigungen mit einem SBOM als Inhalt zu überprüfen und ein Bild auf Schwachstellen zu scannen:
Sicherheitslücke : Alle Informationen zu der spezifischen Sicherheitslücke, die direkt zugeordnet wurde (z. B. ID, Schweregrad, CVSS-Score, Fehlerbehebungsinformationen, Links für weitere Informationen)
Zugehörige Schwachstellen : Informationen zu Schwachstellen, die im Zusammenhang mit der gemeldeten Hauptschwachstelle stehen. Möglicherweise handelte es sich bei der Schwachstelle, die wir gefunden haben, um einen GitHub-Sicherheitshinweis, der über ein Upstream-CVE (in der maßgeblichen nationalen Schwachstellendatenbank) verfügt. In diesen Fällen listen wir hier die Upstream-Schwachstellen auf.
MatchDetails : In diesem Abschnitt wird versucht zu erklären, wonach wir bei der Suche nach einer Übereinstimmung gesucht haben und welche Details zum Paket und zur Sicherheitslücke genau zu einer Übereinstimmung geführt haben.
Artefakt : Dies ist eine Teilmenge der Informationen, die wir über das Paket kennen (im Vergleich zur Syft-JSON-Ausgabe fassen wir den Metadatenabschnitt zusammen). Hier finden Sie Informationen darüber, wo im Container-Image oder Verzeichnis wir das Paket gefunden haben, um welche Art von Paket es sich handelt, Lizenzinformationen, pURLs, CPEs usw.
Ausgenommen Dateipfade
Grype kann Dateien und Pfade von der Überprüfung innerhalb einer Quelle ausschließen, indem es Glob-Ausdrücke mit einem oder mehreren --exclude Parametern verwendet:
grype --exclude './out/**/*.json' --exclude /etc
Hinweis: Beim Scannen von Bildern ist es möglich, absolute Pfade wie /etc oder /usr/**/*.txt zu verwenden, da das gesamte Dateisystem gescannt wird, während Verzeichnisscans Dateien relativ zum angegebenen Verzeichnis ausschließen. Beispiel: Das Scannen /usr/foo mit --exclude ./package.json würde /usr/foo/package.json ausschließen und --exclude '**/package.json' würde alle package.json Dateien unter /usr/foo ausschließen. /usr/foo . Für Verzeichnisscans ist es erforderlich, Pfadausdrücke mit ./ , */ oder **/ zu beginnen, die alle relativ zum angegebenen Scanverzeichnis aufgelöst werden. Bedenken Sie, dass Ihre Shell möglicherweise versucht, Platzhalter zu erweitern. Setzen Sie diese Parameter daher in einfache Anführungszeichen, z. B. '**/*.json' .
Externe Quellen
Grype kann so konfiguriert werden, dass es externe Datenquellen einbezieht, um die Genauigkeit beim Schwachstellenabgleich zu erhöhen. Diese Funktion ist derzeit standardmäßig deaktiviert. Um diese Funktion zu aktivieren, fügen Sie Folgendes zur Grype-Konfiguration hinzu:
Sie können die Basis-URL auch konfigurieren, wenn Sie eine andere Registrierung als Maven-Endpunkt verwenden.
Ausgabeformate
Das Ausgabeformat für Grype ist ebenfalls konfigurierbar:
grype -o
Folgende Formate sind verfügbar:
table : Eine spaltenförmige Zusammenfassung (Standard).
cyclonedx : Ein XML-Bericht, der der CycloneDX 1.6-Spezifikation entspricht.
cyclonedx-json : Ein JSON-Bericht, der der CycloneDX 1.6-Spezifikation entspricht.
json : Verwenden Sie dies, um so viele Informationen wie möglich aus Grype herauszuholen!
sarif : Verwenden Sie diese Option, um einen SARIF-Bericht (Static Analysis Results Interchange Format) zu erhalten.
template : Ermöglicht dem Benutzer die Angabe des Ausgabeformats. Siehe „Vorlagen verwenden“ weiter unten.
Verwendung von Vorlagen
Mit Grype können Sie mithilfe von Go-Vorlagen benutzerdefinierte Ausgabeformate definieren. So funktioniert es:
Definieren Sie Ihr Format als Go-Vorlage und speichern Sie diese Vorlage als Datei.
Setzen Sie das Ausgabeformat auf „template“ ( -o template ).
Geben Sie den Pfad zur Vorlagendatei an ( -t ./path/to/custom.template ).
Die Vorlagenverarbeitung von Grype verwendet dieselben Datenmodelle wie das json Ausgabeformat. Wenn Sie sich also fragen, welche Daten beim Erstellen einer Vorlage verfügbar sind, können Sie die Ausgabe von grype -o json als Referenz verwenden.
Bitte beachten Sie: Vorlagen können auf Informationen über das System zugreifen, auf dem sie ausgeführt werden, beispielsweise auf Umgebungsvariablen. Sie sollten niemals nicht vertrauenswürdige Vorlagen ausführen.
Im Vorlagenverzeichnis der Grype-Quelle gibt es mehrere Beispielvorlagen, die als Ausgangspunkt für ein benutzerdefiniertes Ausgabeformat dienen können. Beispielsweise erstellt csv.tmpl einen Schwachstellenbericht im CSV-Format (durch Kommas getrennte Werte):
An derselben Stelle finden Sie auch die Vorlage für das Standardausgabeformat „Tabelle“.
Grype enthält neben dem Standard-Golang-Text/-Template auch eine Vielzahl von Utility-Templating-Funktionen von Sprig, mit denen Benutzer die Ausgabe von Grype anpassen können.
Gating nach Schweregrad der Schwachstellen
Sie können Grype mit einem Fehler beenden lassen, wenn Schwachstellen mit oder über dem angegebenen Schweregrad gemeldet werden. Dies ist praktisch, wenn Sie Grype innerhalb eines Skripts oder einer CI-Pipeline verwenden. Verwenden Sie dazu das CLI-Flag --fail-on .
So können Sie beispielsweise einen Ausfall der CI-Pipeline auslösen, wenn im ubuntu:latest Image Schwachstellen mit einem Schweregrad von „mittel“ oder höher gefunden werden:
grype ubuntu:latest --fail-on medium
Angabe von Übereinstimmungen, die ignoriert werden sollen
Wenn Sie sehen, dass Grype Fehlalarme oder andere Schwachstellenübereinstimmungen meldet, die Sie einfach nicht sehen möchten, können Sie Grype anweisen, Übereinstimmungen zu ignorieren , indem Sie eine oder mehrere „Ignorierungsregeln“ in Ihrer Grype-Konfigurationsdatei angeben (z. B. ~/.grype.yaml ). Dies führt dazu, dass Grype keine Schwachstellenübereinstimmungen meldet, die die in einer Ihrer Ignorierregeln festgelegten Kriterien erfüllen.
Jede Regel kann eine beliebige Kombination der folgenden Kriterien angeben:
Paketsprache (z. B. "python" ; diese Werte werden hier definiert)
Pakettyp (z. B. "npm" ; diese Werte werden hier definiert)
Paketspeicherort (z. B. "/usr/local/lib/node_modules/**" ; unterstützt Glob-Muster)
Hier ist ein Beispiel ~/.grype.yaml , das das erwartete Format für Ignorierregeln demonstriert:
ignorieren: # Dies ist der vollständige Satz unterstützter Regelfelder:
- Schwachstelle: CVE-2008-4318 Fixstatus: unbekannt # VEX-Felder gelten, wenn Grype Vex-Daten liest: Vex-Status: not_affected Vex-Justification: vulnerable_code_not_present Paket: Name: libcurl Version: 1.5.1 Typ: npm Ort: „/ usr/local/lib/node_modules/**" # Wir können Regeln erstellen, die nur anhand der Schwachstellen-ID übereinstimmen:
- Schwachstelle: CVE-2014-54321 # ...oder nur durch ein einzelnes Paketfeld:
- Paket: Typ: gem
Schwachstellenübereinstimmungen werden ignoriert, wenn Regeln für die Übereinstimmung gelten. Es wird davon ausgegangen, dass eine Regel nur dann auf eine bestimmte Schwachstellenübereinstimmung anwendbar ist, wenn alle in der Regel angegebenen Felder auf die Schwachstellenübereinstimmung zutreffen.
Wenn Sie Grype ausführen und dabei Ignorierungsregeln angeben, geschieht Folgendes mit den Schwachstellenübereinstimmungen, die „ignoriert“ werden:
Ignorierte Übereinstimmungen werden vollständig in der Grype-Ausgabe ausgeblendet , außer bei Verwendung der json oder template Ausgabeformate; In diesen beiden Formaten werden die ignorierten Übereinstimmungen jedoch aus dem vorhandenen Array-Feld matchesentfernt und in ein neues Array-Feld ignoredMatches eingefügt. Jede aufgelistete ignorierte Übereinstimmung verfügt außerdem über ein zusätzliches Feld, appliedIgnoreRules , bei dem es sich um ein Array aller Regeln handelt, die dazu geführt haben, dass Grype diese Schwachstellenübereinstimmung ignoriert hat.
Ignorierte Übereinstimmungen werden bei der Entscheidung über den Exit-Status von Grype nicht berücksichtigt, wenn --fail-on verwendet wird. Wenn ein Benutzer beispielsweise --fail-on critical angibt und alle gefundenen Schwachstellenübereinstimmungen mit dem Schweregrad „kritisch“ ignoriert wurden, wird Grype den Ausgang auf Null setzen.
Hinweis: Bitte melden Sie weiterhin alle Fehlalarme, die Sie sehen! Selbst wenn Sie Falsch-Positive mithilfe von Ignorierregeln zuverlässig herausfiltern können, ist es für die Grype-Community sehr hilfreich, wenn wir so viel Wissen wie möglich über die Falsch-Positiven von Grype haben. Dies hilft uns, Grype kontinuierlich zu verbessern!
Es werden nur „behobene“ Schwachstellen angezeigt
Wenn Sie möchten, dass Grype nur Schwachstellen meldet, für die ein bestätigter Fix vorliegt , können Sie das Flag --only-fixed verwenden. (Dadurch werden der Grype-Konfiguration automatisch Ignorierregeln hinzugefügt, sodass nicht behobene Schwachstellen ignoriert werden.)
Hier ist zum Beispiel ein Scan von Alpine 3.10:
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical
libcrypto1.1 1.1.1k-r0 CVE-2021-3711 Critical
libcrypto1.1 1.1.1k-r0 CVE-2021-3712 High
libssl1.1 1.1.1k-r0 CVE-2021-3712 High
libssl1.1 1.1.1k-r0 CVE-2021-3711 Critical
...und hier ist der gleiche Scan, aber mit dem Flag --only-fixed :
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical
Wenn Sie möchten, dass Grype nur Schwachstellen meldet , für die es keinen bestätigten Fix gibt , können Sie das Flag --only-notfixed verwenden. Alternativ können Sie das Flag --ignore-states verwenden, um Ergebnisse nach Schwachstellen mit bestimmten Status zu filtern, z. B. wont-fix (siehe --help für eine Liste gültiger Fixstatus). Diese Flags fügen der Grype-Konfiguration automatisch Ignorierregeln hinzu, sodass Schwachstellen, die behoben sind oder nicht behoben werden, ignoriert werden.
VEX-Unterstützung
Grype kann VEX-Daten (Vulnerability Exploitability Exchange) verwenden, um Fehlalarme herauszufiltern oder zusätzlichen Kontext bereitzustellen und so Übereinstimmungen zu verbessern. Beim Scannen eines Container-Images können Sie das Flag --vex verwenden, um auf ein oder mehrere OpenVEX-Dokumente zu verweisen.
VEX-Anweisungen beziehen sich auf ein Produkt (ein Container-Image), eine Schwachstelle und einen VEX-Status, um eine Aussage über die Auswirkungen der Schwachstelle auszudrücken. Es gibt vier VEX-Status: not_affected , affected , fixed und under_investigation .
Hier ist ein Beispiel für ein einfaches OpenVEX-Dokument. (Tipp: Verwenden Sie vexctl um Ihre eigenen Dokumente zu generieren).
Standardmäßig verwendet Grype alle Anweisungen in bestimmten VEX-Dokumenten mit dem Status not_affected oder fixed um Übereinstimmungen in den Ignoriersatz zu verschieben.
Alle aufgrund von VEX-Anweisungen ignorierten Übereinstimmungen werden bei Verwendung von --show-suppressed gekennzeichnet:
libcrypto3 3.0.8-r3 3.0.8-r4 apk CVE-2023-1255 Medium (suppressed by VEX)
Anweisungen mit dem Status affected oder under_investigation werden nur dann zur Erweiterung des Ergebnissatzes berücksichtigt, wenn sie ausdrücklich über die Umgebungsvariable GRYPE_VEX_ADD oder in einer Konfigurationsdatei angefordert werden.
VEX-Ignorierungsregeln
Es können Ignorierungsregeln geschrieben werden, um zu steuern, wie Grype VEX-Anweisungen berücksichtigt. Um beispielsweise Grype so zu konfigurieren, dass es nur auf VEX-Anweisungen reagiert, wenn die Begründung vulnerable_code_not_present lautet, können Sie eine Regel wie diese schreiben:
Einzelheiten finden Sie in der Liste der Begründungen. Sie können vex-status und vex-justification mit anderen Ignorierregelparametern kombinieren.
Grypes Datenbank
Wenn Grype einen Scan nach Schwachstellen durchführt, verwendet es dazu eine Schwachstellendatenbank, die in Ihrem lokalen Dateisystem gespeichert ist und durch den Abruf von Daten aus verschiedenen öffentlich verfügbaren Schwachstellendatenquellen erstellt wird. Zu diesen Quellen gehören:
Alpine Linux SecDB: https://secdb.alpinelinux.org/
Amazon Linux ALAS: https://alas.aws.amazon.com/AL2/alas.rss
Standardmäßig verwaltet Grype diese Datenbank automatisch für Sie. Grype sucht nach neuen Updates für die Schwachstellendatenbank, um sicherzustellen, dass bei jedem Scan aktuelle Schwachstelleninformationen verwendet werden. Dieses Verhalten ist konfigurierbar. Weitere Informationen finden Sie im Abschnitt „Grype-Datenbank verwalten“.
So funktionieren Datenbankaktualisierungen
Die Schwachstellendatenbank von Grype ist eine SQLite-Datei mit dem Namen vulnerability.db . Aktualisierungen der Datenbank sind atomar: Die gesamte Datenbank wird ersetzt und dann von Grype als „schreibgeschützt“ behandelt.
Der erste Schritt von Grype bei einem Datenbank-Update besteht darin, Datenbanken zu ermitteln, die zum Abruf verfügbar sind. Grype tut dies, indem es eine „Listing-Datei“ von einem öffentlichen Endpunkt anfordert:
Mit diesen Informationen kann Grype die richtige Datenbank auswählen (die zuletzt erstellte Datenbank mit der aktuellen Schemaversion), die Datenbank herunterladen und die Integrität der Datenbank anhand des aufgelisteten checksum überprüfen.
Verwalten der Grype-Datenbank
Hinweis: Bei normaler Nutzung besteht für Benutzer keine Notwendigkeit, die Grype-Datenbank zu verwalten! Grype verwaltet seine Datenbank im Hintergrund. Für Benutzer, die mehr Kontrolle benötigen, bietet Grype jedoch Optionen zur expliziteren Verwaltung der Datenbank.
Lokales Datenbank-Cache-Verzeichnis
Standardmäßig wird die Datenbank im lokalen Dateisystem im Verzeichnis $XDG_CACHE_HOME/grype/db// zwischengespeichert. Unter macOS würde die Datenbank beispielsweise in ~/Library/Caches/grype/db/3/ gespeichert. (Weitere Informationen zu XDG-Pfaden finden Sie in der XDG-Basisverzeichnisspezifikation.)
Sie können den Cache-Verzeichnispfad mithilfe der Umgebungsvariablen GRYPE_DB_CACHE_DIR festlegen. Wenn das Festlegen dieser Variablen allein nicht funktioniert, muss möglicherweise auch die Umgebungsvariable TMPDIR festgelegt werden.
Veraltete Daten
Grype benötigt aktuelle Schwachstelleninformationen, um genaue Übereinstimmungen bereitzustellen. Standardmäßig schlägt die Ausführung fehl, wenn die lokale Datenbank in den letzten 5 Tagen nicht erstellt wurde. Die Datenveraltungsprüfung kann über die Umgebungsvariablen GRYPE_DB_MAX_ALLOWED_BUILT_AGE und GRYPE_DB_VALIDATE_AGE oder die Felder max-allowed-built-age und validate-age unter db konfiguriert werden. Es verwendet die Zeitdauersyntax von Golang. Legen Sie GRYPE_DB_VALIDATE_AGE oder validate-age auf false fest, um die Verjährungsprüfung zu deaktivieren.
Offline- und Air-Gap-Umgebungen
Standardmäßig prüft Grype bei jedem Start, ob eine neue Datenbank vorhanden ist, indem es einen Netzwerkaufruf über das Internet durchführt. Sie können Grype anweisen, diese Prüfung nicht durchzuführen, indem Sie die Umgebungsvariable GRYPE_DB_AUTO_UPDATE auf false setzen.
Solange Sie die Dateien vulnerability.db und metadata.json von Grype im Cache-Verzeichnis für die erwartete Schemaversion ablegen, muss Grype nicht auf das Netzwerk zugreifen. Darüber hinaus können Sie mit dem Befehl grype db list in einer Online-Umgebung eine Liste der zum Herunterladen verfügbaren Datenbankarchive abrufen, das Datenbankarchiv herunterladen, es in Ihre Offline-Umgebung übertragen und grype db import “ verwenden Verwenden Sie die angegebene Datenbank offline.
Wenn Sie Ihre eigenen Grype-Datenbanken intern verteilen möchten, ohne db import manuell verwenden zu müssen, können Sie den DB-Update-Mechanismus von Grype nutzen. Dazu können Sie Ihre eigene Datei listing.json erstellen, die der öffentlich gefundenen Datei ähnelt (siehe grype db list -o raw für ein Beispiel unserer öffentlichen Datei listing.json ) und die Download-URL so ändern, dass sie auf einen internen Endpunkt verweist (z. B ein privater S3-Bucket, ein interner Dateiserver usw.). Jede interne Installation von Grype kann Datenbankaktualisierungen automatisch empfangen, indem die db.update-url (wie die Umgebungsvariable GRYPE_DB_UPDATE_URL ) so konfiguriert wird, dass sie auf die von Ihnen erstellte gehostete listing.json verweist.
CLI-Befehle für die Datenbankverwaltung
Grype stellt datenbankspezifische CLI-Befehle für Benutzer bereit, die die Datenbank über die Befehlszeile steuern möchten. Hier sind einige der nützlichen Befehle:
grype db status – Melden Sie den aktuellen Status der Grype-Datenbank (z. B. Speicherort, Erstellungsdatum und Prüfsumme).
grype db check – prüfen, ob Updates für die Datenbank verfügbar sind
grype db update – Stellen Sie sicher, dass die neueste Datenbank in das Cache-Verzeichnis heruntergeladen wurde (Grype führt diesen Vorgang standardmäßig zu Beginn jedes Scans durch)
grype db list – Laden Sie die unter db.update-url konfigurierte Listendatei herunter und zeigen Sie Datenbanken an, die zum Download verfügbar sind
grype db import – Stellen Sie Grype ein Datenbankarchiv zur expliziten Verwendung bereit (nützlich für Offline-DB-Updates).
grype db providers – bietet eine detaillierte Liste der Datenbankanbieter
Vollständige Informationen zu den Datenbankbefehlen von Grype finden Sie, indem Sie grype db --help ausführen.
Shell-Fertigstellung
Grype bietet Shell-Vervollständigung durch seine CLI-Implementierung (cobra). Generieren Sie den Abschlusscode für Ihre Shell, indem Sie einen der folgenden Befehle ausführen:
grype completion
go run ./cmd/grype completion
Dadurch wird ein Shell-Skript an STDOUT ausgegeben, das dann als Abschlussskript für Grype verwendet werden kann. Wenn Sie einen der oben genannten Befehle mit den Flags -h oder --help ausführen, erhalten Sie Anweisungen dazu für die von Ihnen gewählte Shell.
Private Registrierungsauthentifizierung
Lokale Docker-Anmeldeinformationen
Wenn keine Containerlaufzeit vorhanden ist, kann Grype dennoch Anmeldeinformationen verwenden, die in allgemeinen Anmeldeinformationsquellen konfiguriert sind (z. B. ~/.docker/config.json ). Mithilfe dieser Anmeldeinformationen werden Bilder aus privaten Registern abgerufen. In der Konfigurationsdatei werden Ihre Anmeldeinformationen gespeichert, wenn Sie sich über einen Befehl wie docker login bei privaten Registrierungsstellen authentifizieren. Weitere Informationen finden Sie in der Dokumentation go-containerregistry .
Sie können den folgenden Befehl als Beispiel ausführen. Es beschreibt die Mount-/Umgebungskonfiguration, die ein Container benötigt, um auf eine private Registry zuzugreifen:
docker run -v ./config.json:/config/config.json -e "DOCKER_CONFIG=/config" anchore/grype:latest
Docker-Anmeldeinformationen in Kubernetes
Der folgende Abschnitt zeigt einen einfachen Arbeitsablauf zum Mounten dieser Konfigurationsdatei als Geheimnis in einem Container auf Kubernetes.
Erstellen Sie ein Geheimnis. Der Wert von config.json ist wichtig. Es bezieht sich auf die hier aufgeführte Spezifikation. Unterhalb dieses Abschnitts befindet sich die Datei secret.yaml , die die Pod-Konfiguration als Volume nutzt. Wichtig ist der Schlüssel config.json . Dies wird am Ende der Name der Datei sein, wenn sie in den Pod gemountet wird.
Erstellen Sie Ihren Pod mit Ggype. Die Umgebung DOCKER_CONFIG ist wichtig, da sie angibt, wo nach der Anmeldeinformationsdatei gesucht werden soll. Im folgenden Beispiel wird Grype durch die Einstellung DOCKER_CONFIG=/config darüber informiert, dass Anmeldeinformationen unter /config/config.json zu finden sind. Aus diesem Grund haben wir config.json als Schlüssel für unser Geheimnis verwendet. Beim Mounten in Containern wird der Schlüssel des Geheimnisses als Dateiname verwendet. Der Abschnitt volumeMounts stellt unser Geheimnis in /config bereit. Der Abschnitt volumes benennt unser Volume und nutzt das Geheimnis, das wir in Schritt eins erstellt haben.
Der Benutzer kann jetzt kubectl logs grype-private-registry-demo ausführen. Die Protokolle sollten die Grype-Analyse für das in der Pod-Konfiguration bereitgestellte anzeigen.
Mithilfe der oben genannten Informationen sollten Benutzer in der Lage sein, den privaten Registrierungszugriff zu konfigurieren, ohne dies in den grype oder syft -Konfigurationsdateien tun zu müssen. Sie sind auch nicht auf einen Docker-Daemon (oder eine andere Laufzeitsoftware) für die Registrierungskonfiguration und den Zugriff angewiesen.
Konfiguration
Standard-Konfigurationssuchpfade (alle mit grype config locations anzeigen):
.grype.yaml
.grype/config.yaml
~/.grype.yaml
/grype/config.yaml
Verwenden Sie grype config um eine Beispielkonfigurationsdatei auf stdout zu drucken. Verwenden Sie grype config --load , um die aktuelle Konfiguration auszudrucken, nachdem alle Werte in stdout geladen wurden.
Sie können Dateien direkt mit den Flags --config / -c angeben, um Ihre eigenen Konfigurationsdateien/Pfade bereitzustellen:
grype -c /path/to/config.yaml
Konfigurationsoptionen (Beispielwerte sind die Standardwerte):
# Überprüfung auf Anwendungsaktualisierungen beim Start aktivieren/deaktivieren# dasselbe wie GRYPE_CHECK_FOR_APP_UPDATE env varcheck-for-app-update: true# ermöglicht Benutzern die Angabe, welche Bildquelle zum Generieren des SBOM verwendet werden soll# Gültige Werte sind: Registry, Docker, Podman# dasselbe wie GRYPE_DEFAULT_IMAGE_PULL_SOURCE env vardefault-image-pull-source: ""# dasselbe wie --name; Legen Sie den Namen des zu analysierenden Ziels fest. Name: „“# Wenn beim Scannen ein Schweregrad mit oder über dem angegebenen Schweregrad gefunden wird, lautet der Rückgabecode 1#. Standardmäßig ist er nicht gesetzt, wodurch diese Validierung übersprungen wird (Optionen: vernachlässigbar, niedrig, mittel). , hoch, kritisch)# dasselbe wie --fail-on ; GRYPE_FAIL_ON_SEVERITY env varfail-on-severity: „“# das Ausgabeformat des Schwachstellenberichts (Optionen: Tabelle, Vorlage, JSON, Cyclonedx)# Wenn Sie Vorlage als Ausgabetyp verwenden, müssen Sie auch einen Wert für „output-template-“ angeben. file'# dasselbe wie -o ; GRYPE_OUTPUT env varoutput: „table“# Wenn Sie die Vorlagenausgabe verwenden, müssen Sie einen Pfad zu einer Go-Vorlagendatei angeben.# Weitere Informationen zur Vorlagenausgabe finden Sie unter https://github.com/anchore/grype#using-templates.# Der Standardpfad Bei der Vorlagendatei handelt es sich um das aktuelle Arbeitsverzeichnis# Output-Template-File: .grype/html.tmpl# Ausgabebericht in eine Datei schreiben (Standard ist das Schreiben in stdout)# dasselbe wie --file; GRYPE_FILE env varfile: ""# eine Liste von Globs, die vom Scan ausgeschlossen werden sollen, zum Beispiel:#exclude:# - '/etc/**'# - './out/**/*.json'# dasselbe wie -- ausschließen; GRYPE_EXCLUDE env varexclude: []# Übereinstimmungen auf Kernel-Header-Paketen einschließen, die mit dem Upstream-Kernel-Paket abgeglichen werden# wenn „falsch“, werden solche Übereinstimmungen als „ignoriert“ markiert.match-upstream-kernel-headers: false# Betriebssystem und/oder Architektur, die wann verwendet werden sollen Verweisen auf Container-Images (z. B. „windows/armv6“ oder „arm64“)# dasselbe wie --platform; GRYPE_PLATFORM env varplatform: „“# Bei Verwendung der SBOM-Eingabe automatisch CPEs generieren, wenn Pakete „noneadd-cpes-if-none: false“ haben. Geben Sie explizit eine zu verwendende Linux-Distribution als : wie alpine:3.10distro:external an -sources: enable: false maven: search-upstream-by-sha1: true base-url: https://repo1.maven.org/maven2db: # bei der Ausführung auf Datenbankaktualisierungen prüfen # dasselbe wie GRYPE_DB_AUTO_UPDATE env var auto-update: true # Speicherort zum Schreiben des Caches der Schwachstellendatenbank; Standardmäßig ist $XDG_CACHE_HOME/grype/db # dasselbe wie GRYPE_DB_CACHE_DIR env var cache-dir: "" # URL der Schwachstellendatenbank # dasselbe wie GRYPE_DB_UPDATE_URL env var update-url: "https://toolbox-data.anchore.io/grype /databases/listing.json" # stellt sicher, dass der DB-Build nicht älter als das maximal zulässige Build-Alter ist. # Auf „false“ setzen, um die Überprüfung zu deaktivieren. „validate-age: true“ # Maximal zulässiges Alter für die Schwachstellendatenbank, wobei # das Alter die seither vergangene Zeit angibt es wurde erstellt # Das standardmäßige maximale Alter beträgt 120 Stunden (oder fünf Tage) max-allowed-built-age: „120h“ # Zeitüberschreitung beim Herunterladen von GRYPE_DB_UPDATE_URL, um zu sehen, ob die Datenbank heruntergeladen werden muss # Diese Datei hat eine Größe von ~156 KiB (Stand: 2024–04). -17, daher sollte der Download schnell gehen; Bei Bedarf anpassen update-available-timeout: „30s“ # Timeout für das Herunterladen der tatsächlichen Schwachstellen-Datenbank # Die Datenbank ist mit Stand vom 17.04.2024 ~156 MB groß, daher können langsamere Verbindungen das Standard-Timeout überschreiten; nach Bedarf anpassen update-download-timeout: „120s“search: # der Suchraum zum Suchen nach Paketen (Optionen: alle Ebenen, gestaucht) # dasselbe wie -s ; GRYPE_SEARCH_SCOPE env var Scope: „squashed“ # Suche in Archiven, die einen Dateiindex zum Durchsuchen enthalten (zip) # Hinweis: Dies gilt vorerst nur für den Java-Paketkatalogisierer # dasselbe wie GRYPE_PACKAGE_SEARCH_INDEXED_ARCHIVES env var indexed-archives: true # Suche in Archiven, die keinen Dateiindex zum Durchsuchen enthalten (tar, tar.gz, tar.bz2 usw.) # Hinweis: Das Aktivieren dieser Option kann zu Leistungseinbußen führen, da alle erkannten komprimierten Tars dekomprimiert werden Gilt nur für den Java-Paketkatalog. # Gleich wie GRYPE_PACKAGE_SEARCH_UNINDEXED_ARCHIVES env var unindexed-archives: false# Optionen beim direkten Abrufen aus einer Registrierung über das Schema „registry:“registry: # TLS-Überprüfung überspringen, wenn mit der Registrierung kommuniziert # gleich wie GRYPE_REGISTRY_INSECURE_SKIP_TLS_VERIFY env var unsicher -skip-tls-verify: false # HTTP anstelle von https verwenden, wenn eine Verbindung zur Registrierung hergestellt wird # dasselbe wie GRYPE_REGISTRY_INSECURE_USE_HTTP env var insecure-use-http: false # Dateipfad zu einem CA-Zertifikat (oder einem Verzeichnis mit *.crt, *.cert, *.pem), der zum Generieren des Client-Zertifikats verwendet wird # GRYPE_REGISTRY_CA_CERT env var ca-cert: "" # Anmeldeinformationen für bestimmte Registrierungen auth: # die URL zur Registrierung (z. B. „docker.io“, „localhost:5000“ usw.) # GRYPE_REGISTRY_AUTH_AUTHORITY Umgebungsvariable
- Autorität: "" # GRYPE_REGISTRY_AUTH_USERNAME env var Benutzername: "" # GRYPE_REGISTRY_AUTH_PASSWORD env var Passwort: "" # Hinweis: Token und Benutzername/Passwort schließen sich gegenseitig aus # GRYPE_REGISTRY_AUTH_TOKEN env var token: "" # Dateipfad zum Client-Zertifikat, das für die TLS-Authentifizierung verwendet wird zur Registrierung # GRYPE_REGISTRY_AUTH_TLS_CERT env var tls-cert: "" # Dateipfad zum Client-Schlüssel, der für die TLS-Authentifizierung bei der Registrierung verwendet wird # GRYPE_REGISTRY_AUTH_TLS_KEY env var tls-key: "" # - ... # Hinweis: Weitere Anmeldeinformationen können über bereitgestellt werden Nur Konfigurationsdatei (nicht env vars)log: # alle Ausgaben unterdrücken (außer der Schwachstellenliste) # dasselbe wie -q ; GRYPE_LOG_QUIET env var quiet: false # Ausführlichkeit erhöhen # dasselbe wie GRYPE_LOG_VERBOSITY env var verbosity: 0 # die Protokollebene; Hinweis: Detaillierte Protokollierung unterdrückt das ETUI # dasselbe wie GRYPE_LOG_LEVEL env var # Verwendet Logrus-Protokollierungsebenen: https://github.com/sirupsen/logrus#level-logging level: "error" # Speicherort zum Schreiben der Protokolldatei (Standard ist nicht). um eine Protokolldatei zu haben) # dasselbe wie GRYPE_LOG_FILE env var file: „“match: # legt die folgenden Matcher fest, um cpes zu verwenden, wenn versucht wird, # Schwachstellenübereinstimmungen zu finden. Der Bestands-Matcher ist die Standardnummer, wenn kein primärer Matcher identifiziert werden kann. Java: using-cpes: false Python: using-cpes: false Javascript: using-cpes: false Ruby: using-cpes: false Dotnet: using-cpes: false Golang: using-cpes: false # auch wenn der CPE-Abgleich deaktiviert ist, Machen Sie eine Ausnahme, wenn Sie nach „stdlib“ suchen. Always-use-cpe-for-stdlib: true # Ermöglicht die Verwendung von Pseudoversionen des Hauptmoduls, die von Syft möglicherweise nur „erraten“ wurden, beim Schwachstellenabgleich. Allow-main-module-pseudo-version-comparison: false stock : using-cpes: wahr
Zukunftspläne
Folgende Bereiche potenzieller Entwicklung werden derzeit untersucht:
Unterstützung für Zulassungsliste und Paketzuordnung
