Table of Contents

Introduction : Pourquoi le balayage d'image de conteneur appartient à votre pipeline

La conteneurisation a transformé le développement logiciel par des applications d'emballage avec leurs dépendances en environnements légers et portables. Des ordinateurs portables de développement local aux grappes de Kubernetes, les conteneurs fournissent la cohérence qui élimine le problème "il fonctionne sur ma machine". Cependant, les mêmes caractéristiques qui rendent les conteneurs puissants introduisent également des risques de sécurité uniques.

Les organisations qui traitent la sécurité des conteneurs comme une pensée après-vente se retrouvent souvent en train de brouiller pour patcher les écosystèmes de production lorsqu'une vulnérabilité et une exposition communes critiques (CVE) sont divulguées. Une approche beaucoup plus efficace est de de gauche de la sécurité de changement—intégrer la numérisation d'image des conteneurs directement dans le flux de travail de développement de sorte que les vulnérabilités sont capturées avant que les images n'atteignent jamais un registre.

Comprendre le balayage d'image du conteneur

Le balayage d'image de conteneur est le processus automatisé d'inspection des couches d'image de conteneur pour identifier les vulnérabilités connues en matière de sécurité, les paquets logiciels périmés, les erreurs de configuration et les violations de conformité. Les scanners comparent le contenu d'une image, y compris le système d'exploitation de base, les dépendances d'application et toutes les bibliothèques installées, contre les bases de données de vulnérabilité curées telles que la base de données nationale sur la vulnérabilité (NVD), les flux OSV ou les flux propres aux fournisseurs.

Types de numérisation: statiques ou dynamiques

La plupart des scanners d'images de conteneurs fonctionnent de façon statique. Ils analysent l'image sans l'exécuter, ce qui permet de réaliser des analyses rapides qui peuvent être intégrées à chaque construction. La numérisation statique examine le système de fichiers et les manifestes de paquets (comme , , , , ou ) pour identifier les logiciels présentant des vulnérabilités connues. Certains outils avancés inspectent également la configuration de l'image pour les mots de passe, les clés API ou les permissions de fichiers excessivement permissives. La numérisation dynamique, par contre, nécessite l'exécution du conteneur dans un environnement sablé et l'observation de son comportement d'exécution – ce qui est moins courant dans les pipelines CI/CD en raison des frais généraux et de la complexité, mais elle peut révéler des problèmes que la numérisation statique manque, tels que les ports exposés ou les variables d'environnement mal configurées.

Ce que les scanners recherchent

  • Silences connues (CVE) dans les paquets de systèmes d'exploitation, les durées d'exécution de la langue et les dépendances des applications.
  • Un logiciel périmé ou déprécié qui ne peut plus recevoir de correctifs de sécurité.
  • Misconfigurations[ telles que l'exécution de la racine, les contrôles de santé manquants ou les secrets exposés.
  • Violations de conformité[ à l'encontre de normes comme PCI DSS, HIPAA ou SOC 2 qui nécessitent un durcissement d'image spécifique.
  • Malware ou binaires inattendus dans les images de base tirées des registres publics.

Le rôle de la sélection de base de l'image

Le choix d'une image de base officielle et minimale à partir d'une source fiable (par exemple, Linux alpin, images distroles ou versions durcies d'Ubuntu) réduit considérablement la surface d'attaque. Les scanners peuvent comparer votre image de base au dernier digest et vous alerter lorsqu'une version plus récente et corrigée est disponible. Sans scanner, les équipes pourraient sans le savoir continuer à utiliser une image qui contient une vulnérabilité critique qui a été corrigée il y a des mois.

Avantages de l'intégration de la numérisation au développement

Le passage d'une analyse d'image de conteneur d'une vérification après déploiement à une étape courante du processus de développement procure des avantages concrets qui se multiplient au fil du temps.

Détection précoce des vulnérabilités

La prise en charge du même problème dans la production nécessite un retour en arrière d'urgence, une intervention incidente et souvent un nouveau pipeline de déploiement. La détection précoce réduit le temps moyen pour remédier (MTTR) et empêche les images vulnérables d'atteindre des environnements de mise en scène ou de production.

Contrôles de sécurité automatisés sans goulots d'étranglement

Les équipes de sécurité sont souvent sous-effectifs et ne peuvent pas examiner manuellement chaque image de conteneur produite par votre organisation. En automatisant le balayage dans le pipeline CI/CD, vous imposez des contrôles cohérents pour chaque construction, qu'il s'agisse d'une branche expérimentale du développeur ou d'un candidat à la libération.

Conformité réglementaire et préparation à la vérification

De nombreux cadres de conformité exigent maintenant des preuves que les images de conteneurs sont numérisées pour détecter les vulnérabilités avant le déploiement. La numérisation automatisée génère une piste de vérification, chaque image ayant un rapport qui peut être stocké à côté de l'artefact. Cela rend simple de prouver la diligence raisonnable au cours des vérifications.

Économies réalisées grâce à la sécurité des postes postés

Une fois cette image déployée sur des dizaines ou des centaines de nœuds, le coût augmente : il faut coordonner le patching, gérer les redémarrages de roulement et gérer les incidents potentiels auxquels le client est confronté. La numérisation d'image du conteneur réduit la probabilité de corrections d'urgence coûteuses et les dommages de réputation qui accompagnent une rupture. Selon les recherches de l'industrie, le coût de la fixation d'une vulnérabilité dans la production est 30 à 100 fois plus élevé que celui de la fixer pendant le développement.

Mise en oeuvre de la numérisation d'image du contenant dans le pipeline CI/CD

L'intégration de la numérisation d'image de conteneur dans votre flux de développement nécessite de sélectionner les bons outils, d'automatiser l'étape de l'analyse, de définir les politiques et de s'assurer que les développeurs peuvent agir sans friction sur les résultats.

Étape 1: Choisissez un outil de numérisation qui convient à votre pile

L'écosystème de numérisation de conteneurs offre des options commerciales et open source. Les principaux facteurs à évaluer incluent le soutien de l'écosystème de langue (Node.js, Python, Java, Go, etc.), la fréquence de mise à jour de la base de données, les capacités d'intégration avec votre outil IC/CD existant, et la capacité de faire appliquer des décisions politiques au-delà d'un simple passage/échec.

  • Trivy (Aqua Security) : Open-source, rapide, prend en charge plusieurs langues et paquets OS, et s'intègre facilement dans les actions GitHub, GitLab CI, Jenkins, ou tout pipeline basé sur Docker. Trivy est largement adopté pour sa simplicité et sa précision.
  • Clair (Red Hat): Un scanner open-source plus ancien mais stable, souvent utilisé avec les registres CoreOS et Quay. Il nécessite une configuration de base de données et est moins simple dans les coureurs d'IC éphémères.
  • Snyk (Snyk Ltd.): Une plateforme commerciale qui fournit une analyse de dépendance profonde et une surveillance continue. Elle s'intègre profondément avec GitHub et GitLab et offre une interface utilisateur conviviale pour les développeurs.
  • Docker Scout: outil de numérisation intégré de Docker, gratuit pour les utilisateurs de Docker Desktop et intégré dans Docker Hub. Il fournit une gouvernance basée sur les politiques et des recommandations pour les mises à jour d'images de base.
  • Anchore Engine: Un scanner open-source qui peut être déployé comme un service autonome. Il prend en charge les politiques personnalisées et se nourrit dans les flux de travail de conformité de l'entreprise.

Exemple d'intégration avec Trivy dans GitHub Actions: Ajoutez une étape après avoir construit votre image Docker qui tourne . Si Trivy trouve des vulnérabilités critiques ou de haute gravité, la compilation échoue, empêchant l'image d'être poussée dans le registre. Pour un contrôle plus granulaire, vous pouvez écrire les résultats dans un fichier JSON et utiliser des moteurs de politique comme OPA (Open Policy Agent) pour prendre des décisions de gouvernance.

Étape 2 : Automatisez le balayage dans votre pipeline CI/CD

Placez l'étape de numérisation après la construction de l'image, mais avant qu'elle ne soit poussée vers le registre. Cela garantit que seules les images qui passent les contrôles de sécurité entrent dans vos zones de stockage et de déploiement.

# Pseudocode for a typical CI/CD workflow
1. Checkout source code
2. Install dependencies and application code
3. Build container image using Dockerfile
4. Run container image scan with severity threshold
 If FAIL: Notify developer, stop pipeline
 If PASS: Continue to step 5
5. Push image to registry (with scan report metadata)
6. Deploy to staging environment
7. (Optional) Re-scan after deployment for runtime checks

Pour GitLab CI, un extrait de configuration typique dans pourrait ressembler à :

container_scan:
 stage: security
 image: docker:20.10.16
 services:
 - docker:20.10.16-dind
 before_script:
 - apk add --no-cache curl
 - curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/scripts/get_helm.sh | sh
 script:
 - trivy image --exit-code 0 --severity LOW,MEDIUM --ignore-unfixed your-image:$CI_COMMIT_SHA
 - trivy image --exit-code 1 --severity CRITICAL,HIGH --ignore-unfixed your-image:$CI_COMMIT_SHA

Notez l'utilisation de deux passes : la première passe ne signale que des problèmes faibles et moyens (code de sortie 0 donc le pipeline continue), tandis que la seconde passe échoue sur le pipeline sur des problèmes critiques et élevés. Cela permet aux développeurs de voir des avertissements non-bloquants tout en appliquant une politique stricte sur les vulnérabilités graves.

Étape 3 : Examen et loi sur les résultats

Pour rendre les résultats exploitables, configurez votre outil pour produire un rapport structuré (JSON ou SARIF) et l'intégrer à votre tableau de bord développeur ou aux commentaires de requêtes de tirage. Par exemple, GitHub Actions peut ajouter un commentaire à la liste des vulnérabilités trouvées, ainsi que des corrections suggérées. Les équipes devraient trier régulièrement les constatations, en vérifiant que les faux positifs (tels que les vulnérabilités dans les paquets qui ne peuvent pas être exploités dans le contexte du conteneur) sont filtrés en mettant à jour la configuration d'exclusion du scanner.

Étape 4 : Établir et appliquer des politiques de sécurité

Définir ce que signifie «pass» pour votre organisation. Les politiques communes comprennent :

  • Aucune vulnérabilité critique ou de haute gravité qui ont une correction connue (ignore-non fixée).
  • Les images de base doivent avoir moins de 30 jours, ou la construction doit utiliser une base durcie spécifique.
  • L'utilisateur non root doit être déclaré dans le fichier Dockerfile ().
  • Aucun secret exposé ou identifiant codé en dur dans aucune couche.

En cas de violation, le pipeline devrait bloquer la poussée et en aviser le promoteur ou l'équipe responsable. Pour les avertissements de faible gravité, vous pouvez permettre au pipeline de réussir, mais enregistrer les résultats et exiger des mesures correctives dans un nombre défini de jours.

Meilleures pratiques pour un balayage efficace de l'image du conteneur

La numérisation à elle seule ne suffit pas – la façon dont vous implémentez et maintenez le processus détermine son efficacité.

Scanner tôt et souvent

Ne limitez pas la numérisation à la version finale de la version. Intégrez une numérisation légère dans chaque commit qui construit une image de conteneur. Cela inclut les branches de développement, les branches de fonctionnalités et les fusions de requêtes. Plus tôt vous trouvez une dépendance vulnérable, moins de changement de contexte nécessaire pour la corriger. Pour les images de base, envisagez de les scanner chaque fois que le registre en amont publie une mise à jour—de nombreux outils prennent en charge un webhook ou un scan programmé pour les images stockées dans un registre.

Gardez à jour vos outils et bases de données de numérisation

Les bases de données de vulnérabilité sont mises à jour quotidiennement, parfois à l'heure. Un scanner utilisant des bases de données en panne manquera les derniers CVE. Configurez votre pipeline pour extraire la dernière base de données de vulnérabilité avant chaque balayage. Pour Trivy, utilisez ou comptez sur la fonction de mise à jour automatique du scanner.

Utiliser des images de base minimales et des constructions multi-étages

Utilisez des images de base distrol ou alpines pour la production. Utilisez des fichiers Docker pour séparer les dépendances de temps de construction (p. ex., compilateurs, cadres de test) des artefacts d'exécution. Par exemple, construisez votre application dans une image de nœud ou de go pleine caractéristique, puis copiez seulement le binaire compilé dans une image de rayures ou de distrol. Cela réduit considérablement la surface de vulnérabilité.

# Example multi-stage build
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o main

FROM gcr.io/distroless/base-debian12
COPY --from=builder /app/main /main
CMD ["/main"]

Scanners ne va inspecter que l'image finale, qui contient des paquets minimaux et donc moins de résultats.

Privilégier les Fixes en fonction de l'Exploitabilité

Toutes les vulnérabilités ne sont pas aussi dangereuses. Prioriser les corrections en fonction de l'utilisation réelle du paquet vulnérable au moment de l'exécution, de l'exploitation connue et de la racine de l'image. De nombreux scanners supportent maintenant l'analyse de la accessibilité – ils peuvent déterminer si la fonction vulnérable est importée ou appelée dans le code d'application.

Éduquer les développeurs sur les pratiques sécuritaires en matière de conteneurs

L'automatisation est puissante, mais elle ne peut remplacer la compréhension. Fournir de la documentation et de la formation sur la raison pour laquelle le balayage des conteneurs est appliqué, comment interpréter les résultats de l'analyse et comment résoudre les problèmes communs. Encourager les développeurs à utiliser des outils comme localement avant de pousser les commits.

Défis et considérations

Bien que les avantages de la numérisation des conteneurs soient clairs, la mise en œuvre n'est pas sans ses obstacles. Être conscient des défis communs vous aide à concevoir une stratégie de numérisation plus résistante.

Faux positifs et bruit

Par exemple, une image de Node.js peut contenir une version vulnérable d'une bibliothèque qui n'est utilisée que pendant les tests. Au fil du temps, les équipes peuvent devenir désensibilisées au bruit et commencer à ignorer les résultats de l'analyse. Mitigatez ceci en configurant le scanner pour ignorer les vulnérabilités non fixées (ceux sans version corrigée) lorsque le risque est acceptable, ou en utilisant un moteur de politique qui filtre en fonction de la accessibilité.

Impact sur les performances dans les temps de construction

Pour réduire l'impact, utilisez la numérisation progressive — de nombreux outils cachent les résultats de la numérisation précédente et analysent seulement les couches modifiées. Pensez également à lancer un balayage rapide pour la gravité critique seulement pendant les constructions de développement et un balayage complet sur les constructions de la publication. Au fil du temps, lorsque les images de base se stabilisent, les temps de numérisation ont tendance à baisser.

Traitement des secrets et des données sensibles

Les secrets qui finissent par être placés en couches de conteneurs présentent un risque de sécurité que les outils de numérisation détectent souvent. Cependant, si un secret est incorporé dans une image, il faut le supprimer et invalider toutes les couches mises en cache. Empêcher les secrets de pénétrer les images en utilisant des arguments de construction, des supports secrets (Docker BuildKit), ou des magasins secrets externes comme HashiCorp Vault.

Conformité aux normes réglementaires multiples

Les organisations soumises à PCI DSS, HIPAA ou FedRAMP doivent prouver que leurs images de conteneurs répondent à des exigences spécifiques de durcissement. Cela va souvent au-delà de la numérisation CVE – il comprend des vérifications des autorisations des utilisateurs, des étiquettes de système de fichiers et des configurations réseau. Utilisez un moteur de politique qui peut évaluer les règles de conformité personnalisées aux côtés des données de vulnérabilité.

Conclusion

En choisissant l'outil de numérisation approprié, en automatisant les balayages dans votre pipeline CI/CD, en établissant des barrières claires et en favorisant une culture de sensibilisation à la sécurité, vous pouvez réduire considérablement le risque de déployer des conteneurs vulnérables. L'investissement initial dans la configuration des pipelines et l'éducation des développeurs rapporte des dividendes en prévenant les incidents coûteux, en simplifiant les audits de conformité et en permettant aux équipes de se déplacer rapidement en toute confiance.

Commencez par une intégration minimale – ajoutez une étape Trivy à l'un de vos pipelines de construction, fixez un seuil de gravité critique et examinez les résultats avec votre équipe. Iterate de là, en étendant à inclure la numérisation d'image de base, la surveillance des registres et les politiques d'exécution. La sécurité est un voyage, et la numérisation d'image de conteneur est l'une des étapes les plus efficaces que vous pouvez ajouter à ce voyage aujourd'hui.

Ressources externes pour la lecture suivante :