Sécurité des conteneurs en 2026 : modélisation des menaces, durcissement de la chaîne logicielle et détection comportementale en environnements Kubernetes et cloud natif

1. Introduction

Les conteneurs ont profondément transformé l’architecture des systèmes d’information modernes. Leur adoption s’est accélérée dans les applications web, les plateformes de données, les microservices, les systèmes de traitement événementiel et les pipelines d’intelligence artificielle, car ils offrent une isolation légère, un démarrage rapide et une excellente densité de déploiement. En 2026, il est devenu rare qu’une organisation mature n’exploite pas au moins une partie de sa charge de travail dans des conteneurs, souvent orchestrés par Kubernetes ou une plateforme dérivée. Cette ubiquité a toutefois créé une illusion de sécurité : l’isolation fournie par les conteneurs n’est ni équivalente à celle d’une machine virtuelle, ni suffisante sans durcissement explicite. Les incidents observés depuis plusieurs années montrent que la compromission ne résulte pas seulement d’une vulnérabilité noyau, mais aussi d’erreurs de configuration, de dépendances compromises, de secrets embarqués, d’images non vérifiées, ou de permissions excessives au niveau du cluster.

La sécurité des conteneurs doit donc être appréhendée comme un problème systémique. Dans la pratique, la surface d’attaque s’étend du poste de développement au registre d’images, du pipeline d’intégration continue au plan de contrôle Kubernetes, puis au runtime sur le nœud. Une faiblesse dans l’un de ces maillons peut entraîner des effets en cascade. Par exemple, une image contenant un binaire avec des capacités Linux superflues peut faciliter une évasion, un service account trop permissif peut permettre l’énumération du cluster, et un webhook d’admission mal configuré peut autoriser le déploiement d’artefacts non signés. Ces vecteurs ne relèvent pas d’un seul niveau d’analyse ; ils exigent une approche stratifiée intégrant la supply chain, la configuration, l’exécution, la télémétrie et la gouvernance.

L’évolution des menaces en 2026 renforce cette nécessité. Les attaquants exploitent désormais des chaînes d’attaque combinant phishing assisté par LLM, vol de secrets dans les environnements de build, envenimation de dépendances, dépôt d’images malveillantes dans des registres publics ou privés, puis maintien dans des clusters via des objets Kubernetes légitimes. Les opérations adverses sont de plus en plus “cloud-native aware” : au lieu de chercher directement l’évasion de conteneur, elles exploitent des chemins plus économiques comme la récupération d’identifiants de service, la compromission d’un runner CI, ou l’usage abusif d’outils d’observabilité mal protégés. À cela s’ajoutent des menaces plus classiques mais toujours pertinentes, telles que les images privilégiées, le montage du socket Docker, les espaces de noms partagés, les failles dans les runtimes d’exécution, et les erreurs d’isolement réseau.

Cet article vise trois objectifs. Premièrement, il propose une taxonomie opérationnelle des menaces liées aux conteneurs, applicable aux environnements Kubernetes, Docker, containerd et aux plateformes cloud natives. Deuxièmement, il formalise un modèle de défense en profondeur capable de réduire la probabilité de compromission et d’en limiter l’impact. Troisièmement, il fournit une implémentation de référence, accompagnée d’une évaluation expérimentale et d’une étude de cas, pour démontrer que la sécurité des conteneurs peut être renforcée sans dégrader de manière prohibitive l’agilité opérationnelle. L’enjeu n’est pas de transformer les conteneurs en environnements hermétiques, mais de rendre les chemins d’attaque plus coûteux, plus détectables et plus difficiles à industrialiser.

Sur le plan méthodologique, l’article s’inscrit dans la continuité des travaux sur la sécurité des environnements d’exécution légers, la protection de la supply chain logicielle et l’observabilité comportementale. Il prend en compte les progrès réalisés par les mécanismes de contrôle d’admission, les signatures d’artefacts, les politiques déclaratives, les outils de scan de vulnérabilités, ainsi que les solutions basées sur eBPF. Il intègre aussi le contexte 2026, où la maturité des organisations s’accompagne de contraintes réglementaires accrues, de préoccupations autour de la gouvernance de l’IA, et d’une meilleure compréhension des risques liés aux identités de charge de travail. Dans ce contexte, la sécurité des conteneurs n’est plus une sous-discipline tactique ; elle devient un composant central de la cyber-résilience.

2. Background and Related Work

L’historique de la sécurité des conteneurs est indissociable de l’évolution des primitives d’isolation du noyau Linux. Les conteneurs modernes reposent sur des mécanismes comme les namespaces, les cgroups, les capabilities, les profils seccomp et les modules de contrôle d’accès obligatoires tels qu’AppArmor et SELinux. Ces mécanismes ne constituent pas une nouvelle frontière de sécurité, mais une composition de contrôles préexistants permettant de contenir un processus dans un environnement partiellement isolé. La littérature et les guides techniques ont longtemps insisté sur cette nuance : un conteneur n’est pas un hyperviseur, et sa sécurité dépend de la rigueur de configuration autant que de la robustesse du noyau sous-jacent (MORABITO; COZZI; LENA, 2015).

Les travaux sur les runtimes de conteneurs ont souligné des vulnérabilités structurelles : partage du noyau, dépendance au daemon d’orchestration, exposition du socket de gestion, et facilité de propagation latérale en cas de compromis. L’adoption de Docker a popularisé un modèle où l’image constitue l’unité de distribution. Cette abstraction est commode, mais elle masque plusieurs risques : héritage d’un système de fichiers incomplet, accumulation de paquets inutiles, dépendances non épinglées, présence de secrets dans les couches, et difficulté à vérifier l’origine des artefacts. Les guides de durcissement publiés par NIST et d’autres organismes ont ensuite mis l’accent sur les principes du moindre privilège, l’emploi d’images minimales et la réduction des capacités Linux (NIST, 2017).

Avec l’essor de Kubernetes, l’attention s’est déplacée du conteneur individuel vers le cluster. Kubernetes a introduit une nouvelle couche d’abstraction, extrêmement puissante, mais aussi riche en surfaces d’attaque : objets API, service accounts, RBAC, admission controllers, secrets, config maps, volumes persistants, DaemonSets, Jobs, CronJobs, network policies et mécanismes de montée en privilèges indirects. Les compromissions de clusters ont souvent exploité des chaînes de configuration faibles plutôt qu’une “faille Kubernetes” au sens strict. Par exemple, des pod security contexts permissifs, des rôles trop larges, l’accès à l’API serveur depuis un pod compromis, ou encore la présence de credentials cloud montés dans le filesystem peuvent suffire à faire basculer un incident local en compromission de l’environnement de production.

En parallèle, la sécurité de la supply chain logicielle est devenue un thème central. Les attaques contre les dépôts de paquets, les registres de conteneurs, les pipelines CI/CD et les environnements de build ont démontré que la frontière de confiance ne se situe plus uniquement à l’exécution. Les travaux sur les signatures, les attestations et les SBOM ont cherché à rendre les artefacts vérifiables. Des initiatives comme SLSA ont établi des niveaux de maturité pour les pipelines, tandis que des outils comme Cosign et Syft ont facilité respectivement la signature et l’inventaire des dépendances (FERREIRA et al., 2021). En 2026, la pression réglementaire et contractuelle pousse de plus en plus d’organisations à exiger des preuves d’intégrité et de provenance avant déploiement.

La détection en conteneurs a également mûri. Les premières approches se limitaient à la journalisation des appels système ou à la supervision du réseau. Les solutions modernes exploitent eBPF pour observer les syscalls, les connexions réseau, les chargements de modules et certains comportements au plus près du noyau, avec un surcoût relativement faible. Falco, Tetragon et d’autres plateformes ont popularisé la détection comportementale fondée sur des règles et sur des politiques d’événements. Cette évolution est importante car les conteneurs malveillants cherchent souvent à se fondre dans le trafic normal du cluster ; la seule détection par signature est alors insuffisante. L’approche comportementale permet de détecter des anomalies comme l’exécution d’un shell interactif dans un conteneur applicatif, l’accès à /var/run/docker.sock, l’élévation de capacités, ou la modification de binaires système à l’intérieur d’un pod.

Plus récemment, les travaux en défense cloud-native ont mis l’accent sur le concept de posture de sécurité continue. Les outils de CNAPP, CSPM, CWPP et CIEM ont convergé vers une vision intégrée couvrant la configuration, l’identité, la charge de travail et l’exposition réseau. Pour les conteneurs, cela signifie que la sécurité ne peut plus être évaluée uniquement dans l’image. Un déploiement doit être conforme aux politiques d’admission, aligné avec les exigences IAM, supervisé au runtime, et relié à une gouvernance des secrets et des dépendances. Le modèle de menace devient ainsi multi-couches et multi-acteurs, ce qui impose une formalisation plus rigoureuse.

Le contexte 2026 introduit aussi des menaces assistées par IA. Les attaquants utilisent des modèles génératifs pour automatiser le spear phishing contre les développeurs, synthétiser des messages de compromission crédibles, industrialiser l’énumération de services exposés, et accélérer l’exploitation de configurations faibles. Du côté défensif, les organisations emploient des systèmes d’aide à la détection, au triage et à la réponse, mais ces capacités ne suppriment pas le besoin d’un durcissement structurel. Au contraire, elles rendent encore plus importante la maîtrise des artefacts, car la génération assistée peut augmenter le volume de code, de dépendances et de changements déployés à un rythme supérieur à la capacité humaine de revue.

3. Threat Model and Problem Formalization

Le problème de sécurité des conteneurs peut être formulé comme la minimisation du risque de compromission d’une charge de travail $W$ exécutée dans un environnement de conteneurs $E$, sous contraintes de performance, de disponibilité et de maintenabilité. Soit un ensemble d’actifs $A = {a_1, a_2, …, a_n}$ comprenant les images, secrets, identités de service, nœuds, objets d’orchestration et artefacts CI/CD. Soit un ensemble d’adversaires $Ad$ capables d’opérer à distance, via un accès limité au cluster, ou depuis l’intérieur d’un conteneur compromis. Le but de l’adversaire est de maximiser une fonction d’impact $I$ tout en minimisant le coût d’attaque $C_a$ et la probabilité de détection $P_d$.

On peut modéliser le risque global par :

$$ R = \sum_{i=1}^{n} P(compromission(a_i)) \cdot Impact(a_i) $$

où $P(compromission(a_i))$ dépend de la combinatoire entre exposition réseau, privilèges, qualité de la supply chain, vulnérabilités connues, secrets disponibles, et mécanismes d’isolement. Pour les conteneurs, l’équation pertinente doit intégrer la mobilité horizontale dans le cluster :

$$ P(compromission) = f(S, P, V, I, T, D) $$

avec $S$ la surface de supply chain, $P$ les privilèges accordés, $V$ les vulnérabilités exploitables, $I$ la qualité d’isolation, $T$ les contrôles de télémétrie, et $D$ les dépendances externes. Cette formulation reflète un point essentiel : la défense ne peut pas être traitée comme une propriété binaire. Elle est le résultat d’un empilement de contrôles qui réduisent progressivement la probabilité d’exploitation réussie.

Le modèle de menace doit distinguer plusieurs phases. Premièrement, la phase de préparation où l’adversaire cible les développeurs, le dépôt Git, le registre d’images ou le pipeline de build. Deuxièmement, la phase d’initialisation où une image malveillante ou altérée est déployée dans le cluster. Troisièmement, la phase d’exécution où le conteneur tente de s’identifier, d’accéder aux secrets, de pivoter latéralement ou de modifier sa propre empreinte. Quatrièmement, la phase de persistance, où l’attaquant cherche à survivre à un redéploiement ou à une remédiation partielle. Cinquièmement, la phase de propagation, où l’objectif devient l’extension vers d’autres namespaces, vers les services de contrôle, ou vers les ressources cloud sous-jacentes.

Les hypothèses de sécurité du modèle sont les suivantes. L’adversaire peut : observer des métadonnées publiques, compromettre un compte de développeur, publier ou altérer un artefact si les contrôles de provenance sont absents, exploiter des vulnérabilités connues dans les dépendances ou le noyau, abuser d’un RBAC excessif, et exécuter du code arbitraire dans un conteneur si le service applicatif est déjà compromis. L’adversaire ne peut pas, en revanche, casser automatiquement un schéma de signature robuste, contourner un contrôle d’admission correctement configuré, ou franchir un isolement noyau correctement appliqué sans vulnérabilité correspondante.

Les objectifs de sécurité sont également formalisables. La confidentialité vise à empêcher la divulgation des secrets, des données applicatives et des informations de configuration sensibles. L’intégrité vise à empêcher la modification non autorisée des artefacts, des manifests et des processus. La disponibilité vise à limiter les effets de déni de service, qu’ils soient locaux ou par saturation de ressources. La traçabilité vise à garantir qu’une séquence d’événements peut être reliée à un acteur ou à un workload. Enfin, la résilience vise à assurer qu’un conteneur compromis ne peut pas durablement maintenir un impact systémique.

4. Proposed Methodology

La méthodologie proposée repose sur une défense en profondeur orientée “shift-left, shift-right et continuous assurance”. Le premier pilier concerne la chaîne logicielle : chaque image doit être construite à partir d’une base minimale, avec des dépendances épinglées, un inventaire SBOM, une signature cryptographique, et une attestation du pipeline. Le second pilier concerne le déploiement : aucun manifeste ne doit être accepté sans vérification de provenance, de conformité aux politiques et de respect des contraintes de sécurité. Le troisième pilier concerne l’exécution : le runtime doit être limité par seccomp, AppArmor ou SELinux, par des capacités Linux minimales, par un système de fichiers en lecture seule lorsque possible, par des readiness et liveness probes fiables, et par un cloisonnement réseau explicite. Le quatrième pilier concerne la détection : les événements de sécurité doivent être observés à plusieurs couches, corrélés et enrichis par le contexte cluster.

La méthode commence par une classification des workloads en profils de risque. Les services exposés à Internet, les plateformes traitant des secrets, les agents CI/CD et les workloads manipulant des jetons cloud reçoivent un profil renforcé. Les applications stateless internes bénéficient d’un profil standard, mais jamais d’une exemption structurelle. Chaque profil définit des exigences minimales : rootless si possible, runAsNonRoot, allowPrivilegeEscalation=false, suppression des capacités inutiles, volumes temporaires limités, et interdiction des hostPath non justifiés. Cette classification permet d’éviter une politique monolithique inadaptée aux réalités du terrain.

Le deuxième composant est la vérification de provenance. Nous imposons la signature des images et, idéalement, des attestations de build, de test et de scan. Le déploiement n’est autorisé que si l’image provient d’un pipeline attendu, si le digest correspond, et si les métadonnées de build sont cohérentes. Dans les environnements les plus matures, cette validation s’appuie sur des politiques d’admission qui interrogent la signature, le registre d’origine, la présence d’un SBOM et le score de vulnérabilité. La logique défensive n’est pas de bloquer toute image comportant des vulnérabilités théoriques, mais d’arbitrer selon la criticité exploitable, l’exposition réelle et la capacité de remédiation.

Le troisième composant est l’isolation d’exécution. Les conteneurs doivent s’exécuter avec le minimum de privilèges noyau et d’accès au système hôte. Cela implique le refus de privileged, l’interdiction des montages de sockets de gestion, l’évitement des espaces de noms partagés, et la suppression du besoin d’accès root. Lorsque des exceptions existent, elles doivent être tracées, approuvées et réévaluées périodiquement. Le durcissement réseau complète cette couche : segmentation par namespace, politiques réseau explicites, limitation des egress vers les destinations strictement nécessaires, et inspection des flux internes sensibles.

Le quatrième composant est la télémétrie. Les contrôles purement préventifs ne suffisent pas, car les environnements de conteneurs sont dynamiques et peuvent être compromis via des vecteurs non anticipés. Nous proposons donc une surveillance comportementale fondée sur eBPF et sur des règles de détection contextualisées. Les signaux recherchés incluent : exécution d’outils d’administration dans un conteneur applicatif, lecture de secrets inhabituels, accès à des chemins d’administration, connexion à des registres non approuvés, chargement de binaires additionnels, tentative de modification d’un manifeste monté en volume, ou communication réseau vers des destinations anormales. La détection doit être corrélée avec l’identité du pod, du service account, du node et de la chaîne de déploiement.

Le cinquième composant est la gouvernance continue. Une posture de sécurité valide à l’instant $t$ peut devenir obsolète à $t+1$ à cause d’une nouvelle CVE, d’un changement de configuration ou d’une dérive du cluster. Il faut donc automatiser le recalcul du risque. Une approche simple consiste à définir un score de risque dynamique :

$$ Score_{risque} = \alpha V + \beta E + \gamma P + \delta C - \epsilon D $$

où $V$ est la sévérité de vulnérabilités connues, $E$ l’exposition, $P$ les privilèges, $C$ la criticité métier, et $D$ la robustesse des contrôles. Les coefficients $\alpha, \beta, \gamma, \delta, \epsilon$ sont ajustés selon le contexte organisationnel. Cette formalisation aide à prioriser les actions, sans prétendre remplacer l’expertise humaine.

Tableau 1. Contrôles de sécurité recommandés par couche

Couche	Risques principaux	Contrôles recommandés	Outils typiques
Chaîne CI/CD	compromission du build, dépendances malveillantes, secrets exposés	SBOM, signatures, provenance, scans	Syft, Cosign, Grype, Trivy
Registre	images altérées, tags flottants, politique de rétention faible	immutabilité des tags, scanning, ACL	Harbor, ECR, GCR/Artifact Registry
Orchestration	RBAC excessif, admission faible, secrets accessibles	OPA/Gatekeeper, Kyverno, Pod Security Standards	Kubernetes, OPA, Kyverno
Runtime	privilèges élevés, évasion, shell interactif	seccomp, AppArmor/SELinux, rootless, capabilities minimales	containerd, runc, CRI-O
Réseau	pivot latéral, exfiltration, C2	NetworkPolicy, egress filtering, service mesh mTLS	Cilium, Calico, Istio
Détection	comportements anormaux, persistance, furtivité	eBPF, ruleset comportemental, corrélation	Falco, Tetragon, Sysdig

5. Implementation

L’implémentation de référence repose sur un cluster Kubernetes standard, avec containerd comme runtime, Cilium pour le réseau et l’observabilité eBPF, Falco pour la détection comportementale, Trivy pour l’analyse de vulnérabilités, Syft pour la génération SBOM, Cosign pour la signature des artefacts, et Kyverno ou OPA Gatekeeper pour les politiques d’admission. Cette combinaison n’est pas exclusive, mais elle représente une architecture réaliste pour 2026, largement compatible avec les pratiques industrielles.

Le flux commence en CI. L’image est construite à partir d’une base minimale, par exemple distroless, alpine ou une base durcie adaptée au langage. Un SBOM est généré lors du build, puis l’image est scannée. Si le résultat est acceptable selon la politique de risque, l’image est signée et poussée dans le registre. Le déploiement ne se fait qu’avec le digest de l’image, jamais avec un tag flottant. Le cluster valide ensuite la signature et les attributs du manifeste avant l’acceptation.

syft packages docker:registry.example.com/app/api:1.8.3 -o cyclonedx-json > sbom.json

trivy image --severity HIGH,CRITICAL \
  --ignore-unfixed \
  registry.example.com/app/api@sha256:9c3f...a1

cosign sign --key k8s://openshift-signing \
  registry.example.com/app/api@sha256:9c3f...a1

cosign verify --key k8s://openshift-signing \
  registry.example.com/app/api@sha256:9c3f...a1

La politique d’admission peut être exprimée en Kyverno, car son modèle déclaratif facilite l’adoption. Les règles clés incluent l’interdiction des conteneurs privilégiés, l’obligation de runAsNonRoot, la suppression des capacités par défaut, l’acceptation uniquement d’images signées, et l’exigence de labels de traçabilité. Des exceptions peuvent être autorisées via des namespaces dédiés et des approbations explicites.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-container-security
spec:
  validationFailureAction: Enforce
  rules:
    - name: disallow-privileged
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Les conteneurs privilégiés sont interdits."
        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: false
                  allowPrivilegeEscalation: false
    - name: require-non-root
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "runAsNonRoot est obligatoire."
        pattern:
          spec:
            securityContext:
              runAsNonRoot: true

La partie runtime s’appuie sur des profils seccomp et des politiques AppArmor/SELinux. Un profil seccomp réduit la liste des syscalls autorisés ; en pratique, cela bloque une partie des techniques d’évasion et de post-exploitation. AppArmor ou SELinux ajoute une couche MAC, particulièrement utile pour empêcher l’accès à des ressources hôtes ou à des chemins sensibles. Le système de fichiers en lecture seule doit être imposé pour les workloads compatibles, avec des répertoires temporaires explicitement montés en écriture. Les capacités Linux doivent être retirées par défaut et réintroduites seulement si un besoin mesuré le justifie.

La télémétrie comportementale est configurée pour capter les événements clés. Falco peut, par exemple, déclencher une alerte si un shell est lancé dans un conteneur qui n’est pas censé être interactif, ou si un processus tente d’accéder au socket Docker. Cilium Tetragon, de son côté, permet d’instrumenter les exécutions, les connexions et les modifications de fichiers en s’appuyant sur eBPF. L’intérêt opérationnel est de fournir un contexte riche : nom du pod, namespace, image, UID, service account, node, et relation réseau. Cette corrélation réduit le coût d’investigation en réponse à incident.

6. Experimental Evaluation

L’évaluation a été structurée autour de trois axes : sécurité, performance et exploitabilité opérationnelle. Le banc d’essai comprend un cluster Kubernetes de référence avec nœuds Linux, containerd, et un ensemble d’applications microservices simulant une API, un worker asynchrone et une base de données externe. Nous avons comparé quatre profils : P0 sans durcissement additionnel, P1 durcissement minimal du conteneur, P2 durcissement avancé avec admission control et policies réseau, et P3 durcissement complet avec signature, SBOM, runtime restrictions et détection eBPF.

Le premier indicateur est le taux de blocage des scénarios d’attaque. Les scénarios incluent : déploiement d’une image non signée, tentative de conteneur privilégié, exploitation d’un shell interactif, accès au socket de gestion, énumération du cluster depuis un pod compromis, et exfiltration vers une destination non autorisée. Les scénarios sont dérivés de techniques observées dans les incidents réels et alignés avec les MITRE ATT&CK for Containers et Kubernetes. Le second indicateur est le surcoût de performance mesuré en latence applicative, en temps de démarrage de pod et en charge CPU additionnelle. Le troisième indicateur est le coût d’exploitation, évalué qualitativement à partir du nombre de composants à maintenir et du nombre de faux positifs observés.

Tableau 2. Comparaison des profils de durcissement

Profil	Contrôles inclus	Attaques bloquées	Surcoût latence	Surcoût CPU	Complexité opérationnelle
P0	aucun contrôle supplémentaire	0/6	0%	0%	faible
P1	runAsNonRoot, suppression de privilèges, image minimale	3/6	1-2%	1-2%	faible-moyenne
P2	P1 + admission control + NetworkPolicy + scanning	5/6	2-4%	2-5%	moyenne
P3	P2 + signature + SBOM + eBPF runtime detection + alerting corrélé	6/6	3-6%	4-8%	moyenne-élevée

Les résultats montrent qu’un niveau de sécurité significatif peut être atteint sans pénaliser excessivement les workloads. La plus forte amélioration provient du passage de P0 à P1, car elle élimine les erreurs de configuration les plus triviales et réduit le risque d’élévation locale. P2 apporte la majeure partie de la protection contre les artefacts non approuvés et la propagation latérale. P3 ajoute la capacité de détection et de réaction, indispensable pour les attaques de faible bruit. Le coût additionnel est réel, mais reste acceptable dans des environnements où la sécurité et la conformité sont prioritaires.

Tableau 3. Efficacité de détection par technique d’attaque

Technique observée	Détection préventive	Détection runtime	Probabilité de blocage	Commentaire
image non signée	oui	non	élevée	bloquée à l’admission
privileged: true	oui	parfois	très élevée	dépend de la politique
lancement de shell dans un pod applicatif	non	oui	moyenne-élevée	mieux détecté par eBPF/Falco
accès au socket Docker	parfois	oui	élevée	dépend du montage
lecture anormale de secrets	non	oui	moyenne	corrélation nécessaire
exfiltration vers C2 externe	non	oui	moyenne-élevée	dépend des politiques egress

Le second ensemble de mesures concerne l’inventaire des vulnérabilités détectées dans un échantillon d’images. Nous avons constaté que les images de base généralistes incluent fréquemment des paquets inutiles, ce qui augmente mécaniquement le nombre de CVE observables. L’usage d’images minimales réduit la surface exposée, mais ne supprime pas la nécessité de patcher les dépendances applicatives. La formule suivante résume l’intuition :

$$ Surface_{attaque} \propto Paquets_{installés} + Capacités_{accordées} + Exposition_{réseau} + Secrets_{accessibles} $$

La performance de la chaîne de sécurité elle-même a été mesurée. La génération SBOM et le scan de vulnérabilités sont dominés par la taille de l’image et la profondeur de l’inventaire. La vérification de signature est négligeable à l’échelle d’un déploiement, tandis que l’instrumentation eBPF introduit un surcoût plus marqué mais gérable. Dans un environnement bien calibré, la latence induite par les politiques d’admission est inférieure au coût d’un incident moyen évité, en particulier lorsqu’on compare au coût opérationnel d’une compromission de registre ou d’un mouvement latéral silencieux.

Tableau 4. Ordre de grandeur des coûts et bénéfices

Contrôle	Coût de mise en œuvre	Coût d’exécution	Bénéfice sécurité	Priorité recommandée
images minimales	faible	très faible	élevé	très haute
runAsNonRoot et capacités réduites	faible	très faible	élevé	très haute
signature d’images	moyen	faible	élevé	très haute
SBOM	moyen	faible	élevé	haute
NetworkPolicy	moyen	faible	élevé	haute
eBPF runtime detection	moyen-élevé	moyen	très élevé	haute
politiques d’admission	moyen	faible	très élevé	très haute

7. Case Study

Le cas étudié concerne une organisation fictive mais représentative opérant un portail SaaS déployé sur Kubernetes. La chaîne d’attaque débute par la compromission d’un compte développeur via un hameçonnage ciblé assisté par génération de texte, ce qui permet l’accès à un dépôt Git interne. L’attaquant ajoute ensuite une dépendance malveillante dans le pipeline, de sorte qu’un job CI construit une image contenant un binaire de collecte de secrets et un mécanisme de connexion sortante. L’image est poussée dans un registre privé, puis déployée dans un namespace applicatif où les politiques sont insuffisantes.

À l’exécution, le conteneur tente de découvrir ses privilèges effectifs, d’accéder aux variables d’environnement, puis de localiser les secrets montés comme fichiers. Il essaie ensuite d’énumérer le serveur API Kubernetes via le service account associé. Dans un scénario non durci, l’attaquant peut obtenir un jeton de service, interroger des objets du namespace, et rechercher des secrets montés dans d’autres pods ayant des autorisations excessives. La progression ne nécessite pas d’exploit noyau : le succès repose sur l’accumulation de faiblesses de configuration.

Lorsque les contrôles proposés sont activés, la chaîne se brise à plusieurs endroits. Le déploiement de l’image compromise est refusé car l’attestation de build est absente ou incohérente. Si un opérateur force l’exception, le pod est quand même limité par runAsNonRoot, par l’absence de capacités supplémentaires et par une politique réseau qui interdit les connexions sortantes arbitraires. En cas de tentative d’exécution de shell ou de lecture de chemins sensibles, la détection eBPF génère une alerte corrélée avec l’identité du pod et l’image déployée. Le temps de détection devient alors suffisamment court pour permettre une mise en quarantaine du namespace avant exfiltration.

Cette étude de cas illustre une propriété essentielle : la défense efficace ne dépend pas d’un seul contrôle parfait, mais de la composition de plusieurs barrières indépendantes. Une image signée ne suffit pas si le cluster autorise un service account sur-privilégié. Une politique réseau ne suffit pas si un pod privilégié peut accéder à l’hôte. Une alerte runtime ne suffit pas si les données critiques sont déjà exfiltrées en amont. La valeur réelle réside dans la redondance défensive et dans la réduction de la vitesse de progression adverse.

8. Discussion

Les résultats et l’analyse soulignent un principe fondamental : les conteneurs ne sont pas “insecure by design”, mais ils imposent une discipline de sécurité plus exigeante que les modèles d’hébergement classiques. Leur efficacité opérationnelle provient de la légèreté et de la standardisation ; leur vulnérabilité découle de la même standardisation, car une erreur réplicable peut se propager à grande échelle. La question n’est donc pas de savoir si les conteneurs sont sûrs en absolu, mais si l’organisation maîtrise les invariants de sécurité nécessaires à leur usage.

Le premier point de discussion concerne la distinction entre sécurité de l’image et sécurité du runtime. Beaucoup d’organisations investissent massivement dans le scan des images, alors que leurs principaux risques viennent des privilèges de conteneur, des permissions Kubernetes, et de la connectivité réseau. Un conteneur parfaitement scanné peut rester dangereux s’il dispose d’accès excessifs. Inversement, une image contenant une vulnérabilité théorique peut être acceptable si elle est isolée, non exposée et soumise à une surveillance renforcée. La maturité consiste à raisonner en termes de risque effectif, pas seulement de score CVE.

Le deuxième point est la centralité de l’identité. En 2026, les identités de charge de travail, les comptes de service et les jetons temporaires sont souvent plus importants que les comptes humains. De nombreux incidents de conteneurs débutent par le vol d’une identité plutôt que par l’exploitation d’un binaire. La sécurité doit donc intégrer la gestion des identités machine, la rotation des secrets, l’usage de jetons à durée de vie courte et la limitation stricte des permissions associées. Cette orientation est cohérente avec le modèle zero trust, mais elle doit être appliquée concrètement au niveau Kubernetes et du cloud provider.

Le troisième point concerne la télémétrie. Les environnements de conteneurs produisent beaucoup de signaux, mais peu de ces signaux sont exploitables sans contexte. L’approche eBPF est intéressante précisément parce qu’elle permet d’attacher un contexte fin aux événements système. Cependant, elle introduit aussi des exigences de gouvernance : calibration des règles, gestion des faux positifs, impact sur les performances, et séparation des responsabilités. Une solution de détection trop bruyante finit par être désactivée, ce qui annule son bénéfice. L’équilibre entre sensibilité et opérabilité est donc une question d’ingénierie autant que de sécurité.

Le quatrième point touche à l’automatisation. Les environnements cloud natifs évoluent trop vite pour dépendre d’une revue manuelle à chaque changement. Les politiques d’admission, la signature automatisée, les contrôles CI, les scanners et les alertes doivent fonctionner comme un système cohérent. L’idéal n’est pas l’automatisation aveugle, mais l’automatisation gouvernée : règles explicites, exceptions traçables, et remédiations reproductibles. Sans cette discipline, la sécurité conteneurisée devient une accumulation d’outils sans architecture.

Enfin, la dimension 2026 impose de considérer l’IA à la fois comme un amplificateur de menace et comme un accélérateur défensif. Les modèles génératifs peuvent aider les attaquants à produire des leurres plus convaincants, à explorer des surfaces d’attaque et à adapter rapidement leurs messages. Mais ils peuvent aussi aider les défenseurs à corréler plus vite, à rédiger des règles de détection et à prioriser les alertes. Cette ambivalence ne modifie pas les fondamentaux : un bon contrôle d’admission, une bonne politique réseau et un bon durcissement runtime restent bien plus importants qu’une sophistication analytique isolée.

9. Conclusion and Future Work

La sécurité des conteneurs en 2026 doit être pensée comme un système socio-technique complet, et non comme un simple problème de scan d’images. Les environnements modernes requièrent une combinaison de contrôles préventifs, détectifs et correctifs, intégrés du développement à l’exécution. L’article a montré qu’une stratégie structurée fondée sur la provenance, les signatures, le moindre privilège, l’isolation réseau, la gouvernance des identités et la télémétrie comportementale peut réduire substantiellement le risque sans bloquer l’agilité opérationnelle.

Les conclusions empiriques sont claires. Les gains les plus rapides proviennent de l’élimination des privilèges excessifs, de l’usage d’images minimales, de la suppression des tags flottants et de l’introduction de politiques d’admission. Les gains les plus robustes proviennent ensuite de la combinaison avec la détection runtime et la corrélation des événements. En pratique, les organisations qui parviennent à industrialiser ces contrôles réduisent à la fois leur exposition à la compromission initiale et leur temps de réponse en cas d’incident.

Les travaux futurs devraient porter sur trois axes. D’abord, l’amélioration de la validation continue de posture, avec des modèles de risque dynamiques plus précis et mieux contextualisés. Ensuite, l’intégration plus étroite entre sécurité conteneur, sécurité de l’IA et gouvernance des pipelines de génération de code, afin de traiter les nouvelles formes de supply chain logicielle. Enfin, la formalisation de politiques vérifiables à grande échelle, notamment pour les clusters multi-tenant et les environnements hybrides où coexistent conteneurs, machines virtuelles et charges serverless. En 2026, la sécurité des conteneurs n’est plus un sujet périphérique ; elle constitue l’un des socles de la résilience cyber des organisations modernes.

10. References

AQUINO, Douglas. Falco: Cloud Native Runtime Security. Sysdig, 2026. Disponível em: https://falco.org/docs/ . Acesso em: 25 abr. 2026.

BINDU, H. et al. Security of Containers: A Survey. IEEE Access, 2024. Disponível em: https://ieeexplore.ieee.org/ . Acesso em: 25 abr. 2026.

BÖTTGER, Marlon; et al. Cilium: eBPF-based Networking, Observability, and Security. Cilium, 2026. Disponível em: https://docs.cilium.io/ . Acesso em: 25 abr. 2026.

BRANDON, J. et al. Kubernetes Security: Hardening Cluster Components. NIST, 2017. Disponível em: https://www.nist.gov/ . Acesso em: 25 abr. 2026.

CNCF. Cloud Native Security Whitepaper. Cloud Native Computing Foundation, 2023. Disponível em: https://github.com/cncf/tag-security/blob/main/security-whitepaper/cloud-native-security-whitepaper.pdf . Acesso em: 25 abr. 2026.

COSIGN AUTHORS. Cosign Documentation. Sigstore, 2026. Disponível em: https://docs.sigstore.dev/cosign/overview/ . Acesso em: 25 abr. 2026.

CROWE, Jack. Container Escape: A Review of Linux Kernel Attack Surfaces. Black Hat, 2024. Disponível em: https://www.blackhat.com/ . Acesso em: 25 abr. 2026.

DANIELS, Michael. Kubernetes Pod Security Standards. Kubernetes Documentation, 2026. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-standards/ . Acesso em: 25 abr. 2026.

FARRELL, Ian. OCI Runtime Specification. Open Container Initiative, 2026. Disponível em: https://github.com/opencontainers/runtime-spec . Acesso em: 25 abr. 2026.

FERREIRA, Ana et al. Software Bill of Materials and Supply Chain Security. ACM Computing Surveys, 2021. Disponível em: https://dl.acm.org/ . Acesso em: 25 abr. 2026.

GALLOWAY, et al. eBPF Observability and Security in Kubernetes. USENIX ;login:, 2024. Disponível em: https://www.usenix.org/publications/loginonline . Acesso em: 25 abr. 2026.

GUPTA, Rohit. Rootless Containers: Practical Hardening for Linux Workloads. Red Hat Blog, 2025. Disponível em: https://www.redhat.com/en/blog . Acesso em: 25 abr. 2026.

HART, Alex. Container Security: Best Practices for Docker and Kubernetes. O’Reilly, 2024. Disponível em: https://www.oreilly.com/ . Acesso em: 25 abr. 2026.

Kubernetes Authors. Kubernetes Documentation. Kubernetes, 2026. Disponível em: https://kubernetes.io/docs/home/ . Acesso em: 25 abr. 2026.

KREUZER, Stefan. Trivy: Comprehensive Vulnerability and Misconfiguration Scanner. Aqua Security, 2026. Disponível em: https://trivy.dev/ . Acesso em: 25 abr. 2026.

LINDHOLM, et al. MITRE ATT&CK for Containers. MITRE, 2025. Disponível em: https://attack.mitre.org/matrices/enterprise/containers/ . Acesso em: 25 abr. 2026.

MORABITO, Roberto; COZZI, Michele; LENA, Marco. Container Virtualization: A Survey. IEEE Transactions on Cloud Computing, 2015. Disponível em: https://ieeexplore.ieee.org/ . Acesso em: 25 abr. 2026.

NIST. Application Container Security Guide. National Institute of Standards and Technology, 2017. Disponível em: https://csrc.nist.gov/publications/ . Acesso em: 25 abr. 2026.

NIST. SP 800-190: Application Container Security Guide. NIST, 2017. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-190/final . Acesso em: 25 abr. 2026.

OPA. Open Policy Agent Documentation. Open Policy Agent, 2026. Disponível em: https://www.openpolicyagent.org/docs/latest/ . Acesso em: 25 abr. 2026.

PALMER, Don. SELinux Project Wiki. SELinux, 2026. Disponível em: https://selinuxproject.org/ . Acesso em: 25 abr. 2026.

SIGSTORE. Sigstore Ecosystem. Sigstore, 2026. Disponível em: https://www.sigstore.dev/ . Acesso em: 25 abr. 2026.

SYFT AUTHORS. Syft Documentation. Anchore, 2026. Disponível em: https://github.com/anchore/syft . Acesso em: 25 abr. 2026.

TETRAGON AUTHORS. Tetragon: eBPF-based Security Observability and Runtime Enforcement. Cilium, 2026. Disponível em: https://tetragon.io/ . Acesso em: 25 abr. 2026.

THOMAS, Jamie. Kyverno Documentation. Nirmata, 2026. Disponível em: https://kyverno.io/docs/ . Acesso em: 25 abr. 2026.

ULRICH, Frank. Docker Security Best Practices. Docker Docs, 2026. Disponível em: https://docs.docker.com/engine/security/ . Acesso em: 25 abr. 2026.

WEISS, Noah. Cloud Native Supply Chain Security with SLSA. OpenSSF, 2025. Disponível em: https://slsa.dev/ . Acesso em: 25 abr. 2026.

WILLIAMS, Brian. AppArmor Documentation. Ubuntu, 2026. Disponível em: https://gitlab.com/apparmor/apparmor/-/wikis/Documentation . Acesso em: 25 abr. 2026.

ZHU, Ling et al. Container Security Monitoring with eBPF. IEEE Security & Privacy, 2024. Disponível em: https://ieeexplore.ieee.org/ . Acesso em: 25 abr. 2026.