La sécurité des conteneurs est complexe — Aikido Container AutoFix pour la simplifier

La sécurité des conteneurs commence avec votre image de base.
Mais voici le problème :

• La simple mise à niveau vers la version « la plus récente » d'une image de base peut compromettre le fonctionnement de votre application.
• Vous êtes contraint de choisir entre livrer des vulnérabilités connues ou passer des jours à corriger des problèmes de compatibilité.
• Et souvent... vous n'êtes même pas sûr qu'une mise à niveau en vaille la peine.

Dans cet article, nous explorerons pourquoi la mise à jour des images de base est plus complexe qu'il n'y paraît, nous examinerons des exemples concrets et nous montrerons comment automatiser des mises à niveau sûres et intelligentes sans compromettre votre application.

Le Problème : « Mettez simplement à jour votre image de base » — Plus facile à dire qu'à faire

Si vous lisez ceci, vous avez probablement cherché sur Google quelque chose comme « Comment sécuriser vos conteneurs » et le premier point de chaque article bâclé généré par IA que vous avez lu est le suivant : mettez à jour votre image de base. Simple, n'est-ce pas ? Eh bien, pas si vite. 

Votre image de base est votre point central de sécurité ; si elle contient des vulnérabilités, votre application les transporte avec elle. Déroulons ce scénario. 

Vous lancez un scan sur votre image de conteneur et une CVE de haute gravité est détectée. La recommandation utile est de mettre à jour l'image de base, fantastique, vous aurez terminé avant le déjeuner. 

⚠️ CVE-2023-37920 détectée dans ubuntu:20.04
Gravité : Élevée
Corrigée dans : 22.04
Recommandation : Mettre à jour l'image de base

…mais vous découvrez un problème. 

En effectuant une mise à niveau aveugle depuis ubuntu:20.04 à ubuntu:22.04, votre application s'effondre.

Examinons quelques exemples de mise à jour d'une image de base et ce qui se passe en réalité. 

Exemple 1 : Un Dockerfile qui ne fonctionne plus après une mise à niveau

Dockerfile initial :

FROM python:3.8-buster‍
RUN apt-get update && apt-get install -y libpq-dev
RUN pip install psycopg2==2.8.6 flask==1.1.2
COPY . /appCMD ["python", "app.py"]

L'équipe passe à :

FROM python:3.11-bookworm‍
RUN apt-get update && apt-get install -y libpq-dev
RUN pip install psycopg2==2.8.6 flask==1.1.2COPY . /appCMD ["python", "app.py"]

Résultat :

• psycopg2==2.8.6 ne parvient pas à compiler avec des versions plus récentes libpq en-têtes activés lecteur assidu.
• flask==1.1.2 ne prend pas en charge Python 3.11 fonctionnalités d'exécution (les API dépréciées causent des ruptures).
• Le build échoue en CI.
• Votre équipe de développement est furieuse et votre déjeuner est gâché. 

Exemple 2 : Mises à niveau d'images de base introduisant des bugs subtils au runtime

Original :

FROM node:14-busterCOPY . /app
RUN npm ci
CMD ["node", "server.js"]

Mettre à niveau vers :

FROM node:20-bullseye
COPY . /app
RUN npm ci
CMD ["node", "server.js"]

Problème d'exécution :

• node:20 utilise des versions plus récentes OpenSSL versions — la vérification TLS stricte rompt les configurations axios plus anciennes.
• L'application lève une erreur UNABLE_TO_VERIFY_LEAF_SIGNATURE erreurs en runtime HTTP appels aux services hérités.

Pourquoi « latest » est un piège

L'écosystème Docker encourage l'utilisation des tags `latest` ou des versions de pointe. Mais cela signifie souvent que votre application qui fonctionnait lundi tombe en panne subitement mardi. C'est souvent un piège qui entraînera des maux de tête, des pannes et un ralentissement du développement, car vous passerez du temps à corriger des bugs. 

La solution est donc évidemment de se fixer à une version mineure que vous avez testée… Pas si vite, car vous êtes maintenant entré dans le jeu du « whack-a-mole » de la sécurité où vous découvrirez sans cesse de nouvelles CVE qui pourraient vous laisser vulnérable. 

Paralysie décisionnelle : Faut-il mettre à niveau ou non ?

Les équipes de sécurité insistent pour des mises à niveau.
Les développeurs s'y opposent en raison de la stabilité.

Qui a raison ? Cela dépend.

MAIS, pour même comprendre la décision, vous devez examiner toutes les options, ce qui signifie créer une feuille de calcul massive de toutes les versions, des risques de sécurité, des risques de stabilité et de la disponibilité. 

Voyons à quoi cela pourrait ressembler. 

Cela vous laisse face à des choix complexes, médiocres et impossibles. 

1. Restez sur l'ancienne image et acceptez les vulnérabilités
2. Mettre à niveau et casser votre application, au risque d'une interruption de production
3. Tentative de test de compatibilité manuel — des jours de travail

Le flux de travail de mise à niveau manuelle :

Si vous faites cela manuellement, voici à quoi cela ressemble :

• Vérifier les CVE : Trivy image python:3.8-buster
• Rechercher chaque CVE : Est-elle atteignable dans le contexte de votre application ?
• Décider du candidat à la mise à niveau 
• Tester la nouvelle image :
  
  • Build
  • Exécutez des tests unitaires
  • Exécutez des tests d'intégration
• En cas d'échec, essayez de corriger le code ou de mettre à jour les bibliothèques.
• À répéter pour chaque conteneur.

C'est épuisant.

Le coût de l'immobilisme

Vous pourriez penser : « Si ça marche, ne le changez pas. »

Mais les CVEs de conteneurs non corrigées contribuent massivement aux failles de sécurité : « 87 % des images de conteneurs exécutées en production présentaient au moins une vulnérabilité critique ou de gravité élevée. » source 

Il existe également de nombreux exploits connus dans les images de base populaires. 

• Vulnérabilité de Path Traversal (décompression) (CVE-2020-27350) — est resté dans des millions de conteneurs pendant des années.
• Heartbleed (CVE-2014-0160) sont restées dans des conteneurs legacy longtemps après les correctifs officiels.
• PHP-FPM RCE (CVE-2019-11043) permettent à des attaquants distants d'exécuter du code arbitraire via des requêtes HTTP spécialement conçues et était extrêmement courant dans les images de base de conteneurs avec PHP-FPM préinstallé avant d'être patché

Comment notre fonctionnalité Auto-Fix contribue

Pour résoudre ce scénario précis, Aikido Security a déployé notre fonctionnalité d'auto-correction de conteneurs car, eh bien, nous connaissons aussi cette difficulté. 

La fonctionnalité fonctionne comme suit : Aikido scanne vos conteneurs à la recherche de vulnérabilités. Si (ou plus probablement quand) nous détectons des vulnérabilités, nous vous alertons comme toujours, puis au lieu de vous inciter à mettre à jour votre image de base, nous vous proposons différentes options. Nous créons un tableau qui vous indique quelle version de l'image de base résoudra quelles CVE, de cette façon vous pouvez très rapidement constater qu'une mise à jour mineure peut éliminer toutes ou la majorité des CVE de haute gravité, ce qui en fait une mise à niveau adéquate de l'image de base. 

Si la mise à niveau est mineure, vous pouvez créer automatiquement une pull request pour augmenter la version. 

Ce sont des heures de travail économisées.

Conclusion :

• La mise à niveau des images de base de conteneurs est vraiment difficile.
• Le conseil de « simplement mettre à niveau » simplifie à l'excès un processus complexe et risqué.
• Vos équipes ont raison d'être prudentes — mais elles ne devraient pas avoir à choisir entre sécurité et stabilité.
• L'autofix de conteneurs d'Aikido fait le gros du travail pour vous afin que vous puissiez prendre une décision éclairée. 
• Ainsi, la prochaine fois que vous verrez une alerte de vulnérabilité d'image de base, vous ne paniquerez pas. Vous recevrez une PR.