Sécuriser les conteneurs tout au long du cycle de développement logiciel

Les conteneurs deviennent de plus en plus l’unité standard des logiciels. L’image de conteneur, définie techniquement dans la spécification d’image OCI, est un élément clé des outils modernes, de Docker à Kubernetes, en passant par des plateformes comme AWS Fargate et Google Cloud Run. Qu’est-ce que cela implique pour la sécurité des applications ?

Où utilise-t-on les images de conteneur ?

L’un des aspects intéressants des images de conteneur, c’est qu’elles interviennent tout au long du cycle de développement logiciel (SDLC).

• Les développeurs créent les images localement. Elles offrent un moyen pratique de distribuer facilement (parfois trop facilement) des logiciels.

• Les images sont également créées dans le cadre des pipelines d’intégration et de livraison continues. Des métadonnées sur l’application peuvent leur être associées pour faciliter la gestion des actifs.

• Les images sont téléversées vers des registres publics ou privés, depuis lesquels elles peuvent être partagées en vue de leur déploiement.

• Enfin, les images sont déployées dans des clusters, des environnements de développement et de test jusqu’à la production, de plus en plus souvent gérés par Kubernetes ou des outils similaires.

Chacune de ces étapes permet de tester l’image afin d’y détecter des vulnérabilités. Mais quelle est la meilleure étape pour le faire ?

À quelle étape tester nos images ?

Pour sécuriser nos images de conteneur, il est tentant de penser qu’il suffit de les tester à une seule étape du SDLC. Par exemple, si vos images sont sécurisées dans votre registre, vous êtes protégé, n’est-ce pas ? En réalité, la situation est plus nuancée et implique généralement des compromis.

Plus vous effectuez les tests près de la production, plus vous avez confiance dans votre compréhension des risques liés aux applications en cours d’exécution. À moins d’être un éditeur de logiciels qui crée des outils pour d’autres, vous cherchez probablement avant tout à sécuriser les applications que vous exploitez actuellement en production. Tester tard dans le cycle est également utile lorsqu’une nouvelle vulnérabilité est révélée dans une dépendance que vous utilisez. Vous pouvez ainsi déterminer rapidement quelles applications en production sont concernées et agir en conséquence, avec le degré d’urgence approprié.

Cependant, tester uniquement à la fin du SSDLC signifie probablement que les cycles de retour d’information destinés aux développeurs seront longs. Le développeur qui a choisi d’utiliser ou de modifier une image a poursuivi son travail en s’appuyant dessus et est passé à d’autres tâches. Apporter les modifications nécessaires pour corriger la faille devient alors perturbant et coûteux. N’oubliez pas que l’objectif n’est pas seulement de connaître les vulnérabilités potentielles (ce qui est important), mais aussi de les corriger. Les tests locaux offrent le retour d’information le plus rapide, mais reposent sur le fait que chaque développeur pense à lancer une analyse à chaque fois, ce qui est loin d’être exhaustif ou réaliste.

Avant de conclure que le pipeline est donc le bon endroit pour effectuer les tests, il convient également de prendre en compte le coût de mise en œuvre. Vous disposez peut-être d’un ou deux registres de conteneurs centralisés, qui vous permettent d’évaluer toutes les images que vous créez, mais vous avez probablement beaucoup plus de pipelines d’intégration continue. Selon votre niveau d’automatisation et les personnes responsables des différents outils dans votre organisation, il peut être plus judicieux de commencer à un endroit plutôt qu’à un autre.

Il faut également noter que le contexte dont nous disposons varie selon les étapes du SDLC. Des tests effectués localement ou dans le cadre de l’intégration continue nous donnent probablement accès au code source et aux informations de contrôle de version. Cela peut faciliter la détection de certains types de problèmes, par exemple ceux liés au compilateur utilisé ou à des commits non signés effectués par un acteur malveillant. Cela aide aussi à comprendre comment une bibliothèque a été introduite. En revanche, les tests en production nous indiquent précisément quelles images sont utilisées et où, ainsi que leur configuration, ce qui peut nous aider à hiérarchiser les problèmes détectés.

Conclusion

En réalité, tester à un seul endroit peut répondre aux besoins d’une fonction (développement, exploitation ou sécurité, par exemple), mais ne permettra probablement pas d’atteindre pleinement l’objectif global de l’entreprise : détecter et corriger les vulnérabilités le plus rapidement possible. Voici un récapitulatif utile :

Tests de détection des vulnérabilités aux différentes étapes du SDLC

Le point de départ dépend des spécificités de votre organisation. L’objectif idéal est toutefois de tester en profondeur les applications conteneurisées tout au long du SDLC. S’appuyer sur un seul point de contrôle est une approche trop simpliste, qui risque de créer des frictions entre les équipes de développement, d’exploitation et de sécurité, ou de ralentir le déploiement des applications.