Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Depuis le 11 septembre 2026, l'article 14 de la CRA vous oblige à signaler, dans les 24 heures suivant la constatation de l'existence d'une vulnérabilité activement exploitée dans votre produit.
- Une SBOM de niveau supérieur, correspondant au minimum requis par l'annexe I, ne permettra pas de repérer un paquet situé plusieurs niveaux plus bas ; en revanche, un inventaire au niveau de la version de chaque version livrée le permettra.
- Une version rétroportée compatible de celle que vous utilisez déjà corrige une dépendance cachée sans modifier tout ce qui se trouve en amont.
- La période de prise en charge par la CRA s'étend au-delà de la maintenance en amont ; chaque version de paquet doit donc disposer d'un parcours de correctifs qui se poursuive après la fin de vie de la version en amont.
Un mardi, une nouvelle entrée apparaît dans le catalogue KEV de la CISA. Elle signale une vulnérabilité activement exploitée dans un paquet que personne de votre équipe n’a choisi, situé trois niveaux plus bas dans une arborescence de dépendances que personne n’a constituée intentionnellement. Dans les 24 heures, un membre de votre entreprise doit déterminer si ce paquet figure dans une version que vous avez déployée et s’il convient d’en informer votre CSIRT et l’ENISA.
Voici à quoi ressemble l'article 14 de la loi européenne sur la cyber-résilience (CRA) vu de l'intérieur. Les délais sont courts et le seuil de déclenchement est plus restrictif que ne le laissent entendre la plupart des résumés, mais ce qui pose problème, c'est rarement la déclaration en elle-même. Le véritable défi consiste à déterminer ce que contient réellement la version en cours de développement alors que le temps presse.
Le compte à rebours de 24 heures de la CRA a commencé
Depuis le 11 septembre 2026, l'article 14 de la CRA est en vigueur. Il s'agit de la première obligation de déclaration prévue par la CRA qui s'applique aux fabricants, et elle est soumise à un délai strict. Dès que vous constatez qu'une vulnérabilité de votre produit fait l'objet d'une exploitation active, vous disposez de 24 heures.
L'Autorité européenne de protection des données (CRA) entend par « fabricant » toute organisation ou personne qui développe un produit comportant des éléments numériques, ou qui le fait développer, et qui le commercialise sur le marché de l'UE sous son propre nom ou sa propre marque dans le cadre d'une activité commerciale. Une activité commerciale ne se limite pas à la facturation d’un prix. Une assistance payante est prise en compte lorsqu’elle ne se limite pas à la simple récupération de vos coûts réels. Il en va de même pour la monétisation via une plateforme, ou le fait d’exiger des utilisateurs qu’ils fournissent des données à caractère personnel pour des raisons autres que l’amélioration de la sécurité, de la compatibilité ou de l’interopérabilité du logiciel. Si tel est le cas de votre entreprise et que votre produit est distribué en open source, l’article 14 vous concerne déjà.
L'article 14 fixe trois délais de déclaration. Chaque déclaration est transmise, via la plateforme unique de déclaration de l'ENISA, au CSIRT désigné comme coordinateur (il s'agit généralement de celui de votre établissement principal) ainsi qu'à l'ENISA elle-même, l'agence de cybersécurité de l'Union européenne.
La première est la notification d’alerte précoce dans les 24 heures. Dans les 72 heures, vous envoyez une notification de vulnérabilité plus complète. Au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation – terme utilisé par la CRA pour désigner un correctif ou une solution de contournement –, vous envoyez un rapport final. Les délais de 24 et 72 heures constituent des délais maximaux et non des périodes d’attente. Le texte précise « sans retard injustifié et, en tout état de cause, dans les limites » de ces délais.
L’expression « activement exploitée » a une signification précise. Il doit exister des preuves fiables indiquant qu’un acteur malveillant a exploité la vulnérabilité d’un système sans l’autorisation de son propriétaire. La publication d’un CVE ne suffit pas. Une preuve de concept ne suffit pas non plus. L’article 14 couvre également les incidents graves ayant un impact sur la sécurité d’un produit. Ceux-ci font l’objet d’une procédure distincte, avec un rapport final à remettre un mois après la notification de l’incident. Cet article porte sur les vulnérabilités et sur l’aspect « dépendances open source » de la CRA. L’évaluation des risques, l’évaluation de la conformité et les autres obligations du fabricant ne relèvent pas de son champ d’application.
La date limite fixée par l'Agence canadienne du revenu (ARC) pour la mise en conformité avec les obligations restantes des fabricants, ainsi que pour les amendes, est le 11 décembre 2027. L'article 14 est déjà en vigueur et s'applique aux produits mis sur le marché de l'UE avant cette date.
Références : article 14, paragraphes 1, 2, 4 et 7 ; article 3, paragraphes 13 et 42 ; article 64 ; article 71, paragraphe 2 ; article 69, paragraphe 3 ; considérants 15 et 18.
Pourquoi une SBOM de haut niveau ne permet pas de savoir si vous êtes concerné
Les informations indiquant qu’une vulnérabilité est exploitée vous parviennent généralement de l’extérieur : une entrée dans le catalogue « Known Exploited Vulnerabilities » (KEV) de la CISA, un avis émis par un éditeur ou un responsable de maintenance, ou encore un message provenant d’un CSIRT, d’un chercheur ou d’un client. À partir de là, trois choses se produisent. Vous apprenez qu’une vulnérabilité est exploitée quelque part. Vous vérifiez si votre produit est concerné. Puis vous identifiez les versions et les utilisateurs concernés.
Le compte à rebours commence dès que vous prenez connaissance d’une vulnérabilité activement exploitée dans votre produit ; vous devez donc commencer immédiatement à évaluer les alertes crédibles. Le fait qu’un nom de paquet corresponde ne signifie pas en soi que votre produit est concerné, et c’est grâce à un inventaire précis que vous pourrez le déterminer rapidement. Dans la pratique, ces étapes se chevauchent, et vous n’attendez pas de disposer d’une liste complète des utilisateurs pour envoyer une alerte précoce à l’approche de la date limite.
Le paquet mentionné dans l'alerte est souvent une dépendance transitive, intégrée par l'une de vos dépendances directes, et qui n'a été choisie par aucun membre de votre équipe. Log4Shell (CVE-2021-44228) C'est le cas que l'on connaît bien. log4j-core Il était présent dans de nombreuses applications en tant que dépendance de frameworks et de connecteurs, et la première tâche de la plupart des équipes consistait à vérifier s’ils en disposaient.
C'est là qu'intervient l'exigence de l'Agence canadienne du revenu (ARC) en matière d'inventaire. L'annexe I impose aux fabricants d'identifier et de documenter les composants d'un produit, notamment en établissant une nomenclature logicielle (SBOM) dans un format couramment utilisé et lisible par machine. Le niveau de détail minimal requis correspond « au minimum aux dépendances de premier niveau ». Ce seuil est raisonnable. Il n'est toutefois pas suffisant pour répondre à la question des 24 heures.
Une SBOM de niveau supérieur répertorie directement ce que vous avez ajouté. La question qui se pose est de savoir si une version spécifique d'un paquet donné apparaît quelque part dans le produit, et il y a trois endroits à vérifier.
Votre manifeste, qu'il s'agisse de package.json, pom.xmlou requirements.txt, répertorie les dépendances que vous avez déclarées, souvent sous forme de plages de versions. Votre fichier de verrouillage enregistre le graphe des dépendances résolu pour une compilation ; toutefois, le contenu final livré peut encore varier en raison des dépendances spécifiques à la plate-forme et facultatives, des outils de compilation, du « vendoring » et de toute régénération du fichier de verrouillage au cours du processus. Votre inventaire de version indique ce que contient l'artefact livré : les versions des composants résolues, tout ce qui est intégré ou « vendoré » dans l'artefact, et aucune des dépendances de développement qui ne quittent jamais votre environnement de compilation.
Le fichier de verrouillage est une donnée indispensable, mais il ne permet pas de déterminer ce qui a été livré. Pour savoir si la vulnérabilité signalée se trouve dans une version particulière, il faut disposer de l'inventaire des versions.
Il y a toutefois un autre problème pour tout ce qui a dépassé sa fin de vie en amont. Lorsqu’une vulnérabilité est corrigée, l’avis indique généralement quelque chose comme « corrigé dans la version 4.2, les branches plus anciennes ne sont plus prises en charge ». La version 3.x de votre arborescence peut très bien être concernée, mais l’équipe en amont ne le précisera peut-être jamais, car personne là-bas ne s’occupe plus de cette branche. C’est à vous qu’il revient de l’analyser.
Références : article 14, paragraphe 1 ; article 3, point 42 ; annexe I, partie II, point 1.
Pourquoi l'argument « nous ne savions pas » ne vous protège pas
Le délai prévu à l’article 14 ne commence à courir qu’à partir du moment où vous avez connaissance d’une vulnérabilité activement exploitée présente dans votre produit. Il s’agit là d’une limitation stricte, fondée sur un seul critère déclencheur, qui ne tient aucunement compte du reste de la CRA.
À compter du 11 décembre 2027, les obligations plus étendues prévues par la CRA s'appliqueront. Pour les produits mis sur le marché avant cette date, les règles transitoires prévoient leur intégration dès lors que le produit subit une modification substantielle à compter de cette date. Ces obligations vous imposent d’identifier et de documenter les composants et les vulnérabilités de votre produit, ainsi que de mener des tests et des contrôles de sécurité efficaces et réguliers. Elles exigent que vous fassiez preuve de diligence raisonnable lorsque vous intégrez des composants tiers, y compris ceux issus de l’open source. Elles vous imposent également de gérer efficacement les vulnérabilités du produit, « y compris celles de ses composants », pendant toute la durée de son support.
Le fait qu’un composant ait échappé à votre processus de contrôle ne prouve pas, en soi, que votre processus présente des lacunes. Cela peut toutefois inciter une autorité à examiner si votre identification des composants et votre gestion des vulnérabilités sont adéquates. Ces obligations relèvent de la tranche d’amendes la plus élevée de la CRA, qui peut atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total de votre entreprise pour l’exercice financier précédent, le montant le plus élevé étant retenu. Les autorités de surveillance du marché peuvent également ordonner des mesures correctives, restreindre ou interdire les ventes, ou exiger un retrait ou un rappel.
La date d'entrée en vigueur est encore loin. La prochaine alerte, en revanche, ne le sera pas. Si votre outil a omis un paquet, les premières heures d'une fenêtre de 24 heures sont consacrées à déterminer si ce paquet figure bien dans votre pile, ce qui laisse beaucoup moins de temps pour tout le reste que le rapport exige.
Références : annexe I, partie II, points 1 et 3 ; article 13, paragraphes 5 et 8 ; article 54 ; article 64, paragraphe 2 ; article 69, paragraphe 2.
Maintenant, corrige ça sans tout gâcher en amont
La notification dans les 72 heures vous demande de fournir les informations dont vous disposez à ce stade : des informations générales sur le produit, la nature générale de l’exploitation et de la vulnérabilité, les mesures correctives ou d’atténuation que vous avez prises, ainsi que les mesures que vos utilisateurs peuvent prendre. Il n’est pas nécessaire de disposer d’un correctif finalisé pour effectuer cette notification. Toutefois, dans le cas d’une dépendance transitive à trois niveaux en aval, il faut tout de même consacrer des efforts à la mise au point de ces mesures.
Prenons le cas de figure classique. Le correctif existe en amont, dans la version 4.2. Le paquet intermédiaire de votre arborescence est bloqué sur la branche 3.x, et son responsable n’a pas encore effectué la mise à jour. Aucune de vos options n’est sans conséquence. Vous pouvez attendre que le responsable agisse. Vous pouvez forcer une dérogation dans votre fichier de verrouillage et accepter le risque que quelque chose en amont cesse de fonctionner. Vous pouvez faire passer le paquet intermédiaire à une version majeure prenant en charge la 4.2, et intégrer les modifications sans rapport qui l’accompagnent dans une version de sécurité. Vous pouvez remplacer le composant, ou l’améliorer vous-même. Ou encore, vous pouvez obtenir un backport compatible, c’est-à-dire le correctif de sécurité appliqué à la branche 3.x que vous utilisez déjà.
À compter de décembre 2027, l’annexe I impose deux exigences à cet égard. Vous devez traiter et corriger les vulnérabilités sans délai. Et lorsque cela est techniquement possible, vous devez diffuser les mises à jour de sécurité séparément des mises à jour de fonctionnalités. La CRA ne prescrit pas la méthode à adopter. Elle vous autorise également à ne fournir la mise à jour de sécurité que pour votre dernière version, à condition que les utilisateurs des versions antérieures puissent passer gratuitement à celle-ci et n’aient pas à supporter de coûts supplémentaires pour adapter leur environnement.
Un backport compatible respecte cette séparation et limite l'effort de migration. Il s'agit d'une version figée de la version déjà présente dans votre arborescence, compatible avec ses dépendances, les paquets dépendants étant recompilés si nécessaire. Lorsque cela est effectué correctement, vos propres manifestes ne sont pas modifiés et les tests de compatibilité ne sont effectués qu'une seule fois dans votre produit.
Lorsqu’un backport est assorti d’une date de livraison ferme, vous disposez d’un calendrier de correction précis à communiquer parallèlement aux mesures que vous avez déjà prises. Le reste vous incombe : intégrer le composant corrigé, le tester et le publier sous forme de mise à jour de votre produit. Plus le composant arrive tôt, plus vous disposez de temps pour effectuer ces opérations.
Références : article 14, paragraphe 2, point b) ; annexe I, partie II, point 2 ; article 13, paragraphe 10 ; article 69, paragraphe 2.
Le rapport final est établi après la mise en place de la solution, et cette obligation s'étend sur plusieurs années.
Le rapport final doit être remis au plus tard 14 jours après la mise à disposition d'une mesure corrective ou d'atténuation. Il décrit la vulnérabilité, sa gravité et son impact, les informations disponibles concernant l'attaquant, ainsi que la mise à jour de sécurité ou les autres mesures que vous avez mises en place.
Par ailleurs, dès que vous avez connaissance de la vulnérabilité, vous devez en informer les utilisateurs concernés et, le cas échéant, l’ensemble des utilisateurs. L’avis doit leur indiquer les mesures à prendre pour atténuer ou résoudre le problème. Le cas échéant, il est diffusé dans un format structuré et lisible par machine. La CRA n’en prescrit aucun en particulier. Le format CSAF est le format d’avis lisible par machine le plus largement utilisé, et les déclarations VEX, qui indiquent si une vulnérabilité affecte un produit particulier, peuvent être exprimées sous la forme CSAF VEX, CycloneDX VEX ou OpenVEX.
À compter de décembre 2027, la mise à jour elle-même devra également être diffusée de manière sécurisée, sans délai et gratuitement.
Vient ensuite la « longue traîne », où la logique mathématique de l'open source cesse de jouer en votre faveur.
Pendant toute la durée de votre période de support, vous devez continuer à corriger les vulnérabilités du produit. C'est vous qui fixez la durée de la période de support, mais celle-ci doit refléter la durée d'utilisation prévue du produit et être d'au moins 5 ans, sauf si le produit est destiné à être utilisé pendant une durée inférieure. De plus, chaque mise à jour de sécurité que vous publiez pendant la période de support doit rester disponible pendant au moins 10 ans après sa publication, ou jusqu'à la fin de la période de support, la date la plus tardive prévalant, afin qu'un utilisateur qui effectue la mise à jour tardivement puisse encore en bénéficier.
La maintenance en amont d’une version de paquet peut prendre fin bien avant l’expiration de votre période de support. Lorsque cela se produit, la CRA vous tient toujours pour responsable jusqu’à la fin de cette période. Vous n’êtes pas tenu de conserver cette version précise, car le remplacement ou la mise à niveau d’un composant peut constituer une solution légitime. Vous êtes tenu de continuer à corriger les vulnérabilités de votre produit, par tous les moyens nécessaires, pendant toute la durée de la période de support.
Références : article 14, paragraphe 2, point c), et paragraphe 8 ; annexe I, partie II, points 7 et 8 ; article 13, paragraphes 8 et 9 ; article 69, paragraphe 2.
Personne en amont ne partage votre horloge
L'Agence des impôts (CRA) veille délibérément à ce que les logiciels libres et open source développés ou fournis en dehors d'une activité commerciale ne soient pas soumis aux obligations imposées aux fabricants.
Elle crée une catégorie distincte, celle des « responsables de logiciels libres », destinée aux personnes morales qui apportent un soutien durable au développement de logiciels libres destinés à des activités commerciales. Les responsables bénéficient d’un régime allégé et sur mesure qui s’appliquera à partir de décembre 2027, avec des obligations limitées au titre de l’article 14 dans des circonstances bien définies. Les contributeurs individuels au sein d’une communauté ne sont pas automatiquement considérés comme des fabricants ou des responsables.
Quelles que soient leurs obligations et leurs engagements en matière d’assistance, ceux-ci sont distincts des vôtres et ne vous dispensent pas des vôtres. L’article 13, paragraphe 6, le précise clairement. Lorsque vous identifiez une vulnérabilité dans un composant que vous commercialisez, vous devez la signaler à la personne ou à l’entité qui fabrique ou assure la maintenance de ce composant, y remédier dans votre produit, qu’elle réponde ou non, et partager le code ou la documentation pertinente si vous avez développé un correctif. Vous pouvez corriger, remplacer ou mettre à niveau le composant. Ce que vous ne pouvez pas faire, c’est laisser l’inaction en amont justifier un retard dans votre propre réaction.
Ces obligations prévues à l'article 13 s'appliquent à compter du 11 décembre 2027. La leçon opérationnelle s'applique dès maintenant. Même si le code se trouve profondément enfoui dans votre arborescence, que vous ne l'avez pas écrit et que vous ne l'avez peut-être jamais lu, c'est toujours à vous qu'il incombe de corriger la vulnérabilité de votre produit, même si les développeurs en amont ne vous aident pas.
Références : article 24 ; article 3, paragraphe 14 ; article 13, paragraphe 6 ; article 69, paragraphe 2 ; considérants 18 et 19.
En quoi une réponse viable est-elle liée à cela ?
L'ARC vous laisse la liberté de choisir la manière dont vous souhaitez vous conformer aux dispositions de l'article 14. Vous trouverez ci-dessous un ensemble de recommandations pratiques concernant les composants open source intégrés à votre produit. Celles-ci revêtent une importance particulière lorsque le maintien de la compatibilité des versions existantes vous évite un travail de migration.
Commencez par dresser un inventaire, au niveau de chaque version, de tous les éléments composant le produit, jusqu’à la moindre dépendance transitive, en les répertoriant sous forme de versions validées et en les mettant en correspondance avec ce que chaque version du produit contient réellement. La question « en 24 heures » trouve alors sa réponse dans ces enregistrements plutôt que dans une analyse que vous auriez lancée après la réception de l’alerte.
Ensuite, vous avez besoin de correctifs qui arrivent à temps, y compris des rétroportages compatibles pour les versions déjà présentes dans votre arborescence où une mise à niveau n’est pas envisageable, avec les paquets dépendants recompilés si nécessaire. Les modifications de sécurité peuvent alors être distribuées séparément des modifications fonctionnelles, et le travail de migration reste limité. Ce processus de correction doit également se poursuivre après la fin de vie d’un paquet en amont, pendant toute la durée de votre période de support plutôt qu’en fonction de l’intérêt du responsable du paquet.
Les deux derniers points concernent ce qui sort de votre entreprise. Les utilisateurs concernés doivent être informés rapidement, dans des formats lisibles par machine le cas échéant, et bénéficier de mises à jour de sécurité qui restent disponibles pendant au moins 10 ans après leur publication, ou jusqu'à la fin de la période de support si celle-ci est plus longue. Vous devez également garantir une couverture équivalente dans tous les écosystèmes linguistiques de votre produit, car l'article 14 ne tient pas compte de l'origine d'un composant.
La plupart des autres obligations incombant aux fabricants, ainsi que les mesures d'application qui en découlent, s'appliqueront à compter du 11 décembre 2027. L'obligation de déclaration est déjà en vigueur. Les mois qui nous séparent de cette date seront l'occasion de mettre en place les moyens nécessaires.
Le rôle de SecureChain et du support tout au long du cycle de vie
SecureChain et le service « Endless Lifecycle Support » (ELS) de TuxCare s'appuient sur ces fonctionnalités, dans le même ordre.
Commençons par l’inventaire. Les paquets open source sont intégrés à votre produit via le catalogue SecureChain, qui assure le suivi des versions des paquets qu’il gère et publie pour chacun d’entre eux des SBOM lisibles par machine, y compris pour CycloneDX, avec les détails des dépendances en annexe. Il s’agit là de la partie « composants » de votre inventaire de versions. Vous le reliez à vos enregistrements de compilation et aux artefacts livrés ; à partir de là, déterminer si le composant concerné est présent relève d’une simple recherche plutôt que d’une recherche effrénée. Lorsqu’une vulnérabilité est confirmée, TuxCare publie les données relatives à cette vulnérabilité afin que vous puissiez les recouper avec les versions des paquets figurant dans cet inventaire.
Ensuite, les correctifs. Tant que le développeur en amont continue de les diffuser, SecureChain les recompile à partir du code source et fournit des remplacements prêts à l'emploi pour les versions prises en charge des paquets que vous utilisez déjà. Lorsque le développeur en amont cesse de fournir des mises à jour, SecureChain applique lui-même les correctifs au paquet et en assure la compatibilité. Lorsqu’une dépendance cachée est corrigée, les paquets qui en dépendent sont recompilés en tenant compte de ce correctif, ce qui évite d’avoir à modifier vos propres manifestes. L’application des correctifs respecte les délais de réponse cibles publiés en fonction du niveau de gravité, tels que définis dans la fiche technique sur la couverture du cycle de vie. Cela vous donne un calendrier concret à communiquer lors de votre notification sous 72 heures, en plus des mesures déjà prises et des mesures d’atténuation mises à la disposition de vos utilisateurs. L’intégration, les tests et la publication de la mise à jour sous votre propre nom restent à votre charge.
Vient ensuite la phase où le développeur en amont cesse d’intervenir. Lorsque celui-ci arrête de corriger une version, que ce soit parce qu’il n’a pas respecté la date limite fixée par le CVE ou parce qu’il n’a pas publié de nouvelle version depuis neuf mois, SecureChain continue d’y appliquer des correctifs pendant trois mois supplémentaires. Passé ce délai, le service « Endless Lifecycle Support » prend le relais et assure le portage des correctifs tant que vous utilisez cette version, c’est-à-dire aussi longtemps que l’exige votre propre période de support.
Les avis de sécurité et les mises à jour sont publiés via le portail de sécurité de TuxCare sous forme de documents CSAF et VEX, accompagnés de flux RSS et de métadonnées signées, prêts à être associés à vos propres versions concernées et à vos notifications aux utilisateurs. TuxCare est également une autorité de numérotation CVE (CNA); elle peut donc attribuer des identifiants CVE aux vulnérabilités relevant de sa compétence et les publier dans ses propres avis de sécurité, sans avoir à passer par l'intermédiaire d'un tiers.
Ce modèle couvre JavaScript, Python, Java, Go, Rust et PHP. Un seul catalogue, un seul modèle SBOM, un seul modèle de correction, quel que soit l’écosystème d’origine d’un paquet.
TuxCare est un fabricant à part entière au sens du règlement CRA pour les produits qu’il met sur le marché de l’UE ; il est donc soumis aux mêmes obligations prévues à l’article 14, ainsi qu’à l’obligation prévue à l’article 13, paragraphe 6, de signaler en amont les vulnérabilités des composants et de partager les correctifs. Ce que ces deux produits changent pour vous, c’est la durée du délai entre une alerte et la publication d’une version corrigée qui est consacrée à attendre la correction d’un composant par un tiers, ainsi que la qualité du rapport que vous pouvez soumettre pendant que le temps presse.
Avant la prochaine alerte
Vous pouvez tester la plupart de ces éléments en un après-midi. Prenez une version actuelle et une alerte, réelle ou fictive. Log4Shell fera l’affaire si vous avez été concerné. Sinon, imaginez une entrée KEV pour une bibliothèque située trois niveaux plus bas dans votre arborescence. Suivez ensuite le parcours que l’alerte emprunterait au sein de votre entreprise et répondez à chaque question en vous basant sur la dernière fois où cela s’est réellement produit, ou en utilisant une estimation réaliste si cela ne s’est jamais produit auparavant.
Votre inventaire des versions indique-t-il si le paquet figure dans cette version ? D'où proviendrait le correctif, et quelqu'un s'est-il engagé sur une date pour sa mise en place ? Combien de temps a pris votre dernière mise à jour de sécurité, entre le correctif du composant et la publication de la mise à jour ? Comment vos utilisateurs en seraient-ils informés ? Chaque fois que vous n'avez pas de réponse, c'est là que la prochaine alerte trouvera en premier une faille.
Au sein de votre entreprise, une personne est chargée de gérer la situation pendant les 24 heures qui suivent la réception de cette alerte. L'exercice vous permet de déterminer si cette personne est en mesure de déterminer à temps si l'article 14 s'applique et, le cas échéant, de le mettre en œuvre.
