~10 minutes
Cet article fait partie de la série OWASP Top 10 Kubernetes 2026. Retrouvez le tableau de bord complet des dix risques et la matrice STRIDE sur la page d’entrée de la série.
K10 est le risque qui rend les neuf autres partiellement futiles si on ne le traite pas. On peut avoir le RBAC parfait, les NetworkPolicies bien écrites, etcd chiffré, Falco qui tourne : si l’image déployée est compromise, tout ça ne sert qu’à observer l’attaquant travailler depuis l’intérieur.
La supply chain est le vecteur d’entrée par excellence pour les acteurs sophistiqués : ils n’attaquent pas le cluster ; ils rentrent avec les artefacts légitimes. SolarWinds en 2020, CodeCov en 2021, la backdoor xz-utils en 2024, Shai-Hulud sur npm en 2026 : dans chaque cas, l’artefact compromis était signé, distribué par les canaux officiels, et déployé de manière tout à fait normale par des équipes qui suivaient les bonnes pratiques.
Note du PandaRedacteur : Sur Shai-Hulud, j’ai publié une série complète sur ce blog : anatomie technique de l’infection, scénario du phishing à la destruction, modélisation STRIDE et PASTA, bonnes pratiques pour sécuriser les pipelines. Et si vous voulez le cadre général des attaques SCA sur l’infrastructure CI/CD et les assistants IA : La face cachée de la supply chain.
Ce que j’aurais aimé avoir en 2021 quand on discutait de CodeCov : une réponse claire à la question “comment on sait que l’image qu’on déploie est bien celle qu’on a construite ?”. La réponse “c’est la même qu’hier” ne tient pas. La réponse “elle est dans notre registry” tient un peu plus, mais pas assez. La réponse avec SLSA, Cosign et un SBOM vérifié à l’admission est celle qui tient.
Vecteurs d’attaque
L’image depuis un registry public non vérifiée
Je commence par le plus banal, parce qu’il reste le plus fréquent : une image tirée depuis docker.io ou ghcr.io sans vérification de l’intégrité. Le tag latest ou un tag version sans digest.
Le problème n’est pas que les images publiques sont toutes malveillantes. C’est que sans vérification cryptographique, on ne peut pas distinguer une image légitime d’une image compromise. Le tag nginx:1.25 peut pointer sur un digest différent aujourd’hui et demain si quelqu’un a écrasé le tag sur le registry.
La règle exploitable :
- digest obligatoire pour les workloads de production,
- pas de tag flottant.
Le digest est immuable ; le tag ne l’est pas. Un tag est un alias qui peut changer. Un digest SHA256 est l’empreinte de l’image, il ne change jamais.
Note du PandaRedacteur : et croyez moi bien, ca fait quelques années que j’essaye de convaincre des OPS/SRE de ne pas tirer des images depuis les registry publics…Et récemment…paf…encore une….
SolarWinds chez vous
Le pipeline CI/CD est souvent l’un des points vulnérable de la supply chain : il a accès au code source, au registry d’images, aux secrets de déploiement, et potentiellement aux configs Kube de production. Compromettre le pipeline, c’est compromettre tout ce qu’il produit.
Les vecteurs de compromission d’un pipeline sont nombreux : action GitHub tierce compromise, credential volé qui donne accès au pipeline, plugin Jenkins avec une vulnérabilité connue et non patchée, dépendance de build compromise.
L’impact est asymétrique : une compromission de pipeline peut affecter tous les déploiements qui passent par là, dans tous les environnements, pour tous les services. Et elle est difficile à détecter parce que les artefacts produits sont signés par le pipeline légitime.
Sur un exercice de red-team interne, j’ai réussi à accédé a la registry de production en compromettant un secret Jenkins qui avait trop de droits. Le secret avait été créé avec un accès
writeglobal sur l’organisation au lieu d’être scopé au registry du projet. En poussant une image avec une backdoor sur un tag utilisé en production, on avait accès à l’ensemble du cluster de production en moins d’une heure. Aucune alerte. L’image avait passé tous les scans Trivy (la backdoor était dans une lib légitime légèrement modifiée).
Les dépendances sans SBOM
Un SBOM (Software Bill of Materials) est l’inventaire de tout ce qui compose un artefact logiciel : les dépendances directes, les dépendances transitives, leurs versions, leurs licences, leurs hashes. Sans SBOM, on ne sait pas exactement ce qui tourne dans les conteneurs de production.
Le problème concret : une CVE est publiée sur openssl 3.0.5. Sans SBOM, répondre à la question “quels services utilisent cette version ?” prend des heures ; il faut inspecter chaque image, lancer un scan Trivy sur chaque image en production, corréler les résultats. Avec un SBOM centralisé et un outil comme Dependency-Track, la réponse est en quelques secondes.
En 2026, un SBOM n’est plus optionnel pour les organisations qui veulent être capables de répondre aux incidents supply chain dans un délai raisonnable.
Note du PandaRedacteur : et bientot on pourra dire merci aux cocheurs de cases avec le Cyber Resilience Act (CRA). Pour une fois que la compliance sert réellement a quelque chose….
Mitigations 2026
Sigstore/Cosign pour signer et vérifier les images
Cosign signe les images à la construction et permet de vérifier cette signature avant le déploiement. En mode keyless (OIDC), la clé de signature est liée à l’identité du pipeline CI : l’image est signée par “ce workflow GitHub Actions sur ce repo”, pas par une clé qui pourrait être partagée ou volée.
La politique de vérification à l’admission s’exprime dans Kyverno : si l’image n’est pas signée par exactement ce workflow sur cette branche, le déploiement est bloqué à l’admission. Pas d’alerte. Blocage.
SLSA pour attester la provenance des artefacts
SLSA (Supply chain Levels for Software Artifacts) définit des niveaux de confiance sur la provenance des artefacts. Le niveau 3 (votre objectif 2026) impose une provenance vérifiable non falsifiable : le build s’est déroulé dans un environnement éphémère isolé, les sources sont identifiées par hash, et la provenance est signée par l’infrastructure de build.
L’attestation SLSA complète la signature Cosign : la signature dit “qui a signé”, SLSA dit “comment c’était construit”.
SBOM obligatoire et Dependency-Track pour la gestion des CVE
On génère les SBOMs en CycloneDX ou SPDX à partir d’une image ou d’un répertoire de dépendances. Dependency-Track centralise les SBOMs, les corrèle avec les bases CVE et alerte en temps réel quand une nouvelle CVE affecte un composant déployé.
Note du PandaRedacteur: Ajouter une sauce de trivy dessus, c’est tellement simple et indolore qu’on aurait tord de s’en priver…Et tellement bon…
Réduire les droits des pipelines CI/CD
On revient à K08 : les pipelines CI/CD ne devraient avoir que les droits nécessaires pour déployer, scoped au namespace cible. Le droit de push sur le registry doit être scopé au repo du service. Les secrets de déploiement doivent être gérés via OIDC/Workload Identity dès que le provider le permet, pour éliminer les tokens longue durée.
DevSecOps : intégrer K10 dans la chaîne CI/CD
Ce contenu représente de nombreuses heures de travail, d'expérience etc... J'ai remarqué que mon contenu était repris par certaines sociétés/personnes et j'ai donc décidé de donner du contenu minimal sur ce blog. C'est pourquoi je vous invite a me contacter sur LinkedIn en mentionnant cet article pour plus d'informations.
- ✓ Digest obligatoire en production : un tag est un alias mutable ; un digest SHA256 est une empreinte immuable.
- ✓ Cosign keyless lie la signature à l'identité du pipeline : plus de clé de signature partagée ou stockée dans un secret.
- ✓ SBOM = capacité de réponse supply chain : sans inventaire, répondre à une CVE critique prend des heures au lieu de secondes.
- ✓ SLSA v1.0 niveau 3 est l'objectif raisonnable en 2026 : provenance vérifiable, build éphémère isolé, attestation non falsifiable.
- ✓ Le pipeline CI/CD est une cible, pas seulement un outil : ses droits sur les registries et les clusters doivent être scopés et audités comme n'importe quel service de production.