Cyber Resilience Act et délai de signalement : comment s'y préparer

À compter du 11 septembre 2026, de nombreuses entreprises qui commercialisent des logiciels sur le marché de l'Union européenne (UE) disposeront de 24 heures pour faire un rapport dès qu'elles auront connaissance de l'exploitation active d'une vulnérabilité dans l'un de leurs produits. Il s'agit d'une nouvelle obligation introduite par le Cyber Resilience Act (CRA), la législation européenne qui définit les exigences en matière de cybersécurité applicables aux produits comportant des éléments numériques vendus en Europe. Son objectif : garantir que ces produits sont sécurisés dès leur conception et protégés contre les nouvelles menaces. Les exigences les plus strictes du règlement sur la cyberrésilience (CRA) s'appliquent aux fabricants de ces produits, qu'il s'agisse de grands éditeurs de logiciels ou d'entreprises qui commercialisent du matériel connecté.

Le véritable défi pour rester en conformité ne réside pas dans le dépôt du rapport lui-même, mais dans la rapidité avec laquelle une entreprise peut détecter qu'une vulnérabilité présente dans un produit qu'elle a livré est activement exploitée dans sa chaîne d'approvisionnement logicielle. Le délai de 24 heures commence à courir dès l'instant où vous en avez connaissance, c'est pourquoi la détection est si déterminante. Une détection continue relève d'une démarche d'ingénierie plutôt que d'une simple mesure ponctuelle de conformité. Les capacités de sécurité de la chaîne d'approvisionnement logicielle de GitLab sont conçues pour vous aider à détecter automatiquement et en continu toute exploitation active au sein de ce que vous avez livré. Cet article passe en revue quatre questions que vous devriez vous poser dès aujourd'hui sur la solution de détection continue de votre pipeline CI/CD.

L'obligation de signalement entre en vigueur en septembre 2026

À compter du 11 septembre 2026, les fabricants sont tenus de signaler toute vulnérabilité activement exploitée dans les 24 heures suivant le moment où ils en ont connaissance. Ce signalement s'effectue en trois étapes, soumises simultanément à l'Agence de l'Union européenne pour la cybersécurité (ENISA) et à l'équipe de réponse aux incidents de sécurité informatique (CSIRT) désignée comme coordinatrice.

1. Alerte précoce, dans les 24 heures suivant la prise de connaissance de la vulnérabilité activement exploitée. Un premier signal indiquant qu'une exploitation est en cours. Vous n'êtes pas tenu de connaître l'étendue complète de l'impact ni la correction à apporter à ce stade.
2. Notification, dans les 72 heures. Un compte rendu plus complet, précisant ce qui est affecté, ce que vous savez jusqu'à présent et les mesures que vous prenez pour y remédier.
3. Rapport final. Pour une vulnérabilité activement exploitée, au plus tard 14 jours après la disponibilité d'une mesure corrective ou d'atténuation.

Quatre questions auxquelles GitLab peut vous aider à répondre

C'est à vous de décider si une vulnérabilité de votre produit doit être signalée. Voici quatre questions que vous pouvez vous poser dès aujourd'hui pour vous préparer au règlement sur la cyberrésilience (CRA), et la façon dont GitLab peut vous aider à y répondre.

Détecter l'exploitation active dans ce que vous avez déjà livré

Un composant présent dans un produit que j'ai livré est-il activement exploité en ce moment ?

L'analyse des dépendances en continu surveille votre SBOM et signale les avis nouvellement publiés qui le concernent. Le statut KEV et les scores EPSS associés à chaque résultat vous indiquent quelles vulnérabilités sont réellement utilisées par des attaquants, afin que vous puissiez prioriser celles qui présentent un risque réel. L'analyse des conteneurs couvre les images que vous livrez, et l'analyse des conteneurs en production couvre ce qui s'exécute actuellement dans vos clusters.

Identifier chaque produit et dépôt concerné

Lesquels de mes produits sont concernés, et dans quel dépôt ?

Une seule recherche dans la liste des dépendances au niveau du groupe renvoie tous les projets qui livrent ce composant. Les attributs de sécurité vous indiquent lesquels sont exposés sur Internet ou critiques pour l'activité, afin que vous sachiez par où commencer. Cette liste est alimentée par deux sources : un SBOM CycloneDX issu de l'analyse des dépendances pour ce que votre code déclare, y compris les dépendances transitives, et un autre issu de l'analyse des conteneurs pour les paquets du système d'exploitation intégrés à l'image. Une seule recherche couvre l'ensemble de votre chaîne d'approvisionnement logicielle, tout ce que vous avez réellement livré.

Documenter le moment où une vulnérabilité a été identifiée

Puis-je démontrer à quel moment j'en ai eu connaissance ?

Le journal d'activité de chaque vulnérabilité enregistre la date de détection, le pipeline concerné, ainsi que chaque changement de statut ultérieur avec le nom de la personne et l'horodatage. Le webhook des événements de vulnérabilité transmet ces mêmes informations au système qui gère votre chronologie. Lorsqu'on vous demande à quel moment vous avez été informé, la réponse est déjà consignée.

Prouver que le correctif a été livré, et à quelle date

Un correctif a-t-il été livré, et quand ?

La correction automatique de l'analyse des dépendances ouvre la merge request de mise à niveau à votre place. Les politiques d'approbation des merge requests peuvent conditionner l'approbation au statut d'exploitation connue, de sorte que la règle s'applique sans qu'il soit nécessaire de la remettre en question. Les frameworks de conformité définissent les contrôles sous-jacents à l'ensemble du dispositif, le rapport de statut de conformité suit la position de chaque projet par rapport à ces contrôles, et le rapport des violations de conformité signale tout ce qui aurait pu passer entre les mailles du filet.

Tout ce que vous utilisez déjà

Une grande partie des informations dont vous aurez besoin pour évaluer vos obligations de signalement au titre du règlement sur la cyberrésilience (CRA) se trouve déjà dans la plateforme de GitLab où réside votre code. L'inventaire, les signaux d'exploitation, la mise en correspondance continue, les horodatages et les contrôles de politique ne sont pas cinq outils à évaluer, acquérir et interconnecter. Ce sont des fonctionnalités que vous activez dans les pipelines que vous exécutez déjà, sans nouvel agent ni nouveau plan de données.

Les scans de sécurité de GitLab, notamment le test statique de sécurité des applications (SAST), la détection des secrets, la protection contre les push de secrets, l'analyse de l'Infrastructure as Code (IaC) et les politiques de sécurité de GitLab, ne sont peut-être pas indispensables pour répondre à ces questions. Elles peuvent toutefois contribuer à répondre aux exigences de la prochaine phase du règlement sur la cyberrésilience (CRA), qui entrera en vigueur en décembre 2027.

Perspectives : bloquez les paquets à risque avant qu'ils n'atteignent votre chaîne d'approvisionnement

Les capacités de sécurité de GitLab vous permettent de réagir rapidement. Il est également judicieux de configurer votre environnement de façon à réduire le nombre de vulnérabilités à signaler.

Tous les risques liés à la chaîne d'approvisionnement logicielle ne se manifestent pas sous la forme d'une entrée CVE (vulnérabilités ou expositions communes). Un paquet publié avec un seul caractère de différence par rapport à une bibliothèque que votre équipe utilise quotidiennement ne fait l'objet d'aucun avis ni d'aucun score de gravité. Il en va de même pour un nom de paquet inventé par un assistant d'IA et enregistré par quelqu'un d'autre. Il n'y a rien à corriger, car le paquet lui-même constitue l'attaque.

À l'avenir, GitLab vous permettra d'appliquer une politique préventive au niveau du registre plutôt que de détecter une vulnérabilité lors d'une revue trois semaines plus tard, afin d'empêcher les paquets malveillants d'entrer dans votre chaîne d'approvisionnement avant même d'atteindre un build. Pour obtenir des informations sur la version bêta fermée du Dependency Firewall, disponible prochainement, remplissez notre formulaire.

Pour les clients GitLab existants, testez-le sur un composant. Ouvrez votre liste de dépendances au niveau du groupe, choisissez un élément dont vous savez qu'il est intégré à un produit, et mesurez le temps qu'il vous faut pour répondre aux quatre questions. Si les réponses vous viennent rapidement, activez l'analyse des dépendances en continu et ajoutez le statut d'exploitation connue à une politique d'approbation des merge requests.

Si vous n'utilisez pas encore GitLab Ultimate, vérifiez en un seul coup d'œil si vos composants livrés comportent des vulnérabilités connues pour être exploitées dans la nature. Démarrez un essai gratuit.

Pour approfondir le sujet, consultez les ressources suivantes : la présentation du règlement sur la cyberrésilience (CRA) par la Commission européenne, sa page sur les obligations de signalement, le résumé du texte législatif et les orientations de mise en œuvre de la Commission.

Amit Shalem est Principal Product Manager, Software Supply Chain Security, chez GitLab.