Tout ce que vous avez toujours voulu savoir sur la résolution des vulnérabilités de sécurité dans les conteneurs Linux

Pensez à l’image de conteneur la plus importante que vous exécutez actuellement en production. Comment avez-vous choisi son image de base ? Savez-vous combien de vulnérabilités elle contient ? Vous aimeriez le savoir, n’est-ce pas ?

Chez Snyk, nous cherchons à rendre le choix de l’image de base la plus sécurisée plus intelligent, plus fluide et, surtout, davantage fondé sur les données.

Mais commençons par quelques notions de sécurité des distributions Linux, puisque cet article porte sur les images basées sur Linux.

Les distributions Linux en bref

Une distribution Linux (distro) est un système d’exploitation (OS) constitué d’un ensemble logiciel comprenant un noyau Linux (le cœur du système d’exploitation), un système de gestion de paquets, des outils et bibliothèques GNU, des logiciels supplémentaires ainsi que de la documentation. Le tout est regroupé et adapté par ses responsables de maintenance afin d’optimiser ses capacités et de répondre aux besoins de différentes plateformes et différents appareils.

Les distributions sont généralement proposées de deux façons :

• sous forme de binaires compilés (images empaquetées), téléchargeables depuis des dépôts d’images tels que Docker Hub ; les images sont généralement créées à partir des bibliothèques dont le code source est maintenu.

• sous forme de code source, qui permet de modifier le logiciel d’origine. Cela offre une grande flexibilité, d’autant que la plupart des logiciels inclus dans la distribution sont généralement open source.

Il existe aujourd’hui des centaines de distributions Linux, dont la plupart sont activement maintenues. Grâce à leur grande disponibilité et à la flexibilité de leurs fonctionnalités, elles sont utilisées sur différentes plateformes et différents appareils, notamment dans les conteneurs.

Comme tout autre logiciel, les conteneurs sont donc eux aussi susceptibles d’être attaqués en raison des vulnérabilités que leur code peut contenir.

En quoi la sécurité varie-t-elle d’une distribution Linux et d’une version à l’autre ?

La façon dont les différentes distributions sont créées et maintenues varie. Ces différences peuvent notamment concerner le regroupement des composants et leur gestion. Elles entraînent des écarts de taille, de gestionnaires de paquets et de vulnérabilité face aux menaces de sécurité.

La gravité d’une vulnérabilité affectant un composant peut varier d’une distribution à l’autre. Un composant commun à plusieurs distributions peut être considéré comme sûr dans l’une, mais recevoir un score CVE élevé dans une autre, uniquement en raison des différences de mode d’empaquetage.

Certaines distributions sont généralement plus sûres que d’autres grâce aux mécanismes intégrés par leurs responsables dans leur processus de maintenance. Les distributions commerciales et bien établies (Debian, Ubuntu, CentOS, Oracle) disposent d’équipes de sécurité dédiées. Ces équipes vérifient les scores CVE, hiérarchisent les correctifs de sécurité et les mettent en œuvre, tout en veillant à la sécurité globale de la distribution.

Même dans ce cas, les options présentent des différences. Consultez le tableau ci-dessous, qui détaille les différences de gestion entre ces grandes distributions, un facteur qui influe également sur leur niveau de sécurité :

*Alpine adopte une approche différente pour maintenir ses images : les paquets sont régulièrement mis à niveau, avec des correctifs de sécurité pour un petit nombre de ses principaux paquets (curl, …).

En quoi une distribution Linux diffère-t-elle d’un écosystème de langages ?

Les écosystèmes de langages stockent les paquets dans des registres, et les gestionnaires de paquets (comme npm et pip) sont chargés de les maintenir à jour. De même, les distributions sont stockées dans des dépôts de paquets afin d’être réutilisées comme dépendances dans différents projets. Toutefois, elles sont empaquetées sous forme d’images, puis stockées séparément dans des dépôts conçus pour les images, où elles peuvent être téléchargées et utilisées immédiatement dans d’autres projets. Une fois empaquetées pour être téléchargées et utilisées immédiatement, les images sont stockées dans leurs propres registres de paquets, puis mises à jour par leurs gestionnaires de paquets, indépendamment des bibliothèques sources d’origine.

Dans les deux cas, le gestionnaire de paquets est chargé de télécharger régulièrement le paquet, de le mettre à jour, puis de le téléverser à nouveau dans son espace de stockage.

Mais les similitudes s’arrêtent là.

Maintenance des paquets dans les écosystèmes de langages

Pour les paquets des écosystèmes de langages, c’est assez simple : un registre de paquets, au moins un gestionnaire de paquets et une relation directe entre les deux. Le gestionnaire télécharge les paquets depuis le registre et les y téléverse.

Le schéma suivant l’illustre : un exemple général à gauche, valable pour tout dépôt de paquets, et un exemple spécifique à npm à droite.

Maintenance des paquets dans les dépôts des distributions

En revanche, la situation est un peu plus complexe pour les distributions dans les dépôts d’images. Une distribution peut utiliser plusieurs dépôts, plusieurs gestionnaires de paquets et plusieurs outils de téléversement. Le choix du dépôt, du gestionnaire et de l’outil de téléversement dépend de la version de la distribution, de son périmètre (main, contributions, non-free, community), entre autres.

Le schéma suivant l’illustre : à gauche, un dépôt général de paquets pour n’importe quelle distribution et version ; à droite, plusieurs versions de Debian.

Chaque version de Debian utilise le dépôt adapté à la version spécifiée.

Les paquets et leurs versions ne sont pas toujours disponibles dans tous les dépôts. Certaines distributions permettent le rétroportage de paquets (des versions disponibles uniquement pour un type de publication peuvent être installées sur une autre), et certains paquets peuvent être ajoutés directement à une version de la distribution depuis un dépôt externe, comme une archive de paquets personnels (PPA) pour Ubuntu, plutôt que par le gestionnaire de paquets natif. Cette relation complexe entre paquets et distributions contraste avec la relation simple entre registres et gestionnaires de paquets, bien moins sensible aux problèmes de versionnement décrits.

Les complexités de la résolution des problèmes de sécurité des conteneurs

La plupart des équipes de sécurité des distributions ne maintiennent des correctifs de sécurité que pour certains de leurs composants. Debian, par exemple, fournit officiellement des correctifs de sécurité uniquement pour ses composants principaux, comme l’indique sa documentation. Cela s’explique par le processus complexe de triage des différentes images au fil du temps.

Comme nous l’avons indiqué, les images sont créées à partir de leur code source, généralement stocké séparément sous forme de bibliothèques open source. Une fois empaquetée, stockée et maintenue dans son propre dépôt, l’image évolue au fil de ses propres versions, indépendamment de la bibliothèque source, qui suit aussi son propre rythme d’évolution. Ainsi, une vulnérabilité présente dans la bibliothèque peut être absente de l’image. Elle peut être apparue dans une version ultérieure de la bibliothèque et n’avoir, dans ce cas, jamais affecté l’image déjà empaquetée. L’inverse peut également se produire.

Lorsqu’une vulnérabilité est découverte dans une bibliothèque ayant servi à créer une image, les équipes de sécurité doivent trier l’image en conséquence, vérifier si la vulnérabilité est effectivement présente et déterminer si sa composition même permet de la considérer comme une vulnérabilité.

Les versions des distributions plus anciennes et bien établies ne sont généralement pas mises à niveau de façon radicale ; on peut s’attendre à ce qu’elles reçoivent des mises à jour mineures et des correctifs de sécurité pour les nouvelles vulnérabilités.

Les distributions très anciennes en fin de vie (EOL), ainsi que les toutes nouvelles distributions (versions Edge dont la sécurité n’est peut-être pas encore de la responsabilité de l’équipe dédiée), sont souvent considérées comme non maintenues par la plupart des distributions (Debian 7, par exemple, est en fin de vie). Lorsqu’une vulnérabilité affecte la version X d’un paquet, disponible uniquement dans des versions en fin de vie ou tout juste publiées, elle peut ne pas figurer dans les avis de sécurité de la distribution. Le niveau de prise en charge de la sécurité d’une distribution pour les versions en fin de vie et les versions de pointe ne reflète donc pas nécessairement son état de sécurité réel. Dans ces cas, les informations disponibles ne suffisent pas à Snyk pour détecter toutes les vulnérabilités, et certaines vulnérabilités critiques peuvent même passer inaperçues.

Pourquoi ma distribution Linux n’est-elle pas prise en charge ?

Chaque image basée sur une distribution que nous prenons en charge est analysée à l’aide de notre base de données des vulnérabilités, en fonction de sa distribution et de sa version. Après l’analyse de l’image, nous répertorions les vulnérabilités et fournissons des détails sur chacune d’elles et sa source, indiquons si elle est corrigée, quelles distributions et versions sont concernées, ainsi que la version à partir de laquelle elle est corrigée.

Lors de la collecte des vulnérabilités, nous faisons de notre mieux pour suivre chaque nouvelle version et préparer notre feuille de route en conséquence. Nous suivons également de près les activités et les besoins de nos utilisateurs afin d’enrichir notre base de données, et restons toujours disponibles pour échanger avec eux à l’adresse support@snyk.io et sur notre compte Twitter. Nous faisons aussi un effort particulier pour prendre en charge les versions LTS des fournisseurs examinés dans cet article. Cela dit, nous ne prenons pas en charge toutes les distributions existantes. Par exemple, si votre image repose sur une distribution très ancienne ou toute récente, il est probable que Snyk ne la prenne pas en charge.

Comment Snyk sait-il quelles images de base sécurisées recommander ?

Nous collectons également régulièrement des données dans un large éventail de dépôts, en récupérant plusieurs fois par jour toutes les balises de chaque dépôt sur Docker Hub afin de rester à jour. Ces informations nous permettent aussi de vous recommander des mesures correctives pour l’image de base (ou parent), à condition que vous ayez associé vos projets Snyk au Dockerfile correspondant.

Si vous connaissez l’analyse des applications de Snyk, vous avez peut-être l’habitude de trouver quelques vulnérabilités, voire quelques dizaines, par dépôt surveillé ou testé. Dans l’écosystème Linux, les chiffres sont tout autres : quelques centaines de vulnérabilités, c’est assez courant.

Cela peut sembler accablant. C’est pourquoi nous essayons de vous fournir des conseils et des informations plus exploitables sur l’image et ses vulnérabilités. Pour nous aider, nous vous demandons de fournir le Dockerfile, qui fait souvent partie d’un projet de conteneur.

Lorsque vous utilisez Snyk pour analyser vos images, vous pouvez ajouter un lien vers le code source où vous avez stocké le Dockerfile. Une fois le dépôt analysé, nous pouvons vous proposer des conseils de correction en fonction des résultats. Découvrez comment créer un lien vers votre Dockerfile dans notre documentation.

À partir du Dockerfile, nous détectons l’image de base. Nous pouvons ainsi déterminer le nombre de vulnérabilités provenant de l’image de base et celui des vulnérabilités introduites par les autres couches du Dockerfile. Ces informations vous aident à décider s’il faut modifier les autres couches définies dans le Dockerfile ou remplacer l’image de base par une image plus sécurisée.

Pour vous recommander des mises à niveau pertinentes, nous récupérons et analysons en continu des dizaines de dépôts et des centaines de tags. Nous comparons ensuite notre base d’images à notre base de données des vulnérabilités afin de trouver l’image disponible la plus sécurisée, avec des résultats à jour. Nous vous proposons alors des tags du dépôt pour votre image de base, notamment :

• une mise à niveau mineure — comme son nom l’indique, un tag correspondant à une mise à niveau mineure par rapport à votre tag actuel. Une simple mise à niveau mineure peut parfois éliminer des dizaines, voire des centaines de vulnérabilités. Alors, pourquoi ne pas essayer ?

• une mise à niveau majeure — passer à la prochaine version majeure

• une solution alternative — nous recommandons d’autres images sans lien avec celle-ci, qui pourraient convenir à votre conteneur

Nous considérons un tag alternatif comme une option de mise à niveau s’il répond aux critères suivants :

• Il présente moins de vulnérabilités de gravité élevée, ou autant de vulnérabilités de gravité élevée mais moins de vulnérabilités de gravité moyenne, et autant ou moins de vulnérabilités de gravité faible.

• La distribution du système d’exploitation associée au tag de l’image candidate n’est ni trop ancienne, ni à la pointe, ni sans prise en charge à long terme (LTS), ni instable.

• Comme les avis de sécurité des distributions Alpine ne couvrent qu’un petit sous-ensemble des paquets corrigés, nous estimons que les images basées sur Alpine offrent une visibilité limitée sur la sécurité. C’est pourquoi nous ne recommandons pas les tags basés sur Alpine.

Les mises à niveau alternatives peuvent utiliser des tags issus d’autres distributions et représentent donc généralement un changement beaucoup plus risqué. Nous souhaitons toutefois vous fournir le plus d’informations possible sur les options qui s’offrent à vous pour sécuriser votre image.

Conclusion

Les conteneurs diffèrent des bibliothèques, ce qui rend incontestablement la sécurité et la priorisation des vulnérabilités plus complexes. Pourtant, les conteneurs sont omniprésents, compte tenu de leurs avantages évidents et essentiels. Cela ne signifie pas pour autant que vous devez déployer des conteneurs dangereux ! Avec un peu de préparation et de bons outils de sécurité, comme Snyk, vous pouvez grandement faciliter la sécurisation de vos conteneurs.

Dans tous les cas, il est important d’examiner régulièrement vos conteneurs pour qu’ils restent aussi sûrs que possible. Lorsque vous découvrez une vulnérabilité et devez la corriger en remplaçant votre image de base, tenez compte des points suivants pour sécuriser votre conteneur sans le compromettre :

• Vérifiez si vous dépendez d’un paquet du système d’exploitation. Si c’est le cas, assurez-vous que la mise à niveau ne provoque pas de dysfonctionnement.

• Tenez compte de la taille de l’image.

• Si vous envisagez une mise à niveau vers une solution alternative, vérifiez également les commandes et fonctionnalités spécifiques à la distribution que vous utilisez, puis mettez-les à jour en conséquence.

Essayez dès aujourd’hui d’analyser vos images avec Snyk.