À partir du 11 septembre 2026, tout éditeur qui distribue une image de conteneur, un opérateur Kubernetes ou un Helm chart en Europe entre officiellement dans le champ du Cyber Resilience Act. Ce n’est plus une hypothèse de conformité lointaine. C’est une échéance calendaire, avec des obligations de signalement sous 24 heures et des amendes qui peuvent grimper jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial. Au même moment, l’Office fédéral allemand de la sécurité informatique (BSI) a fait passer son catalogue de conformité cloud C5 de 121 à 168 critères, avec un domaine entièrement nouveau consacré au cycle de vie des conteneurs. Pour les équipes DevOps, RSSI et éditeurs de logiciels cloud-native qui vendent en France et en Europe, les deux textes se percutent au même moment et redessinent, dans l’urgence, la manière dont on construit, scanne et signe une image Docker.
Le choc de calendrier : CRA et C5:2026 arrivent en même temps
Le règlement (UE) 2024/2847, alias Cyber Resilience Act, est entré en vigueur le 10 décembre 2024. Mais son application se fait par vagues successives, et deux de ces vagues tombent presque coup sur coup au second semestre 2026. Le chapitre IV, qui organise la désignation des organismes d’évaluation de la conformité, s’applique depuis le 11 juin 2026. L’article 14, celui qui concentre toute l’attention des équipes sécurité en ce moment, entre en application le 11 septembre 2026. Ce jour-là, tout fabricant d’un produit comportant des éléments numériques devra signaler à l’ENISA et au CSIRT national compétent toute vulnérabilité activement exploitée dans un délai de 24 heures après en avoir eu connaissance. La Commission européenne présente le texte comme le premier règlement horizontal de sécurité produit couvrant l’ensemble du cycle de vie du logiciel commercialisé dans l’UE.
Le texte ne cite jamais explicitement le mot « conteneur » ou « Kubernetes ». Mais la Commission européenne a publié en mars 2026 un projet de lignes directrices qui introduit un test en trois points pour déterminer si un composant cloud entre dans le périmètre du CRA : le composant traite-t-il des données à distance, une fonction essentielle du produit en dépend-elle, et le fabricant en garde-t-il le contrôle. Si les trois réponses sont oui, le composant cloud tombe sous le règlement. Des analyses de vendeurs spécialisés, dont RapidFort, en concluent que les images de conteneurs, les opérateurs Kubernetes et les Helm charts distribués commercialement dans l’UE sont couverts dès lors qu’ils bénéficient d’un support commercial.
En parallèle, le BSI a publié fin mars 2026 la version finale de son catalogue C5:2026, le Cloud Computing Compliance Criteria Catalogue qui sert de référence à la certification des fournisseurs cloud opérant en Allemagne et, de facto, dans une bonne partie de l’Europe germanophone et au-delà. La révision est loin d’être cosmétique : le nombre de critères passe de 121 dans C5:2020 à 168 dans C5:2026, toujours répartis en 17 domaines thématiques, mais désormais découpés en sous-critères alignés sur le futur schéma européen EUCS (European Cybersecurity Certification Scheme for Cloud Services). Pour la première fois, le catalogue est aussi publié en format YAML lisible par machine, en plus du PDF et de l’Excel habituels, pour permettre son intégration directe dans les outils de gouvernance, risque et conformité.
Ce que le CRA exige concrètement d’une image de conteneur
Le règlement impose une nomenclature logicielle lisible par machine, la SBOM (Software Bill of Materials), pour chaque produit couvert, y compris les logiciels distribués via des images de conteneurs. Selon Anchore, éditeur spécialisé qui a publié en août 2026 une documentation détaillée de préparation au CRA, l’annexe I, partie II, point 1 du règlement exige une SBOM par version, couvrant au minimum les dépendances de premier niveau du produit. Concrètement, cela signifie qu’une image construite à partir d’un socle public récupéré sans vérification n’est plus une pratique acceptable pour un produit commercialisé en Europe : chaque composant de l’image de base et de ses dépendances doit apparaître dans la SBOM et faire l’objet d’un suivi de vulnérabilités continu.
L’article 13 du CRA ajoute une contrainte de durée : les fabricants doivent fournir des mises à jour de sécurité pendant au moins cinq ans à compter de la mise sur le marché, ou pendant toute la durée de vie prévue du produit si elle est plus courte. Pour une image de conteneur maintenue en production, cela revient à s’engager sur un cycle de patch de cinq ans minimum, ce qui bouleverse la façon dont beaucoup d’éditeurs gèrent aujourd’hui leurs registres et leurs tags de version.
Activestate, dans un guide de conformité publié courant 2026, résume la logique de façon directe : quand une application conteneurisée fait partie d’un produit avec éléments numériques, le conteneur et tout son contenu tombent sous le regard du CRA. Cela inclut les bibliothèques tierces embarquées dans l’image, les paquets système du socle Linux utilisé, et les dépendances transitives récupérées automatiquement au moment du build. Tirer une image publique arbitraire depuis un registre communautaire, sans provenance vérifiée, n’est plus considéré comme conforme.
C5:2020 contre C5:2026 : ce qui change pour les fournisseurs cloud
Le catalogue C5 sert depuis 2020 de référentiel d’audit pour les fournisseurs cloud qui veulent démontrer un niveau de sécurité crédible face aux administrations et grandes entreprises allemandes, un usage qui a largement débordé les frontières nationales. La version 2026 conserve l’architecture en 17 domaines mais ajoute un domaine dédié à la gestion du cycle de vie des conteneurs, couvrant la provenance des images, l’isolation à l’exécution, la sécurité de l’orchestration et l’intégrité de la chaîne d’approvisionnement des registres.
| Caractéristique | C5:2020 | C5:2026 |
|---|---|---|
| Nombre de critères | 121 | 168 |
| Domaines thématiques | 17 | 17 (sous-critères ajoutés) |
| Domaine conteneurs dédié | Absent | Présent (provenance, exécution, registre) |
| Format machine-readable | PDF, Excel | PDF, Excel, YAML |
| Alignement EUCS | Non | Oui, sous-critères structurés |
| Date limite pour audits Type-1 | – | 1er juin 2027 |
Selon le BSI, les organisations disposent d’environ huit mois à partir de fin juillet 2026 pour conduire un gap assessment complet entre les deux versions, adresser les nouveaux domaines (sécurité des conteneurs, stratégie post-quantique, confidential computing), remapper leurs preuves d’audit existantes et intégrer le nouveau format YAML dans leurs outils de gouvernance. Les organisations déjà certifiées Type-1 sous C5:2020 doivent basculer vers les critères C5:2026 au plus tard le 1er juin 2027, ce qui laisse une fenêtre de transition documentée mais courte pour des équipes qui gèrent déjà l’échéance CRA de septembre 2026 en parallèle.
Un écosystème d’outils qui se réorganise autour de la conformité
La pression réglementaire a un effet direct et mesurable sur le marché des outils de sécurité des conteneurs. Selon Mordor Intelligence, le marché mondial de la sécurité des conteneurs est estimé à environ 3,69 milliards de dollars en 2026, avec une projection à 9,42 milliards de dollars d’ici 2031, soit une croissance annuelle proche de 20,66 %. Market Research Future, avec une méthodologie différente, avance un chiffre proche de 3,98 milliards de dollars pour 2026 et évalue la part européenne à environ 26 % du marché mondial, ce qui situerait la dépense européenne autour de 900 millions à 1 milliard de dollars cette année, portée notamment par les obligations NIS2 et CRA.
Sur le terrain des outils eux-mêmes, plusieurs mouvements récents illustrent la bascule. Anchore, éditeur spécialisé dans la gestion de SBOM, a publié en mai 2026 la version 6 de sa plateforme Anchore Enterprise, présentée explicitement comme une solution de conformité pilotée par SBOM pour répondre aux obligations CRA de signalement à partir du 11 septembre 2026. L’outil exporte des SBOM unifiées aux formats CycloneDX 1.6 ou SPDX 2.3, directement exploitables dans la documentation technique exigée par le règlement.
Docker a de son côté renforcé Docker Scout, sa fonctionnalité de génération de SBOM intégrée à l’écosystème Docker, capable de produire des nomenclatures au format SPDX directement depuis une image locale ou distante. Sigstore, le projet open source de signature d’artefacts logiciels, continue d’être présenté comme une brique d’infrastructure quasi invisible mais structurante pour signer des images OCI et des SBOM : Cosign a ajouté le support de Rekor v2 pour la vérification des journaux de transparence, renforçant la capacité des équipes à prouver la provenance d’une image sans processus manuel lourd.
Aqua Security a annoncé en février 2026 un repositionnement stratégique vers la sécurité à l’exécution (runtime), avec l’idée de prioriser les vulnérabilités réellement exploitables plutôt que la liste théorique de CVE présentes dans une image. En avril 2026, l’éditeur a lancé Aqua Compass, un serveur MCP permettant l’investigation et la remédiation automatisées d’incidents runtime, avec un tableau de bord qui chiffre l’exposition financière réelle d’une organisation. Trivy, l’outil de scan open source maintenu par Aqua, a lui-même traversé un incident révélateur : en mars 2026, une vulnérabilité de chaîne d’approvisionnement référencée CVE-2026-33634 a touché plusieurs artefacts Trivy distribués sur Docker Hub, poussant l’équipe à durcir ses releases avec des attestations de provenance SLSA et une protection renforcée des tags Git.
Signe supplémentaire de l’importance stratégique du secteur, Google Cloud a finalisé le 11 mars 2026 le rachat de Wiz pour 32 milliards de dollars en numéraire, sa plus grosse acquisition à ce jour. Wiz, plateforme de protection des applications cloud-native (CNAPP) qui scanne sans agent les environnements AWS, Azure et Google Cloud, avait dépassé le milliard de dollars de revenu annuel récurrent avant le rachat. L’opération n’est pas spécifique au CRA, mais elle confirme à quel point la sécurité cloud-native est devenue un enjeu de premier plan pour les grands fournisseurs.
Comparatif des principaux outils de conformité conteneurs
| Outil | Fonction principale | Format SBOM | Positionnement CRA |
|---|---|---|---|
| Anchore Enterprise | Gestion et export de SBOM | CycloneDX 1.6, SPDX 2.3 | Documentation explicitement dédiée au CRA |
| Docker Scout | SBOM et analyse de vulnérabilités d’image | SPDX, JSON | Intégré au flux Docker standard |
| Trivy (Aqua) | Scan d’image et de SBOM | Consommation CycloneDX/SPDX | Outil de référence dans les pipelines DevSecOps européens |
| Sigstore / Cosign | Signature et vérification de provenance | Signature d’artefacts OCI et SBOM | Preuve technique de non-altération du code |
| Aqua Platform | Sécurité à l’exécution (runtime) | N/A (détection comportementale) | Priorisation des vulnérabilités exploitables |
| Wiz (Google Cloud) | CNAPP multi-cloud sans agent | N/A (posture et configuration) | Visibilité globale, hors périmètre SBOM strict |
Le fossé entre sensibilisation et préparation réelle
L’ENISA a mené entre février et mars 2026 sa première enquête dédiée aux PME face au CRA, avec 194 organisations réparties dans 31 pays. Le résultat dessine un écart net entre connaissance du texte et préparation opérationnelle : 66 % des répondants avaient entendu parler du Cyber Resilience Act avant l’enquête. Mais l’agence souligne elle-même une marge de progression importante dans la compréhension pratique des exigences, et identifie la gestion des incidents et le suivi du cycle de vie produit comme les points les plus faibles, en particulier chez les micro-entreprises.
Un autre indicateur, issu du rapport IoT & OT Cybersecurity 2025 d’ONEKEY, cité dans une communication 2026, apporte une lecture complémentaire côté fabricants d’objets connectés : seuls 14 % des répondants avaient pris des mesures poussées pour assurer leur conformité aux exigences liées au CRA. 38 % avaient engagé de premières démarches, et 38 % n’avaient entrepris aucune action. Côté connaissance du texte, 32 % se disaient pleinement familiers avec les exigences du CRA, 36 % avaient au moins commencé à les examiner, et 27 % ne s’étaient pas encore penchés sur le sujet.
Aucune de ces enquêtes ne donne un taux de conformité officiel unique, et il serait trompeur d’en extrapoler un chiffre précis. Mais la tendance qui se dégage est cohérente d’une étude à l’autre : la majorité des organisations concernées connaît désormais l’existence du règlement, une minorité seulement a engagé les travaux techniques nécessaires pour signaler un incident sous 24 heures ou produire une SBOM exploitable à l’échéance du 11 septembre 2026.
Amendes possibles, mais aucune sanction encore prononcée
L’article 64 du règlement fixe un barème de sanctions à trois niveaux. Le non-respect des exigences essentielles de cybersécurité de l’annexe I ou des obligations des articles 13 et 14 (conception, fabrication, signalement des vulnérabilités) peut entraîner une amende allant jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial annuel, le montant le plus élevé étant retenu. Le non-respect d’autres obligations du texte, comme la documentation de conformité, peut coûter jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires. Fournir des informations incorrectes, incomplètes ou trompeuses aux autorités expose à une amende allant jusqu’à 5 millions d’euros ou 1 % du chiffre d’affaires.
À la mi-août 2026, aucune amende ni sanction publique n’a encore été prononcée au titre du CRA. C’est logique : les obligations de signalement de l’article 14 ne deviennent contraignantes que le 11 septembre 2026, et l’application intégrale du texte, avec marquage CE et évaluation de conformité complète, n’interviendra que le 11 décembre 2027. Les cabinets d’avocats qui suivent le dossier insistent néanmoins sur un point souvent sous-estimé : les obligations de signalement s’appliquent dès le premier jour à tous les produits déjà commercialisés, pas seulement à ceux lancés après l’échéance. Un éditeur qui distribue depuis plusieurs années une image de conteneur encore utilisée en production tombe donc sous le coup du texte, même sans nouvelle version prévue.
Contexte historique : d’ENISA à EUCS, une trajectoire de dix ans
Le CRA et C5:2026 ne sortent pas de nulle part. Ils prolongent une trajectoire européenne engagée depuis le règlement sur la cybersécurité de 2019, qui avait donné à l’ENISA un mandat élargi et posé les bases d’un schéma européen de certification de cybersécurité. Le C5 lui-même existe depuis 2016 sous une forme antérieure, avant sa refonte en 2020 qui en avait fait un standard largement adopté par les hyperscalers pour prouver leur conformité auprès des clients allemands et européens. La directive NIS2, transposée dans la plupart des États membres au cours de 2024 et 2025, avait déjà élargi le périmètre des secteurs soumis à des obligations de cybersécurité renforcées, sans toutefois cibler directement les produits logiciels eux-mêmes.
Le CRA comble ce vide en s’attaquant au produit plutôt qu’à l’opérateur qui l’exploite. C’est une bascule de philosophie réglementaire : NIS2 responsabilise les entités qui utilisent des systèmes numériques critiques, le CRA responsabilise ceux qui les fabriquent et les vendent. C5:2026, en intégrant un domaine conteneurs et en s’alignant sur EUCS, vient combler l’interstice entre les deux logiques côté fournisseurs cloud, dont l’infrastructure sous-jacente (registres, orchestrateurs, runtimes) échappait jusqu’ici à un cadre d’audit aussi précis.
Impact concret sur les équipes DevOps et les RSSI
Pour une équipe DevOps qui construit des images de conteneurs distribuées en Europe, la checklist de conformité CRA se résume à quelques chantiers concrets mais lourds à mettre en place à l’échelle d’un catalogue entier de produits. D’abord, générer une SBOM machine-readable pour chaque image publiée, en couvrant au minimum les dépendances directes, idéalement l’ensemble de l’arbre de dépendances transitives. Ensuite, signer systématiquement les images avec un outil comme Cosign avant tout déploiement, pour disposer d’une preuve de provenance vérifiable par un auditeur, un régulateur ou un client. Puis mettre en place une quarantaine automatique pour toute image contenant une CVE critique non corrigée, avec un processus de rotation régulière des tokens d’accès aux registres.
S’ajoute à cela une contrainte organisationnelle plus difficile à automatiser : la capacité à détecter une vulnérabilité activement exploitée et à la signaler à l’ENISA et au CSIRT national compétent dans un délai de 24 heures. Cela suppose une astreinte de sécurité opérationnelle, un canal de signalement documenté, et une chaîne de décision claire entre équipes techniques et juridiques, un dispositif qu’une bonne partie des PME interrogées par l’ENISA n’a pas encore mis en place selon l’enquête de février-mars 2026.
# Exemple de génération de SBOM avec Docker Scout
docker scout sbom --format spdx monimage:tag > sbom.spdx.json
# Signature de l'image avec Cosign (Sigstore)
cosign sign --yes monregistre.io/monimage:tag
# Vérification de la provenance avant déploiement
cosign verify monregistre.io/monimage:tag \
--certificate-identity-regexp "https://github.com/monorg/.*" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com"Impact sur le marché : consolidation attendue côté éditeurs
La convergence CRA/C5:2026 crée un effet d’entonnoir sur le marché des outils de conformité cloud-native. Les éditeurs capables de couvrir à la fois la génération de SBOM, la signature d’artefacts et le monitoring runtime dans une seule plateforme prennent un avantage commercial net face aux outils ponctuels. C’est explicitement la stratégie affichée par Anchore avec sa version 6, et celle qu’a suivie Aqua Security en pivotant vers le runtime tout en conservant Trivy comme brique de scan. Le rachat de Wiz par Google, même s’il dépasse largement le cadre du CRA, confirme que les grands fournisseurs cloud considèrent désormais la sécurité cloud-native comme un axe d’acquisition prioritaire plutôt qu’un simple module additionnel.
Pour les entreprises françaises et européennes de taille intermédiaire, cette consolidation pose un dilemme budgétaire. Investir dans une plateforme unifiée coûte plus cher à court terme qu’un empilement d’outils open source, mais réduit le risque de trous de conformité entre deux outils mal intégrés, un risque que les auditeurs C5:2026 et les autorités CRA ne manqueront pas de pointer du doigt lors des premiers contrôles.
Cinq prédictions pour la suite
- Les premiers signalements d’incident sous 24 heures au titre de l’article 14 vont commencer à remonter à l’ENISA dès la mi-septembre 2026, révélant probablement un volume plus élevé que prévu de vulnérabilités actives dans des images de conteneurs anciennes, jamais reconstruites depuis leur publication initiale.
- Les cabinets de conseil en conformité et les éditeurs de SBOM vont connaître une accélération commerciale nette au dernier trimestre 2026, à mesure que les organisations en retard cherchent une solution rapide plutôt qu’une refonte complète de leur pipeline CI/CD.
- Le nombre d’organisations Type-1 encore sous C5:2020 va se réduire fortement à l’approche du 1er juin 2027, avec une vague de re-certifications concentrée sur le premier trimestre 2027 plutôt qu’étalée dans le temps.
- Les premières amendes CRA, quand elles tomberont après décembre 2027, viseront probablement en priorité des cas emblématiques de non-signalement plutôt que des manquements techniques mineurs sur la SBOM, pour marquer les esprits dès les premiers dossiers.
- D’autres États membres pourraient s’inspirer de la structure YAML machine-readable du C5:2026 pour leurs propres référentiels nationaux, dans une logique de convergence vers le futur schéma EUCS porté par l’ENISA.
Ce que cela change pour les équipes basées en France
Pour une entreprise française qui héberge ou distribue des produits logiciels comportant des composants conteneurisés, le CSIRT national compétent au sens de l’article 14 est en pratique le CERT-FR, rattaché à l’ANSSI. Les équipes sécurité doivent donc désormais intégrer ce canal de signalement dans leur procédure d’astreinte, aux côtés du signalement à l’ENISA. Sur le plan cloud, les fournisseurs qui visent le marché public français ou les secteurs régulés auront intérêt à surveiller de près l’alignement entre C5:2026 et les référentiels français existants, notamment SecNumCloud porté par l’ANSSI, dont la logique de qualification par niveaux de sensibilité des données recoupe en partie les nouveaux domaines du catalogue allemand.
La fenêtre qui reste avant le 11 septembre 2026 est courte pour toute organisation qui n’a pas encore engagé de chantier de génération de SBOM à l’échelle de son catalogue d’images. Les outils existent, la plupart sont open source ou proposent un palier gratuit suffisant pour démarrer, mais le temps d’intégration dans une chaîne CI/CD existante, avec tests et validation, se compte généralement en semaines plutôt qu’en jours.
Questions fréquentes
Le Cyber Resilience Act s’applique-t-il à tous les conteneurs Docker ?
Non. Le règlement vise les produits avec éléments numériques mis sur le marché de l’UE. Selon les analyses de vendeurs spécialisés comme RapidFort, les images de conteneurs, opérateurs Kubernetes et Helm charts entrent dans le périmètre lorsqu’ils bénéficient d’un support commercial et sont distribués à des clients européens, pas les projets purement internes sans commercialisation.
Quelle est la date limite exacte pour l’obligation de signalement ?
L’article 14 du règlement (UE) 2024/2847 s’applique à partir du 11 septembre 2026. À partir de cette date, tout signalement d’une vulnérabilité activement exploitée doit parvenir à l’ENISA et au CSIRT national compétent dans un délai de 24 heures après en avoir eu connaissance.
Qu’est-ce qui change concrètement entre C5:2020 et C5:2026 ?
Le nombre de critères passe de 121 à 168, toujours répartis en 17 domaines mais désormais découpés en sous-critères alignés sur le futur schéma européen EUCS. Un nouveau domaine couvre spécifiquement la gestion du cycle de vie des conteneurs, et le catalogue est pour la première fois publié en format YAML machine-readable.
Des amendes ont-elles déjà été prononcées au titre du CRA ?
Non, aucune sanction publique n’a été rapportée à la mi-août 2026. Les obligations de signalement ne deviennent contraignantes que le 11 septembre 2026, et l’application intégrale du texte, avec évaluation de conformité et marquage CE, n’intervient que le 11 décembre 2027.
Une SBOM suffit-elle à être conforme au CRA ?
Non. La SBOM est une exigence nécessaire mais pas suffisante. Le règlement impose aussi la sécurité dès la conception, un cycle de mises à jour de sécurité d’au moins cinq ans, une gestion active des vulnérabilités et, à partir de septembre 2026, un signalement rapide des incidents graves.
Les PME sont-elles concernées de la même façon que les grands éditeurs ?
Oui, le règlement ne prévoit pas d’exemption générale de taille pour les obligations essentielles, même si certaines mesures de soutien existent. L’enquête ENISA de février-mars 2026 montre justement que les micro-entreprises sont les moins avancées sur la gestion des incidents et du cycle de vie produit, ce qui les expose davantage au retard.
Faut-il attendre 2027 pour se préparer ?
Non. Même si l’application intégrale tombe en décembre 2027, l’obligation de signalement de septembre 2026 s’applique dès le premier jour à tous les produits déjà commercialisés, pas seulement aux nouvelles versions. Un produit vendu depuis plusieurs années et toujours en usage est concerné immédiatement.
Quels outils permettent de démarrer rapidement la mise en conformité ?
Docker Scout et Trivy couvrent la génération de SBOM et le scan de vulnérabilités avec un palier d’entrée accessible. Cosign, du projet Sigstore, permet de signer les images sans coût de licence. Pour une couverture plus complète intégrant reporting et suivi de cycle de vie, des plateformes comme Anchore Enterprise ou Aqua Platform ciblent explicitement les besoins de conformité CRA.
Related Coverage
- CRA : Code Non Signé, Amende de 2,5 % du CA [2026]
- Secrets Kubernetes : 12 Étapes, 90 Min [2026]
- Minikube : Kubernetes en Local en 12 Étapes, 30 Min [2026]
- DMA Cloud : l’UE Vise AWS et Azure d’Ici Novembre [2026]
- Europe : ENISA Bannit RSA Sous 3000 Bits en 2026
Pour plus d’analyses sur le cloud computing, consultez notre rubrique Cloud.
