Utilisation de trivy pour scanner des images de conteneurs

Ce sont des exemples simples de scans d'images sur le hub Docker. On utilise le rapport de type junit qui permet d'avoir les résultats du scan affichés dans le pipeline.

La syntaxe est :

aJob:
  stage: aStage
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - |
      trivy --quiet image --exit-code 0 --no-progress --format template --template "@/contrib/junit.tpl" URI_IMAGE_DOCKER_HUB > junit-report.xml
  artifacts:
    reports:
      junit: junit-report.xml

URI_IMAGE_DOCKER_HUB prend une valeur comme debian:latest.

Pour scanner des images stockées dans le registre de GitLab-forge, la syntaxe est légèrement moins simple :

aJob:
  stage: aStage
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  before_script:
    - |
      export TRIVY_AUTH_URL=$CI_REGISTRY
      export TRIVY_USERNAME=$CI_REGISTRY_USER
      export TRIVY_PASSWORD=$CI_REGISTRY_PASSWORD
  script:
    - |
      trivy --quiet image --exit-code 0 --no-progress --format template --template "@/contrib/junit.tpl" URI_IMAGE_GITLABFORGE > junit-report.xml
  after_script:
    - |
      unset TRIVY_AUTH_URL
      unset TRIVY_USERNAME
      unset TRIVY_PASSWORD
  artifacts:
    reports:
      junit: junit-report.xml

URI_IMAGE_GITLABFORGE prend une valeur comme registry.gitlab-forge.din.developpement-durable.gouv.fr/share/devops/docker/mkdocs-material-plusplus/mkdocs-material-plusplus:7.3.6.

Les résultats de scans dépendent des images de base qui elles-mêmes sont mises à jour par les développeurs !

Il faut donc :

1. scanner les images construites par CI/CD pour connaître leurs vulnérabilités ;
2. reconstruire ces images car les images de base peuvent avoir corriger certaines (ou toutes) les vulnérabilités ;
3. Aller en 1. 😁

La fréquence de reconstruction des images dépend de l'activité du produit (mais au moins une fois par an si le produit est "inactif"), sinon il faut surveiller les alertes !