Scan de sécurité des images Docker / OCI de registre : vulnérabilités avec Grype.
Utilisation et spécificités
Fournissez l’image à analyser et une cible Docker ou Podman disponible. failOn définit le seuil qui fait échouer le nœud. Trivy accepte aussi target=repository avec un workspace de checkout et un chemin relatif, pour analyser avant le build. Les scanners et leurs bases doivent être accessibles ; les valeurs de secrets détectées sont masquées.
Type technique : grype. Runtime : docker.
Identifiants et prérequis
Aucun identifiant externe dédié n’est défini par ce nœud. Les sources distantes ou la cible d’exécution peuvent néanmoins nécessiter leurs propres accès.
Consultez le guide des identifiants si une source distante ou une cible d’exécution nécessite un accès.
Paramètres
Les noms ci-dessous correspondent aux clés techniques. Les valeurs par défaut ne constituent pas une configuration prête à exécuter : renseignez les champs requis par votre opération. Les chemins contenant [] décrivent les éléments d’une liste ; certains champs dépendent du mode sélectionné.
Paramètre
Type
Par défaut
Valeurs / limites
image
string
""
-; max 2000
scannerImage
string
""
-; max 512
platform
string
""
-
ignoreUnfixed
boolean
false
-
failOn
enum
"none"
none, low, medium, high, critical
timeoutMs
number
600000
-; ≥ 10000, ≤ 1800000
Aide de configuration
image Image à analyser
Référence d’une image publiée dans un registre. Les expressions et les sorties du nœud de construction sont acceptées. Publiez les images locales avant le scan. Pour un registre privé, placez un nœud Connexion Docker / Podman avant ce scan. Ses identifiants restent limités à cette exécution.
failOn Bloquer le workflow à partir de
Le seuil inclut les gravités supérieures. Rapport seul conserve toutes les vulnérabilités en sortie. Un seuil atteint met le nœud en échec avec un résumé dans les journaux ; le rapport complet n’est alors pas une sortie réussie. Les gravités inconnues ne déclenchent pas le seuil.
ignoreUnfixed Afficher uniquement les vulnérabilités corrigibles
Ignore les vulnérabilités sans version corrigée disponible, y compris pour le seuil de blocage. Les contrôles de configuration et de secrets restent actifs.
platform Plateforme cible
Facultatif : architecture de l’image à analyser, par exemple linux/amd64 ou linux/arm64. Sans valeur, le scanner choisit sa plateforme par défaut.
timeoutMs Durée maximale (secondes)
De 10 à 1 800 secondes. Inclut le téléchargement du scanner, de l’image et des bases de vulnérabilités.
scannerImage Image du scanner
Facultatif : remplace l’image officielle proposée. Fixez une version ou un digest pour rendre les scans reproductibles. Utilisez une image de confiance : elle accède au code en mode dépôt ou aux identifiants de registre en mode image. Nécessite Docker ou Podman sur l’hôte. Les cibles Kubernetes et SSH ne sont pas prises en charge. Le mode dépôt analyse le dossier du checkout monté en lecture seule, sans identifiants de registre ni socket du moteur. Docker Scout nécessite un compte Docker Hub autorisé. Ajoutez une connexion Docker / Podman à docker.io avant ce nœud, en plus de la connexion au registre privé si nécessaire.
Configuration initiale
Exemple de configuration initiale du catalogue, à adapter avant exécution. Les secrets doivent rester dans les identifiants.
Testez le nœud avec des données représentatives. Contrôlez sa sortie dans l’inspecteur et les logs, puis utilisez le mapping de l’éditeur pour les champs des nœuds suivants. Un test de déclencheur avec payload simulé ne valide pas la livraison du service externe.
Scan de sécurité des images Docker / OCI de registre : vulnérabilités avec Grype.
Utilisation et spécificités
Fournissez l’image à analyser et une cible Docker ou Podman disponible. failOn définit le seuil qui fait échouer le nœud. Trivy accepte aussi target=repository avec un workspace de checkout et un chemin relatif, pour analyser avant le build. Les scanners et leurs bases doivent être accessibles ; les valeurs de secrets détectées sont masquées.
Type technique :
grype. Runtime :docker.Identifiants et prérequis
Aucun identifiant externe dédié n’est défini par ce nœud. Les sources distantes ou la cible d’exécution peuvent néanmoins nécessiter leurs propres accès.
Consultez le guide des identifiants si une source distante ou une cible d’exécution nécessite un accès.
Paramètres
Les noms ci-dessous correspondent aux clés techniques. Les valeurs par défaut ne constituent pas une configuration prête à exécuter : renseignez les champs requis par votre opération. Les chemins contenant [] décrivent les éléments d’une liste ; certains champs dépendent du mode sélectionné.
imagestring""scannerImagestring""platformstring""ignoreUnfixedbooleanfalsefailOnenum"none"none,low,medium,high,criticaltimeoutMsnumber600000Aide de configuration
imageImage à analyser
failOnBloquer le workflow à partir de
ignoreUnfixedAfficher uniquement les vulnérabilités corrigibles
platformPlateforme cible
timeoutMsDurée maximale (secondes)
scannerImageImage du scanner
Configuration initiale
Exemple de configuration initiale du catalogue, à adapter avant exécution. Les secrets doivent rester dans les identifiants.
{ "image": "", "scannerImage": "", "platform": "", "ignoreUnfixed": false, "failOn": "none", "timeoutMs": 600000 }Vérification
Testez le nœud avec des données représentatives. Contrôlez sa sortie dans l’inspecteur et les logs, puis utilisez le mapping de l’éditeur pour les champs des nœuds suivants. Un test de déclencheur avec payload simulé ne valide pas la livraison du service externe.
Voir aussi : Expressions et données, Exécutions, Catalogue des nœuds.