Conseils pour renforcer la sécurité de vos images de conteneurs

Dans la première partie de cette série d’articles, nous avons passé en revue les bonnes pratiques de sécurité pour les images de base que vous utilisez peut-être. Mais que devient la sécurité des images de conteneurs quand on y ajoute d’autres éléments ? Vous installez peut-être des logiciels supplémentaires provenant de sources en amont et vos applications personnalisées ont peut-être leurs propres dépendances. Ces éléments ajoutés sont sous votre contrôle : il vous revient donc de corriger les vulnérabilités que vous avez introduites.

Établir une référence de base

Lorsque vous créez vos images de conteneurs, il est judicieux d’analyser uniquement l’image de base avant d’y apporter des modifications. Vous établissez ainsi une référence de sécurité et pouvez facilement identifier les vulnérabilités présentes dans l’image de base et celles que vous avez ajoutées dans les couches suivantes. Si vous créez des images avec plusieurs couches supplémentaires — par exemple une couche de middleware personnalisée et votre application — il peut également être utile d’établir une référence à chaque étape et de conserver ces images séparément. Vous saurez ainsi clairement d’où proviennent les vulnérabilités.

Définir des priorités

Il n’est probablement pas réaliste, sauf pour les applications les plus simples, d’espérer une sécurité parfaite des images de conteneurs, c’est-à-dire l’absence totale de vulnérabilités. Comme nos ressources pour les corriger ne sont pas illimitées, nous devons établir des priorités et décider lesquelles corriger et lesquelles accepter.

Ces décisions peuvent toutefois être très difficiles à prendre lorsque votre outil d’analyse signale un grand nombre de vulnérabilités dans vos images. L’analyse de sécurité risque alors de générer tellement d’informations qu’elles submergent les équipes, qui finissent par les ignorer ou désactiver complètement l’analyse.

Par ailleurs, les vulnérabilités ne se résument pas à une opposition entre tout ou rien. Une vulnérabilité donnée peut ne poser problème que dans des circonstances très précises ou sur une architecture ou une plateforme particulière. Sans lire les détails de chaque vulnérabilité, comment savoir si elle représente un risque dans notre environnement ?

La hiérarchisation des priorités n’est pas une science exacte et peut s’appuyer sur différents facteurs. La gravité seule nous renseigne peu, hormis sur l’impact potentiel. Le score CVSS, qui tient compte de facteurs comme la facilité d’exploitation et l’impact, apporte davantage de contexte. Nous pouvons aussi prendre en compte la maturité du code d’exploitation disponible et, surtout, l’existence d’un correctif. Les vulnérabilités graves pour lesquelles il existe un exploit et un correctif sont probablement à traiter en premier. Les scores de priorisation de Snyk tiennent compte de tous ces facteurs pour présenter les vulnérabilités et donner aux développeurs des informations claires sur lesquelles fonder leurs décisions.

Définir une stratégie de sécurité des images de conteneurs

La sécurité implique presque toujours des compromis, notamment entre les efforts à fournir et le niveau de risque. Quel effort faut-il déployer pour corriger un problème, par rapport au risque qu’il représente dans mon environnement ? Pour décider comment prioriser la correction des vulnérabilités, la première étape consiste généralement à définir une stratégie. En voici un exemple très simple :

• Aucun CVE grave en production

• Aucune vulnérabilité avec un exploit mature

• Appliquer les correctifs lorsqu’ils sont disponibles

En suivant cette approche, vous pourriez réduire considérablement le nombre total de vulnérabilités dans la plupart des cas.

Atténuation des risques : chaque environnement est différent

Les scores vous donnent une idée de la gravité, mais certains éléments relèvent évidemment de votre appréciation. Vous pouvez par exemple considérer qu’une vulnérabilité grave nécessitant un accès au shell local présente un risque moindre dans votre environnement, car d’autres contrôles empêchent cet accès. Vous pouvez utiliser des conteneurs distroless, qui n’incluent pas de shell : ces contrôles contribueraient alors à atténuer le risque.

Comprendre vos limites de sécurité

Dans certains environnements, vous pouvez considérer le réseau comme fiable et donc juger moins problématique toute vulnérabilité exposée sur ce réseau. Cette approche pose problème dans la plupart des environnements informatiques modernes, car la connectivité est si complexe qu’il est très difficile de définir une limite, sauf dans les environnements totalement isolés. Le problème est particulièrement marqué dans le cloud. Cette approche ne vous protège pas non plus contre les acteurs malveillants internes, qui peuvent représenter un risque important, surtout dans les grandes organisations. En général, il est plus prudent de considérer tous vos réseaux comme non fiables.

Connaître vos outils

C’est là qu’il est important de comprendre les outils que nous utilisons pour détecter ces problèmes. La plupart des outils d’analyse d’images vous permettent de filtrer leurs résultats afin de configurer les informations qui vous intéressent le plus. C’est particulièrement important lorsque vous intégrez l’analyse de sécurité à vos pipelines de livraison logicielle. Vous ne voulez certainement pas que vos builds ou vos déploiements échouent sans cesse à cause d’informations non pertinentes ou de risques que vous avez décidé d’atténuer autrement. Snyk fournit l’option --fail-on flag pour contrôler le statut de sortie de l’analyse CLI. La CLI ne renvoie alors un échec que dans certaines circonstances. Par exemple :

1snyk container test purpledobie/mattj-goof --fail-on upgradable

Cette commande ne renverra un échec que si elle trouve au moins une vulnérabilité pouvant être corrigée dans l’image. Elle ne le fera pas si les vulnérabilités détectées ne peuvent pas être corrigées ou faire l’objet d’un correctif.

La Snyk CLI fournit également des résultats au format JSON, que vous pouvez filtrer ensuite. Ce format permet de créer des filtres complexes à l’aide d’outils comme jq :

1snyk container test purpledobie/mattj-goof --json | jq '.vulnerabilities[] | select(.CVSSv3 | test("AV:N"))'

Cet exemple très simple ne renvoie que les vulnérabilités exploitables depuis le réseau. Pour cela, il filtre la liste en fonction du vecteur d’attaque du score CVSS, qui doit être défini sur « Network ». En créant des filtres de ce type, vous pouvez intégrer des décisions complexes fondées sur des règles à vos analyses.

Automatiser la correction

Une fois votre stratégie définie et vos outils configurés, l’automatisation des corrections peut alléger la charge cognitive des développeurs en réduisant le nombre de décisions à prendre, tout en diminuant les ressources nécessaires. Les demandes de tirage automatisées pour les problèmes clairement couverts par votre stratégie et pour lesquels des correctifs sont disponibles facilitent leur correction continue par les équipes de développement. Vous pouvez ainsi réserver les interventions manuelles aux cas particuliers les plus complexes.

Sécurité approfondie des images de conteneurs

L’analyse des conteneurs peut ne pas détecter certains éléments, comme les binaires qui ne font pas partie des paquets ajoutés pendant le processus de build. Elle ne doit donc pas constituer votre unique protection. C’est pourquoi il est également important d’analyser votre base de code et vos Dockerfiles. Pour les charges de travail en production, vous devez presque certainement adopter le principe de défense en profondeur et inclure d’autres contrôles de sécurité, comme la détection d’anomalies à l’exécution et l’analyse des terminaux.

Protégez vos conteneurs

La sécurité des images de conteneurs soulève de nombreuses questions, mais nous espérons que cet article vous aura donné quelques pistes pour commencer. Pour évaluer la sécurité de vos images de conteneurs actuelles, créez gratuitement un compte Snyk et lancez une analyse.