Accepter des résultats dans le dépôt

Il existe deux façons d’accepter un résultat de scanner : dans le dépôt, avec un fichier d’exclusion Trivy qui accompagne le code, ou via l’API, en ignorant le résultat. Cette page traite de la première.

L’acceptation dans le dépôt convient mieux lorsqu’elle est une propriété du code : une bibliothèque vulnérable embarquée dans un outil que vous ne pouvez pas corriger, un conteneur qui s’exécute volontairement en root. La justification se trouve à côté de ce qu’elle décrit, et elle s’applique à chaque analyse dès sa fusion.

La règle qui piège tout le monde

Si votre dépôt contient .trivyignore.yaml, le fichier .trivyignore simple est entièrement ignoré.

Il n’est ni fusionné, ni consulté en repli : il est ignoré. Aucune de ses entrées ne supprime plus quoi que ce soit.

Cela tient au fait que nos scanners indiquent à Trivy le fichier structuré avec --ignorefile, et que cette option remplace la détection automatique du fichier simple par Trivy au lieu de s’y ajouter. C’est un comportement de Trivy, pas une politique de fremforge, et il passe facilement inaperçu, car un .trivyignore présent dans votre dépôt donne l’impression de servir à quelque chose.

Choisissez donc un seul fichier et n’utilisez que celui-là. Si vous avez besoin de quelque chose que la forme simple ne peut pas exprimer, déplacez toutes vos entrées vers le YAML en une seule fois.

Une acceptation s’applique une fois sur la branche de base

Une pull request est analysée avec les fichiers d’exclusion de la branche dans laquelle elle fusionne, et non avec les siens. Une PR qui introduit un résultat et l’accepte dans le même diff reste donc rouge : la nouvelle acceptation n’est lue qu’après sa fusion.

Pour accepter un résultat, faites d’abord fusionner l’acceptation seule, puis la modification qu’elle couvre. La PR qui ne contient que l’acceptation est analysée sans résultat, puisqu’à elle seule elle n’ajoute rien à trouver.

Cela vaut pour tous les fichiers que nos scanners liraient sinon depuis votre branche : .trivyignore, .trivyignore.yaml et trivy.yaml (Trivy), .semgrepignore (SAST), .gitleaksignore (détection de secrets) et osv-scanner.toml dans n’importe quel répertoire (analyse des dépendances).

Les modifications qui ne peuvent que rendre une analyse plus stricte s’appliquent, elles, dans la PR même :

• la suppression d’un fichier d’exclusion ;
• le retrait d’entrées de .trivyignore ou de .gitleaksignore. La PR est analysée avec les entrées de la branche de base, moins celles qu’elle a retirées. Repousser la date exp: d’une entrée compte comme une nouvelle entrée, et ne s’applique donc qu’après la fusion.

Toute autre modification d’un fichier d’exclusion, comme restreindre un .trivyignore.yaml ou un .semgrepignore, s’applique après la fusion. D’ici là, la PR est analysée avec la version de la branche de base.

Les réanalyses planifiées de votre branche par défaut utilisent toujours les fichiers d’exclusion présents sur cette branche.

Quelle forme choisir

Les deux formes acceptent les mêmes identifiants : identifiants CVE, identifiants GHSA et identifiants de mauvaise configuration comme DS-0002. La différence porte sur ce que vous pouvez dire à propos d’une entrée.

Utilisez la forme simple pour une liste courte. Utilisez le YAML lorsque vous devez limiter une acceptation à un chemin embarqué précis, ou lorsque vous voulez que la justification soit portée par des données plutôt que par un commentaire.

Forme simple

# grpc is statically linked into the pulumi binary and only speaks over
# localhost, so this server-side advisory is not reachable in CLI use.
GHSA-hrxh-6v49-42gf exp:2026-08-30

Forme structurée

vulnerabilities:
  - id: GHSA-hrxh-6v49-42gf
    expired_at: 2026-08-30
    paths:
      - usr/local/bin/pulumi
    statement: >-
      grpc is statically linked into the pulumi binary as its engine<->plugin
      transport and only speaks over localhost, so this server-side advisory is
      not reachable in CLI use. Fixed in grpc 1.82.1; drop this when pulumi
      ships it.

misconfigurations:
  - id: DS-0002
    expired_at: 2027-01-23
    statement: >-
      CI runner base image; it must run as root to drive the container runtime.

Les sections de premier niveau sont vulnerabilities, misconfigurations, secrets et licenses.

Fixez toujours une expiration

Une acceptation écrite sans date devient permanente par accident. La bibliothèque embarquée est corrigée, le fichier vulnérable quitte l’image, et l’entrée reste, supprimant tout ce qui partagera plus tard son identifiant.

Les deux formes prennent en charge l’expiration, et c’est Trivy lui-même qui l’applique : une fois la date passée, le résultat revient. « Il faudra revérifier ça un jour » devient ainsi un jour précis où la barrière vous pose la question.

Choisissez une date à laquelle vous revérifierez réellement : la prochaine version de l’outil en amont, ou dans trois mois.

Quand ignorer plutôt via l’API

Préférez ignorer le résultat plutôt qu’un fichier d’exclusion lorsque :

• le résultat est périmé : vous l’avez déjà corrigé à la source et voulez simplement faire disparaître la ligne. En général, ce n’est même pas nécessaire : la résolution automatique horaire s’en charge dès qu’une analyse plus récente s’exécute ;
• l’acceptation concerne la situation actuelle de ce dépôt, pas le code : par exemple, un résultat sur une branche qui a depuis été fusionnée ;
• vous voulez que le motif figure dans le journal d’audit. Les décisions d’ignorer sont enregistrées avec leur auteur et leur motif ; un fichier d’exclusion est enregistré dans l’historique Git.

Un fichier d’exclusion est le choix durable ; ignorer un résultat est le choix ponctuel.

Vérifier que cela fonctionne

Relancez l’analyse et vérifiez que le résultat a disparu : voir Relancer les analyses. Si l’entrée semble sans effet, vérifiez d’abord la règle en haut de cette page : un .trivyignore.yaml à la racine du dépôt désactive entièrement le fichier simple.

Voir aussi

• API des résultats : lire et ignorer des résultats via REST.
• Analyse des images : ce qui bloque une fusion, et le seuil de gravité.
• Analyse des licences : catégories de politique et liste d’autorisation.