Chaîne d’approvisionnement des images de conteneurs

Les images de conteneurs ne sont pas un simple emballage du code applicatif : ce sont des artefacts logiciels complets qui comprennent le code de l’application, ses dépendances d’exécution, les bibliothèques système, les utilitaires du système d’exploitation et toute la pile logicielle de l’image de base. Lorsqu’un fournisseur livre un logiciel sous forme d’image de conteneur, l’évaluation de la sécurité doit s’étendre à chaque couche de cette image : la couche du code applicatif, les couches de dépendances ajoutées lors de la compilation et la couche de l’image de base qui en constitue le socle. Les vulnérabilités des bibliothèques système de l’image de base sont des vulnérabilités du logiciel livré, quelle que soit la propreté de la couche du code applicatif.

L’obsolescence des images de base est la défaillance la plus courante de la chaîne d’approvisionnement des conteneurs. Les images de base, c’est-à-dire les couches de fondation à partir desquelles les images de conteneurs applicatives sont construites, contiennent des paquets et des bibliothèques du système d’exploitation qui accumulent des vulnérabilités au fil du temps. Un fournisseur qui construit son application sur une image de base sans la mettre à jour régulièrement augmente progressivement le nombre de vulnérabilités de ses conteneurs livrés. L’image de base python:3.9-slim d’il y a quatre mois n’a pas le même profil de vulnérabilités que le même tag construit aujourd’hui, car les publications de vulnérabilités s’accumulent et l’image de base intègre les mises à jour des paquets du système d’exploitation lorsqu’elle est reconstruite, mais seulement si elle est reconstruite.

Le malentendu sur l’immuabilité des tags d’image est le problème de configuration précis. Les tags d’images de conteneurs, comme python:3.9-slim ou ubuntu:22.04, semblent désigner des versions stables, mais ce sont en réalité des pointeurs modifiables que le mainteneur de l’image de base peut mettre à jour. Une image construite aujourd’hui sur python:3.9-slim peut avoir une composition logicielle différente d’une image construite demain sur python:3.9-slim si le mainteneur de l’image de base publie une mise à jour de ce tag. Les fournisseurs qui construisent leurs images sur des tags modifiables et ne les reconstruisent pas fréquemment peuvent avoir des images aux couches de base obsolètes, même s’ils entendent utiliser des images à jour.

Pourquoi c’est important

Le risque lié à la chaîne d’approvisionnement des images de conteneurs compte pour la TPRM, car les logiciels livrés sous forme de conteneurs comprennent toute la pile logicielle du fournisseur, y compris les bibliothèques système et les composants du système d’exploitation, et pas seulement le code applicatif. Un fournisseur qui a beaucoup investi dans la sécurité du code applicatif tout en négligeant l’actualité de ses images de base peut livrer des logiciels présentant des vulnérabilités système critiques qui échappent à toute l’assurance en matière de sécurité applicative recueillie par l’entreprise.

Sécurité applicative évaluée sans évaluation des images de conteneurs
Âge et statut de vulnérabilité de l’image de base non évalués
Vulnérabilités des bibliothèques système des conteneurs hors du périmètre de l’SCA standard
Fréquence de reconstruction des images non évaluée en plus des correctifs applicatifs
SBOM du conteneur non demandé en plus du SBOM de l’application

À quoi ressemblent les bonnes pratiques

Les programmes matures de sécurité de la chaîne d’approvisionnement des conteneurs évaluent le profil de vulnérabilité complet des images, y compris les couches de l’image de base, au moyen d’outils d’analyse propres aux conteneurs, demandent les SBOM des conteneurs en plus des SBOM des applications, exigent des reconstructions régulières des images de base pour intégrer les mises à jour des paquets du système d’exploitation et suivent l’âge des images de conteneurs comme indicateur de sécurité.

Analyse des vulnérabilités des images de conteneurs : évaluation de toutes les couches, y compris l’image de base
SBOM du conteneur, y compris les bibliothèques système et les composants de l’image de base
Fréquence de reconstruction de l’image de base : à quelle fréquence les images sont reconstruites à partir d’une image de base à jour
Suivi de l’âge des images : ancienneté de l’image de conteneur en service par rapport à la dernière reconstruction
Images de base distroless ou minimales réduisant la surface d’attaque liée aux bibliothèques système

Outils

Analyse des conteneurs : Trivy, Grype, analyse AWS ECR, Google Container Analysis pour l’analyse des images de conteneurs sur toutes les couches

Les outils d’analyse propres aux conteneurs évaluent l’ensemble des couches de l’image, y compris les bibliothèques système de l’image de base, et non uniquement les dépendances applicatives couvertes par les outils SCA standard. Trivy et Grype prennent tous deux en charge l’analyse des images de conteneurs avec une analyse complète des couches. Pour les professionnels TPRM, demander si les fournisseurs analysent leurs images de conteneurs avec des outils couvrant toutes les couches (et non uniquement avec une SCA de la couche applicative) permet de poser une question précise sur la sécurité des conteneurs.

Image de base : Google Distroless, Chainguard Images pour des images de base à surface d’attaque minimale

Les images de base distroless et minimales, qui ne contiennent que l’environnement d’exécution de l’application et rien d’autre, réduisent sensiblement la surface d’attaque liée aux bibliothèques système par rapport aux images de base généralistes. Pour les professionnels TPRM, demander si les fournisseurs utilisent des images de base distroless ou minimales permet de poser une question précise de réduction de la surface d’attaque, qui répond au problème d’accumulation des vulnérabilités dans les images de base.

Enjeux de gouvernance

Pour la chaîne d’approvisionnement des images de conteneurs, l’enjeu de gouvernance tient à la discipline de reconstruction. Reconstruire régulièrement les images de conteneurs pour intégrer les mises à jour de l’image de base exige une discipline opérationnelle qui entre en concurrence avec la stabilité des déploiements. Les fournisseurs peuvent rechigner à reconstruire fréquemment, car chaque reconstruction comporte un risque de régression. La réponse en matière de gouvernance consiste à mettre en place des pipelines de reconstruction automatisés déclenchés par les mises à jour de l’image de base, associés à des tests de non-régression qui rendent les reconstructions fréquentes soutenables sur le plan opérationnel.

Demander les résultats d’analyse des vulnérabilités des images de conteneurs en plus de l’SCA de l’application
Poser des questions sur la fréquence de reconstruction de l’image de base : à quelle fréquence les images sont-elles reconstruites ?
Demander le SBOM du conteneur, y compris les bibliothèques système et les composants de l’image de base
Demander si des images de base distroless ou minimales ont été adoptées
Suivre l’âge des images de conteneurs comme indicateur d’accumulation des vulnérabilités

Si vous êtes une petite équipe

Pour le logiciel le plus critique que votre fournisseur livre sous forme de conteneur, demandez les résultats complets de l’analyse des vulnérabilités de l’image de conteneur produits par Trivy ou un scanner équivalent couvrant toutes les couches. Comparez ces résultats à ceux de l’SCA de la couche applicative que le fournisseur a pu vous communiquer auparavant. L’écart, c’est-à-dire les vulnérabilités présentes dans l’analyse du conteneur mais absentes de l’SCA de l’application, correspond à l’exposition aux vulnérabilités des bibliothèques système et de l’image de base que l’évaluation de l’application n’a pas traitée. Demandez à quelle fréquence l’image de conteneur est reconstruite à partir de l’image de base actuelle.

Demander les résultats d’analyse des conteneurs sur toutes les couches pour les logiciels critiques livrés sous forme de conteneurs
Comparer l’analyse des conteneurs à l’SCA de l’application : identifier l’écart de vulnérabilités dû à l’image de base
Poser des questions sur la fréquence de reconstruction de l’image de base
Demander le SBOM du conteneur, y compris les bibliothèques système

Ce qu’il faut exiger

Demandez directement :

« Pour vos logiciels livrés sous forme de conteneurs, analysez-vous l’ensemble des couches de l’image, y compris les bibliothèques système de l’image de base, et à quelle fréquence reconstruisez-vous vos images de conteneurs à partir d’une image de base à jour pour intégrer les mises à jour des paquets du système d’exploitation ? »

Preuves attendues

Résultats d’analyse des images de conteneurs couvrant toutes les couches
Fréquence et processus de reconstruction de l’image de base
SBOM du conteneur, y compris les bibliothèques système
Justification du choix de l’image de base : préférence pour les images distroless ou minimales

Un fournisseur qui confirme la sécurité de ses applications doit être interrogé sur la sécurité de ses images de conteneurs. L’SCA de l’application couvre ce que le fournisseur a écrit. L’analyse des conteneurs couvre ce sur quoi il a construit son code. Les deux sont nécessaires pour les logiciels livrés sous forme de conteneurs.

Comment le prouver

Résultats d’analyse des conteneurs pour les logiciels livrés
Évaluation de l’actualité de l’image de base
Examen du SBOM du conteneur
Exigence de sécurité des conteneurs dans l’évaluation des fournisseurs

À retenir

Application : sécurisée. Image de base du conteneur : obsolète depuis 4 mois, 17 CVE, 2 RCE critiques dans glibc. Évaluation de l’application : terminée. Couche du conteneur : non évaluée. Les images de conteneurs comprennent toute la pile logicielle : le code applicatif et les bibliothèques système sur lesquelles il s’exécute. L’SCA de l’application couvre la couche de code. L’analyse des conteneurs couvre toute la pile. Les vulnérabilités des bibliothèques système de l’image de base sont des vulnérabilités du logiciel livré, quelle que soit la propreté du code applicatif. Les images distroless réduisent la surface. Les reconstructions régulières la maintiennent à jour. L’analyse de toutes les couches la rend visible.