Depuis le 11 septembre 2026, un éditeur qui découvre une vulnérabilité activement exploitée dans son produit a vingt-quatre heures pour la signaler. Ce n'est pas un délai de conformité. C'est un délai d'astreinte. Et il suppose une chose que la plupart des équipes ne savent pas faire : dire ce qu'il y a dans leurs images.
Ce qui a changé il y a une semaine
Le règlement européen sur la cyberrésilience — le Cyber Resilience Act — est publié depuis décembre 2024, mais il s'appliquait par étapes. La première vient de tomber. Depuis le 11 septembre 2026, les obligations de signalement sont actives :
- 24 heures pour notifier à l'ENISA et à l'autorité nationale une vulnérabilité activement exploitée dans votre produit ;
- 72 heures pour un incident de sécurité grave ;
- et, en amont, un canal de signalement identifié — une adresse, un formulaire — que quelqu'un relève réellement.
Le reste arrive en décembre 2027 : marquage CE, absence de vulnérabilité connue exploitable, configuration sécurisée par défaut. Mais la partie qui mord tout de suite, c'est le délai.
Deux exclusions valent la peine d'être connues, parce qu'elles rassurent à tort. Le logiciel libre développé sans intention commerciale n'est pas concerné. Le SaaS pur non plus — tant qu'il ne pose rien chez le client. Dès qu'il y a un agent, un SDK, une image de conteneur livrée, ce composant rentre dans le périmètre.
Le problème n'est pas la loi. C'est l'inventaire.
Vingt-quatre heures pour signaler suppose de savoir, en vingt-quatre heures, si la faille qui vient de sortir vous concerne. Donc de connaître le contenu exact de ce que vous livrez. Pas l'application : l'image, avec sa distribution de base, ses bibliothèques système, ses dépendances transitives.
Un scan sur une image d'API tout à fait ordinaire donne ceci :
Six paquets, dont deux critiques, et pas une seule ligne de votre code applicatif. Ce sont la base et ses dépendances. C'est la partie que personne ne regarde parce que personne ne l'a écrite — et c'est précisément celle sur laquelle le règlement vous interroge.
Et le jour où vous corrigez, ça casse
Voilà ce que les articles de conformité ne racontent jamais. Corriger n'est pas une formalité.
Cas vécu, et pas une fois : un scan sort deux vulnérabilités hautes et plusieurs critiques sur l'image d'une API Python. On applique les montées de version recommandées par l'outil. Le scan repasse au vert. Et le service ne démarre plus.
La version corrigée du serveur applicatif exigeait une version du framework web incompatible avec celle du projet. Il a fallu plusieurs itérations pour trouver un jeu de versions qui ferme les failles et laisse le service démarrer. C'est, de l'aveu des ingénieurs qui l'ont vécu, la partie la plus formatrice et la plus chronophage de tout l'exercice.
Retenez la séquence, parce qu'elle est contre-intuitive : le rapport de scan n'est pas une liste de tâches. C'est une liste d'arbitrages. Monter openssl ne coûte rien. Monter le serveur applicatif peut coûter une soirée. Et une correction qui casse la production est une correction qui ne sera pas déployée — donc une faille qui reste ouverte.
Le réflexe qui manque presque toujours : avant de monter une version, savoir si le composant est atteignable dans votre contexte. Une bibliothèque de parsing XML critique n'est pas un risque si votre service ne parse jamais de XML. Trier par atteignabilité avant de trier par sévérité, c'est ce qui transforme quarante corrections en trois.
Ce qui réduit vraiment le problème
La bonne nouvelle, c'est que la majorité de ces vulnérabilités ne devraient pas être là. Elles arrivent par le compilateur, les en-têtes de développement, le cache du gestionnaire de paquets et le shell complet qu'on a laissés dans l'image finale parce que personne n'a séparé la construction de l'exécution.
Même application, même code. Ce qui change, c'est ce qu'on a laissé entrer. Et cette réduction-là n'est pas un gain de confort : c'est directement l'exigence de « sécurité par conception » que le règlement rendra opposable en décembre 2027.
Une phrase que je répète à chaque cohorte : plus une image est légère, moins elle contient de binaires ; moins elle contient de binaires, moins elle offre de surface d'attaque. Le poids n'est pas l'objectif. Il est le symptôme mesurable de l'objectif.
Ce qu'on peut mettre en place ce mois-ci
Sans grand programme, sans budget, dans l'ordre :
- Produire un SBOM à chaque construction et l'archiver comme artefact de pipeline. Le jour où une faille sort, la question « est-ce que ça nous concerne » devient une recherche de trente secondes au lieu d'une réunion.
- Scanner en CI, et décider du seuil de blocage. Un scan qui n'échoue jamais ne sert à rien ; un scan qui échoue sur tout sera désactivé en deux semaines. Commencez par bloquer sur critique, et seulement sur les composants atteignables.
- Séparer la construction de l'exécution dans vos images. C'est le geste qui a le meilleur rapport effort / vulnérabilités supprimées.
- Écrire le canal de signalement et désigner qui le relève. Vingt-quatre heures, c'est un dimanche soir aussi.
- Rejouer une montée de version en conditions réelles avant d'en avoir besoin. Le jour de l'incident n'est pas le jour où l'on découvre que le correctif casse.
Le fond du sujet
Le règlement ne demande rien d'exotique. Il demande de savoir ce qu'on livre, de pouvoir le corriger, et de savoir le dire vite. Trois choses qui relèvent de la pratique quotidienne, pas du juridique.
Ce qui coince, ce n'est jamais le texte. C'est qu'on découvre, le jour où il faut corriger, qu'on ne maîtrisait pas la couche en dessous : ce que contient l'image de base, pourquoi cette dépendance est là, ce qui casse quand on la déplace. C'est toujours le concept d'en dessous.