Un scanner de vulnérabilités pour les images de conteneurs et les systèmes de fichiers. Installez facilement le binaire pour l'essayer. Fonctionne avec Syft, le puissant outil SBOM (facture logicielle) pour les images de conteneurs et les systèmes de fichiers.
Ordre du jour : https://docs.google.com/document/d/1ZtSAa6fj2a6KRWviTn3WoJm09edvrNUp4Iz_dOjjyY8/edit?usp=sharing (rejoignez ce groupe pour un accès en écriture)
Tous sont les bienvenus !
Pour les options de support commercial avec Syft ou Grype, veuillez contacter Anchore
Caractéristiques
Analysez le contenu d'une image de conteneur ou d'un système de fichiers pour rechercher les vulnérabilités connues.
Recherchez les vulnérabilités des principaux packages de systèmes d'exploitation :
Alpin
Amazon Linux
OccupéBox
CentOS
CBL-Marin
Debian
Sans distribution
Oracle-Linux
Chapeau rouge (RHEL)
Ubuntu
Wolfi
Recherchez les vulnérabilités des packages spécifiques à une langue :
-d : niveaux de journalisation plus détaillés ( -d pour le débogage, -dd pour la trace)
-v : Vérifiez la signature de l'artefact téléchargé avant l'installation (nécessite l'installation cosign )
Chocolaté
La distribution chocolatée de grype est entretenue par la communauté et n'est pas distribuée par l'équipe d'ancrage.
choco installer grype -y
Homebrew
robinet de brassage ancre/grype
brasser installer grype
MacPorts
Sur macOS, Grype peut également être installé à partir du port géré par la communauté via MacPorts :
sudo port installer le groupe
Remarque : Actuellement, Grype est conçu uniquement pour macOS et Linux.
De la source
Voir DEVELOPING.md pour obtenir des instructions sur la création et l'exécution à partir des sources.
Actions GitHub
Si vous utilisez GitHub Actions, vous pouvez utiliser notre action basée sur Grype pour exécuter des analyses de vulnérabilité sur votre code ou vos images de conteneur pendant vos flux de travail CI.
Vérification des artefacts
Les sommes de contrôle sont appliquées à tous les artefacts et le fichier de somme de contrôle résultant est signé en utilisant cosign.
Vous avez besoin de l'outil suivant pour vérifier la signature :
Cosigner
Les étapes de vérification sont les suivantes :
Téléchargez les fichiers souhaités, ainsi que les fichiers checksums.txt, checksums.txt.pem et checksums.txt.sig depuis la page des versions :
Une fois la signature confirmée comme valide, vous pouvez procéder à la validation de l'alignement des sommes SHA256 avec l'artefact téléchargé :
sha256sum --ignore-missing -c checksums.txt
Commencer
Installez le binaire et assurez-vous que grype est disponible sur votre chemin. Pour rechercher des vulnérabilités dans une image :
grype
La commande ci-dessus recherche les vulnérabilités visibles dans le conteneur (c'est-à-dire la représentation écrasée de l'image). Pour inclure les logiciels de toutes les couches d'image dans l'analyse de vulnérabilité, quelle que soit leur présence dans l'image finale, fournissez --scope all-layers :
grype --scope all-layers
Pour exécuter grype à partir d'un conteneur Docker afin qu'il puisse analyser un conteneur en cours d'exécution, utilisez la commande suivante :
docker run --rm --volume /var/run/docker.sock:/var/run/docker.sock --name Grype Anchore/grype:latest $(ImageName):$(ImageTag)
Sources prises en charge
Grype peut analyser une variété de sources au-delà de celles trouvées dans Docker.
# 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
Les sources peuvent être explicitement fournies avec un schéma :
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)
Si une source d'image n'est pas fournie et ne peut pas être détectée à partir de la référence donnée, il est supposé que l'image doit être extraite du démon Docker. Si Docker n'est pas présent, le démon Podman est ensuite tenté, suivi d'un dernier contact direct avec le registre d'images.
Ce comportement par défaut peut être remplacé par l'option de configuration default-image-pull-source (voir Configuration pour plus de détails).
Utilisez les SBOM pour une analyse des vulnérabilités encore plus rapide dans 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 prend en charge la saisie des formats Syft, SPDX et CycloneDX SBOM. Si Syft a généré l'un de ces types de fichiers, ils doivent disposer des informations appropriées pour fonctionner correctement avec Grype. Il est également possible d’utiliser des SBOM générés par d’autres outils avec plus ou moins de succès. Deux choses qui rendent la correspondance Grype plus réussie sont l'inclusion des informations sur la distribution CPE et Linux. Si un SBOM n'inclut aucune information CPE, il est possible de les générer sur la base des informations du package à l'aide de l'indicateur --add-cpes-if-none . Pour spécifier une distribution, utilisez l'indicateur --distro : . Un exemple complet est :
Toute version de Grype antérieure à la v0.40.1 n'est pas prise en charge. Les versions non prises en charge ne recevront aucune mise à jour logicielle ni mise à jour de la base de données de vulnérabilités. Vous pouvez toujours créer des bases de données de vulnérabilités pour les versions de Grype non prises en charge en utilisant les versions précédentes de Vunnel pour collecter les données en amont et de Grype-db pour créer des bases de données pour les schémas non pris en charge.
Travailler avec des attestations
Grype prend en charge l'analyse des SBOM en entrée via stdin. Les utilisateurs peuvent utiliser la cosignature pour vérifier les attestations avec un SBOM comme contenu afin d'analyser une image à la recherche de vulnérabilités :
Vulnérabilité : toutes les informations sur la vulnérabilité spécifique qui a été directement mise en correspondance (par exemple, ID, gravité, score CVSS, informations sur le correctif, liens pour plus d'informations)
RelatedVulnerabilities : informations relatives aux vulnérabilités jugées liées à la principale vulnérabilité signalée. Peut-être que la vulnérabilité sur laquelle nous avons comparé était un avis de sécurité GitHub, qui possède un CVE en amont (dans la base de données nationale de vulnérabilités faisant autorité). Dans ces cas, nous listons ici les vulnérabilités en amont.
MatchDetails : Cette section tente d'expliquer ce que nous avons recherché lors de la recherche d'une correspondance et exactement quels détails sur le package et la vulnérabilité qui conduisent à une correspondance.
Artefact : Il s'agit d'un sous-ensemble des informations que nous connaissons sur le package (par rapport à la sortie Syft json, nous résumons la section métadonnées). Celui-ci contient des informations sur l'endroit où dans l'image ou le répertoire du conteneur nous avons trouvé le package, de quel type de package il s'agit, des informations sur la licence, les pURL, les CPE, etc.
Exclure les chemins de fichiers
Grype peut exclure les fichiers et les chemins de l'analyse dans une source en utilisant des expressions globales avec un ou plusieurs paramètres --exclude :
grype --exclude './out/**/*.json' --exclude /etc
Remarque : dans le cas de l'analyse d'images , puisque l'ensemble du système de fichiers est analysé, il est possible d'utiliser des chemins absolus comme /etc ou /usr/**/*.txt alors que les analyses de répertoire excluent les fichiers relatifs au répertoire spécifié . Par exemple : analyser /usr/foo avec --exclude ./package.json exclurait /usr/foo/package.json et --exclude '**/package.json' exclurait tous les fichiers package.json sous /usr/foo . Pour les analyses de répertoire , il est nécessaire de commencer les expressions de chemin par ./ , */ ou **/ , qui seront toutes résolues par rapport au répertoire d'analyse spécifié . Gardez à l'esprit que votre shell peut tenter d'étendre les caractères génériques, alors mettez ces paramètres entre guillemets simples, comme : '**/*.json' .
Sources externes
Grype peut être configuré pour incorporer des sources de données externes pour une fidélité accrue dans la correspondance des vulnérabilités. Cette fonctionnalité est actuellement désactivée par défaut. Pour activer cette fonctionnalité, ajoutez ce qui suit à la configuration de grype :
Vous pouvez également configurer l'URL de base si vous utilisez un autre registre comme point de terminaison Maven.
Formats de sortie
Le format de sortie pour Grype est également configurable :
grype -o
Où les formats disponibles sont:
table : Un résumé en colonnes (par défaut).
cyclonedx : Un rapport XML conforme à la spécification CycloneDX 1.6.
cyclonedx-json : Un rapport JSON conforme à la spécification CycloneDX 1.6.
json : utilisez-le pour obtenir autant d'informations que possible sur Grype !
sarif : utilisez cette option pour obtenir un rapport SARIF (Static Analysis Results Interchange Format)
template : Permet à l'utilisateur de spécifier le format de sortie. Voir « Utilisation de modèles » ci-dessous.
Utiliser des modèles
Grype vous permet de définir des formats de sortie personnalisés, à l'aide de modèles Go. Voici comment cela fonctionne :
Définissez votre format en tant que modèle Go et enregistrez ce modèle sous forme de fichier.
Définissez le format de sortie sur "modèle" ( -o template ).
Spécifiez le chemin d'accès au fichier modèle ( -t ./path/to/custom.template ).
Le traitement des modèles de Grype utilise les mêmes modèles de données que le format de sortie json . Ainsi, si vous vous demandez quelles données sont disponibles lorsque vous créez un modèle, vous pouvez utiliser la sortie de grype -o json comme référence.
Remarque : les modèles peuvent accéder à des informations sur le système sur lequel ils s'exécutent, telles que les variables d'environnement. Vous ne devez jamais exécuter de modèles non fiables.
Il existe plusieurs exemples de modèles dans le répertoire templates de la source Grype qui peuvent servir de point de départ pour un format de sortie personnalisé. Par exemple, csv.tmpl produit un rapport de vulnérabilité au format CSV (valeurs séparées par des virgules) :
Vous pouvez également trouver le modèle du format de sortie « tableau » par défaut au même endroit.
Grype comprend également une vaste gamme de fonctions de création de modèles utilitaires de Sprig en dehors du texte/modèle Golang par défaut pour permettre aux utilisateurs de personnaliser la sortie de Grype.
Contrôle de la gravité des vulnérabilités
Vous pouvez faire en sorte que Grype se termine avec une erreur si des vulnérabilités sont signalées au niveau ou au-dessus du niveau de gravité spécifié. Cela s'avère pratique lorsque vous utilisez Grype dans un script ou un pipeline CI. Pour ce faire, utilisez l'indicateur CLI --fail-on .
Par exemple, voici comment déclencher une défaillance du pipeline CI si des vulnérabilités sont détectées dans l'image ubuntu:latest avec une gravité « moyenne » ou supérieure :
grype ubuntu:latest --fail-on medium
Spécifier les correspondances à ignorer
Si vous voyez Grype signaler des faux positifs ou toute autre correspondance de vulnérabilité que vous ne voulez tout simplement pas voir, vous pouvez demander à Grype d' ignorer les correspondances en spécifiant une ou plusieurs « règles d'ignorer » dans votre fichier de configuration Grype (par exemple ~/.grype.yaml ). Cela amène Grype à ne signaler aucune correspondance de vulnérabilité répondant aux critères spécifiés par l'une de vos règles d'ignorance.
Chaque règle peut spécifier n'importe quelle combinaison des critères suivants :
ID de vulnérabilité (par exemple "CVE-2008-4318" )
langage du package (par exemple "python" ; ces valeurs sont définies ici)
type de package (par exemple "npm" ; ces valeurs sont définies ici)
emplacement du package (par exemple "/usr/local/lib/node_modules/**" ; prend en charge les modèles globaux)
Voici un exemple ~/.grype.yaml qui montre le format attendu pour les règles d'ignorance :
ignorer : # Voici l'ensemble complet des champs de règles pris en charge :
- vulnérabilité : CVE-2008-4318 fix-state : inconnu # Les champs VEX s'appliquent lorsque Grype lit les données vex : vex-status : not_affected vex-justification : vulnérable_code_not_present package : nom : libcurl version : 1.5.1 type : npm emplacement : "/ usr/local/lib/node_modules/**" # Nous pouvons créer des règles correspondant simplement par ID de vulnérabilité :
- vulnérabilité : CVE-2014-54321 # ...ou juste par un seul champ de package :
- paquet : type : gemme
Les correspondances de vulnérabilité seront ignorées si des règles s’appliquent à la correspondance. Une règle est considérée comme s'appliquant à une correspondance de vulnérabilité donnée uniquement si tous les champs spécifiés dans la règle s'appliquent à la correspondance de vulnérabilité.
Lorsque vous exécutez Grype tout en spécifiant des règles d'ignorance, les événements suivants se produisent avec les correspondances de vulnérabilités « ignorées » :
Les correspondances ignorées sont complètement masquées de la sortie de Grype, sauf lors de l'utilisation des formats de sortie json ou template ; cependant, dans ces deux formats, les correspondances ignorées sont supprimées du champ de tableau matches existant et elles sont placées dans un nouveau champ de tableau de ignoredMatches . Chaque correspondance ignorée répertoriée comporte également un champ supplémentaire, appliedIgnoreRules , qui est un tableau de toutes les règles qui ont amené Grype à ignorer cette correspondance de vulnérabilité.
Les correspondances ignorées ne sont pas prises en compte dans la décision de Grype sur le statut de sortie lors de l'utilisation --fail-on . Par exemple, si un utilisateur spécifie --fail-on critical et que toutes les correspondances de vulnérabilité trouvées avec une gravité « critique » ont été ignorées , Grype quittera zéro.
Remarque : Veuillez continuer à signaler tout faux positif que vous voyez ! Même si vous pouvez filtrer de manière fiable les faux positifs à l'aide de règles d'ignorance, il est très utile pour la communauté Grype si nous avons autant de connaissances que possible sur les faux positifs de Grype. Cela nous aide à améliorer continuellement Grype !
Afficher uniquement les vulnérabilités « corrigées »
Si vous souhaitez uniquement que Grype signale les vulnérabilités qui ont un correctif confirmé , vous pouvez utiliser l'indicateur --only-fixed . (Cela ajoute automatiquement des règles d'ignorance dans la configuration de Grype, de sorte que les vulnérabilités qui ne sont pas corrigées seront ignorées.)
Par exemple, voici un scan d'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
...et voici le même scan, mais en ajoutant le flag --only-fixed :
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical
Si vous souhaitez que Grype signale uniquement les vulnérabilités qui n'ont pas de correctif confirmé , vous pouvez utiliser l'indicateur --only-notfixed . Vous pouvez également utiliser l'indicateur --ignore-states pour filtrer les résultats des vulnérabilités avec des états spécifiques tels que wont-fix (voir --help pour une liste des états de correctifs valides). Ces indicateurs ajoutent automatiquement des règles d'ignorance dans la configuration de Grype, de sorte que les vulnérabilités qui sont corrigées ou ne le seront pas seront ignorées.
Prise en charge VEX
Grype peut utiliser les données VEX (Vulnerability Exploitability Exchange) pour filtrer les faux positifs ou fournir un contexte supplémentaire, augmentant ainsi les correspondances. Lors de la numérisation d'une image de conteneur, vous pouvez utiliser l'indicateur --vex pour pointer vers un ou plusieurs documents OpenVEX.
Les déclarations VEX associent un produit (une image de conteneur), une vulnérabilité et un statut VEX pour exprimer une affirmation de l'impact de la vulnérabilité. Il existe quatre statuts VEX : not_affected , affected , fixed et under_investigation .
Voici un exemple de document OpenVEX simple. (astuce : utilisez vexctl pour générer vos propres documents).
Par défaut, Grype utilisera toutes les instructions dans les documents VEX spécifiés avec un statut not_affectedfixed pour déplacer les correspondances vers l'ensemble ignoré.
Toutes les correspondances ignorées à la suite des instructions VEX sont signalées lors de l'utilisation --show-suppressed :
libcrypto3 3.0.8-r3 3.0.8-r4 apk CVE-2023-1255 Medium (suppressed by VEX)
Les instructions avec un statut affected ou under_investigation ne seront considérées comme augmentant l'ensemble de résultats que lorsque cela est spécifiquement demandé à l'aide de la variable d'environnement GRYPE_VEX_ADD ou dans un fichier de configuration.
VEX Ignorer les règles
Des règles d'ignorance peuvent être écrites pour contrôler la manière dont Grype honore les déclarations VEX. Par exemple, pour configurer Grype pour qu'il agisse uniquement sur les instructions VEX lorsque la justification est vulnerable_code_not_present , vous pouvez écrire une règle comme celle-ci :
Voir la liste des justifications pour plus de détails. Vous pouvez mélanger vex-status et vex-justification avec d'autres paramètres de règle d'ignorance.
Base de données de Grype
Lorsque Grype effectue une analyse des vulnérabilités, il le fait à l'aide d'une base de données de vulnérabilités stockée sur votre système de fichiers local, construite en extrayant des données de diverses sources de données de vulnérabilités accessibles au public. Ces sources comprennent :
Alpine Linux SecDB : https://secdb.alpinelinux.org/
Amazon Linux ALAS : https://alas.aws.amazon.com/AL2/alas.rss
Par défaut, Grype gère automatiquement cette base de données pour vous. Grype recherche de nouvelles mises à jour de la base de données de vulnérabilités pour s'assurer que chaque analyse utilise des informations de vulnérabilité à jour. Ce comportement est configurable. Pour plus d'informations, consultez la section Gestion de la base de données de Grype.
Comment fonctionnent les mises à jour de la base de données
La base de données de vulnérabilités de Grype est un fichier SQLite, nommé vulnerability.db . Les mises à jour de la base de données sont atomiques : l'intégralité de la base de données est remplacée puis traitée en « lecture seule » par Grype.
La première étape de Grype dans une mise à jour de base de données consiste à découvrir les bases de données disponibles pour la récupération. Grype fait cela en demandant un « fichier de liste » à un point de terminaison public :
Avec ces informations, Grype peut sélectionner la base de données correcte (la base de données la plus récemment construite avec la version actuelle du schéma), télécharger la base de données et vérifier l'intégrité de la base de données à l'aide de la valeur de somme checksum répertoriée.
Gestion de la base de données de Grype
Remarque : Lors d'une utilisation normale, les utilisateurs n'ont pas besoin de gérer la base de données de Grype ! Grype gère sa base de données en coulisses. Cependant, pour les utilisateurs qui ont besoin de plus de contrôle, Grype propose des options pour gérer la base de données de manière plus explicite.
Répertoire de cache de base de données locale
Par défaut, la base de données est mise en cache sur le système de fichiers local dans le répertoire $XDG_CACHE_HOME/grype/db// . Par exemple, sur macOS, la base de données serait stockée dans ~/Library/Caches/grype/db/3/ . (Pour plus d'informations sur les chemins XDG, reportez-vous à la spécification du répertoire de base XDG.)
Vous pouvez définir le chemin du répertoire de cache à l'aide de la variable d'environnement GRYPE_DB_CACHE_DIR . Si la définition de cette variable seule ne fonctionne pas, il faudra peut-être également définir la variable d'environnement TMPDIR .
Obsolescence des données
Grype a besoin d'informations de vulnérabilité à jour pour fournir des correspondances précises. Par défaut, l'exécution échouera si la base de données locale n'a pas été créée au cours des 5 derniers jours. La vérification de l'obsolescence des données est configurable via les variables d'environnement GRYPE_DB_MAX_ALLOWED_BUILT_AGE et GRYPE_DB_VALIDATE_AGE ou le champ max-allowed-built-age et validate-age , sous db . Il utilise la syntaxe de durée de Golang. Définissez GRYPE_DB_VALIDATE_AGE ou validate-age sur false pour désactiver la vérification d'obsolescence.
Environnements hors ligne et isolés
Par défaut, Grype recherche une nouvelle base de données à chaque exécution, en effectuant un appel réseau sur Internet. Vous pouvez dire à Grype de ne pas effectuer cette vérification en définissant la variable d'environnement GRYPE_DB_AUTO_UPDATE sur false .
Tant que vous placez les fichiers vulnerability.db et metadata.json de Grype dans le répertoire de cache pour la version de schéma attendue, Grype n'a pas besoin d'accéder au réseau. De plus, vous pouvez obtenir une liste des archives de base de données disponibles au téléchargement à partir de la commande grype db list dans un environnement en ligne, télécharger l'archive de base de données, la transférer vers votre environnement hors ligne et utiliser grype db import pour utiliser la base de données donnée en mode hors ligne.
Si vous souhaitez distribuer vos propres bases de données Grype en interne sans avoir besoin d'utiliser manuellement db import , vous pouvez tirer parti du mécanisme de mise à jour de base de données de Grype. Pour ce faire, vous pouvez créer votre propre fichier listing.json similaire à celui trouvé publiquement (voir grype db list -o raw pour un exemple de notre fichier listing.json public) et modifier l'URL de téléchargement pour pointer vers un point de terminaison interne (par exemple un bucket S3 privé, un serveur de fichiers interne, etc.). Toute installation interne de Grype peut recevoir automatiquement les mises à jour de la base de données en configurant le db.update-url (identique à la variable d'environnement GRYPE_DB_UPDATE_URL ) pour qu'il pointe vers le fichier listing.json hébergé que vous avez créé.
Commandes CLI pour la gestion de base de données
Grype fournit des commandes CLI spécifiques à la base de données pour les utilisateurs qui souhaitent contrôler la base de données à partir de la ligne de commande. Voici quelques-unes des commandes utiles fournies :
grype db status — indique l'état actuel de la base de données de Grype (comme son emplacement, sa date de construction et sa somme de contrôle)
grype db check - voir si des mises à jour sont disponibles pour la base de données
grype db update — assurez-vous que la dernière base de données a été téléchargée dans le répertoire de cache (Grype effectue cette opération au début de chaque analyse par défaut)
grype db list — téléchargez le fichier de liste configuré sur db.update-url et affichez les bases de données disponibles au téléchargement
grype db import — fournissez à grype une archive de base de données à utiliser explicitement (utile pour les mises à jour de base de données hors ligne)
grype db providers - fournit une liste détaillée des fournisseurs de bases de données
Trouvez des informations complètes sur les commandes de base de données de Grype en exécutant grype db --help .
Achèvement de la coque
Grype fournit la complétion du shell via son implémentation CLI (cobra). Générez le code de complétion pour votre shell en exécutant l'une des commandes suivantes :
grype completion
go run ./cmd/grype completion
Cela générera un script shell sur STDOUT, qui pourra ensuite être utilisé comme script de complétion pour Grype. L'exécution de l'une des commandes ci-dessus avec les indicateurs -h ou --help fournira des instructions sur la façon de procéder pour le shell de votre choix.
Authentification du registre privé
Informations d'identification Docker locales
Lorsqu'un environnement d'exécution de conteneur n'est pas présent, grype peut toujours utiliser les informations d'identification configurées dans des sources d'informations d'identification courantes (telles que ~/.docker/config.json ). Il extraira les images des registres privés en utilisant ces informations d'identification. Le fichier de configuration est l'endroit où vos informations d'identification sont stockées lors de l'authentification auprès de registres privés via une commande telle que docker login . Pour plus d’informations, consultez la documentation go-containerregistry .
Vous pouvez exécuter la commande suivante à titre d'exemple. Il détaille la configuration de montage/environnement dont un conteneur a besoin pour accéder à un registre privé :
docker run -v ./config.json:/config/config.json -e "DOCKER_CONFIG=/config" anchore/grype:latest
Informations d’identification Docker dans Kubernetes
La section ci-dessous montre un flux de travail simple sur la façon de monter ce fichier de configuration en tant que secret dans un conteneur sur Kubernetes.
Créez un secret. La valeur de config.json est importante. Il fait référence à la spécification détaillée ici. Sous cette section se trouve le fichier secret.yaml que la configuration du pod consommera en tant que volume. La clé config.json est importante. Ce sera finalement le nom du fichier une fois monté dans le pod.
Créez votre pod en cours d'exécution grype. L'environnement DOCKER_CONFIG est important car il indique où rechercher le fichier d'informations d'identification. Dans l'exemple ci-dessous, la définition de DOCKER_CONFIG=/config informe grype que les informations d'identification peuvent être trouvées dans /config/config.json . C'est pourquoi nous avons utilisé config.json comme clé de notre secret. Lorsqu'elle est montée dans des conteneurs, la clé secrète est utilisée comme nom de fichier. La section volumeMounts monte notre secret sur /config . La section volumes nomme notre volume et exploite le secret que nous avons créé à la première étape.
L'utilisateur peut désormais exécuter kubectl logs grype-private-registry-demo . Les journaux doivent montrer l'analyse grype pour le fourni dans la configuration du pod.
À l'aide des informations ci-dessus, les utilisateurs devraient pouvoir configurer l'accès au registre privé sans avoir à le faire dans les fichiers de configuration grype ou syft . Ils ne dépendront pas non plus d'un démon Docker (ou d'un autre logiciel d'exécution) pour la configuration et l'accès au registre.
Configuration
Chemins de recherche de configuration par défaut (voir tous avec grype config locations ) :
.grype.yaml
.grype/config.yaml
~/.grype.yaml
/grype/config.yaml
Utilisez grype config pour imprimer un exemple de fichier de configuration sur la sortie standard. Utilisez grype config --load pour imprimer la configuration actuelle après avoir chargé toutes les valeurs sur la sortie standard.
Vous pouvez spécifier des fichiers directement à l'aide des indicateurs --config / -c pour fournir vos propres fichiers/chemins de configuration :
grype -c /path/to/config.yaml
Options de configuration (les exemples de valeurs sont les valeurs par défaut) :
# activer/désactiver la vérification des mises à jour de l'application au démarrage# identique à GRYPE_CHECK_FOR_APP_UPDATE env varcheck-for-app-update : true# permet aux utilisateurs de spécifier quelle source d'image doit être utilisée pour générer le sbom# les valeurs valides sont : registre, docker, podman# identique à GRYPE_DEFAULT_IMAGE_PULL_SOURCE env vardefault-image-pull-source : ""# identique à --name ; définir le nom de la cible analyséename : ""# lors de l'analyse, si une gravité est trouvée égale ou supérieure à la gravité donnée, le code de retour sera 1# par défaut n'est pas défini, ce qui ignorera cette validation (options : négligeable, faible, moyenne , élevé, critique)# identique à --fail-on ; GRYPE_FAIL_ON_SEVERITY env varfail-on-severity : ""# le format de sortie du rapport de vulnérabilité (options : table, template, json, cyclonedx)# lorsque vous utilisez un modèle comme type de sortie, vous devez également fournir une valeur pour 'output-template- file'# identique à -o ; GRYPE_OUTPUT env varoutput : "table"# si vous utilisez la sortie du modèle, vous devez fournir un chemin vers un fichier modèle Go# voir https://github.com/anchore/grype#using-templates pour plus d'informations sur la sortie du modèle# le chemin par défaut dans le fichier modèle se trouve le répertoire de travail actuel# fichier-modèle-de-sortie : .grype/html.tmpl# écrit le rapport de sortie dans un fichier (la valeur par défaut est d'écrire sur la sortie standard)# identique à --file ; GRYPE_FILE env varfile : ""# une liste de globs à exclure de l'analyse, par exemple :# exclure:# - '/etc/**'# - './out/**/*.json'# identique à -- exclure ; GRYPE_EXCLUDE env varexclude : []# inclut les correspondances sur les packages d'en-têtes du noyau qui correspondent au package du noyau en amont# si 'false', ces correspondances sont marquées comme ignoréesmatch-upstream-kernel-headers : false# système d'exploitation et/ou architecture à utiliser quand référencement des images de conteneurs (par exemple "windows/armv6" ou "arm64")# identique à --platform ; GRYPE_PLATFORM env varplatform : ""# Si vous utilisez l'entrée SBOM, génère automatiquement des CPE lorsque les packages n'en ont aucunadd-cpes-if-none : false# Spécifiez explicitement une distribution Linux à utiliser comme : comme alpine:3.10distro:external -sources : activer : false maven : search-upstream-by-sha1 : true base-url : https://repo1.maven.org/maven2db : # vérifier les mises à jour de la base de données lors de l'exécution # identique à GRYPE_DB_AUTO_UPDATE env var auto-update : true # emplacement pour écrire le cache de la base de données de vulnérabilités ; par défaut, $XDG_CACHE_HOME/grype/db # identique à GRYPE_DB_CACHE_DIR env var cache-dir : "" # URL de la base de données de vulnérabilités # identique à GRYPE_DB_UPDATE_URL env var update-url : "https://toolbox-data.anchore.io/grype /databases/listing.json" # il garantit que la construction de la base de données n'est pas plus ancienne que l'âge maximum autorisé-construit # défini sur false pour désactiver la vérification validate-age: true # Âge maximum autorisé pour la base de données de vulnérabilité, # l'âge étant le temps écoulé depuis il a été construit # L'âge maximum par défaut est de 120 heures (ou cinq jours) max-allowed-built-age : "120h" # Délai d'expiration du téléchargement de GRYPE_DB_UPDATE_URL pour voir si la base de données doit être téléchargée # Ce fichier fait ~ 156 Ko à partir du 2024-04 -17 donc le téléchargement devrait être rapide ; ajustez si nécessaire update-available-timeout : "30s" # Délai d'expiration pour le téléchargement de la base de données de vulnérabilité réelle # La base de données fait environ 156 Mo au 17/04/2024, donc les connexions plus lentes peuvent dépasser le délai d'expiration par défaut ; ajuster si nécessaire update-download-timeout : "120s"search : # l'espace de recherche pour rechercher les packages (options : toutes les couches, écrasées) # identique à -s ; GRYPE_SEARCH_SCOPE env var scope : "squashed" # recherche dans les archives contenant un index de fichier sur lequel effectuer la recherche (zip) # remarque : pour l'instant, cela ne s'applique qu'au catalogueur de packages Java # identique à GRYPE_PACKAGE_SEARCH_INDEXED_ARCHIVES env var indexed-archives : true # search dans les archives qui ne contiennent pas d'index de fichier sur lequel effectuer la recherche (tar, tar.gz, tar.bz2, etc.) # remarque : l'activation de cette option peut entraîner un impact sur les performances puisque tous les fichiers tar compressés découverts seront décompressés # remarque : pour l'instant, ceci s'applique uniquement au catalogueur de packages Java # identique à GRYPE_PACKAGE_SEARCH_UNINDEXED_ARCHIVES env var unindexed-archives : false # options lors de l'extraction directe à partir d'un registre via le "registry :" Schemeregistry : # ignorer la vérification TLS lors de la communication avec le registre # identique à GRYPE_REGISTRY_INSECURE_SKIP_TLS_VERIFY env var non sécurisé -skip-tls-verify: false # utiliser http au lieu de https lors de la connexion au registre # identique à GRYPE_REGISTRY_INSECURE_USE_HTTP env var insecure-use-http: false # chemin de fichier vers un certificat CA (ou un répertoire contenant *.crt, *.cert, *.pem) utilisé pour générer le certificat client # GRYPE_REGISTRY_CA_CERT env var ca-cert: "" # les informations d'identification pour des registres spécifiques auth : # l'URL du registre (par exemple "docker.io", "localhost:5000", etc.) # Variable d'environnement GRYPE_REGISTRY_AUTH_AUTHORITY
- autorité : "" # GRYPE_REGISTRY_AUTH_USERNAME env var nom d'utilisateur : "" # GRYPE_REGISTRY_AUTH_PASSWORD env var mot de passe : "" # remarque : le jeton et le nom d'utilisateur/mot de passe s'excluent mutuellement # GRYPE_REGISTRY_AUTH_TOKEN env var token : "" # chemin de fichier vers le certificat client utilisé pour l'authentification TLS au registre # GRYPE_REGISTRY_AUTH_TLS_CERT env var tls-cert : "" # chemin de fichier vers la clé client utilisée pour l'authentification TLS dans le registre # GRYPE_REGISTRY_AUTH_TLS_KEY env var tls-key : "" # - ... # remarque, des informations d'identification supplémentaires peuvent être fournies via fichier de configuration uniquement (pas les variables d'environnement) journal : # supprime toutes les sorties (sauf la liste des vulnérabilités) # identique à -q ; GRYPE_LOG_QUIET env var quiet: false # augmente la verbosité # identique à GRYPE_LOG_VERBOSITY env var verbosity: 0 # le niveau de journalisation ; remarque : la journalisation détaillée supprime l'ETUI # identique à GRYPE_LOG_LEVEL env var # Utilise les niveaux de journalisation logrus : https://github.com/sirupsen/logrus#level-logging level : "error" # emplacement pour écrire le fichier journal (la valeur par défaut n'est pas pour avoir un fichier journal) # identique au fichier var d'env GRYPE_LOG_FILE : ""match : # définit les matchers ci-dessous pour qu'ils utilisent cpes lorsqu'ils essaient de trouver # des correspondances de vulnérabilité. Le correspondant de stock est le numéro par défaut lorsqu'aucun correspondant principal ne peut être identifié. java : using-cpes : false python : using-cpes : false javascript : using-cpes : false ruby : using-cpes : false dotnet : using-cpes : false golang : using-cpes : false # même si la correspondance CPE est désactivée, faites une exception lors de la recherche de "stdlib". always-use-cpe-for-stdlib: true # autoriser l'utilisation des pseudo-versions du module principal, qui n'ont peut-être été que "devinées" par Syft, dans la correspondance de vulnérabilités allow-main-module-pseudo-version-comparison: false stock : using-cpes : vrai
Projets futurs
Les domaines de développement potentiels suivants sont actuellement étudiés :
Prise en charge de la liste blanche et du mappage de packages
