Trouver est devenu bon marché. Le reste du cycle de vie, non. Un cycle de vie de gestion des vulnérabilités comporte les mêmes étapes, quel que soit le référentiel dont on le tire : recenser les candidats, apprécier lesquels sont réels et avec quelle gravité, décider du sort de chacun, corriger, vérifier la correction, notifier à qui une notification est due, et conserver le dossier. Selon notre lecture, l’étape coûteuse était autrefois la première. Aujourd’hui un scanner, un fuzzer, une plateforme de revue ou un assistant produit des candidats plus vite qu’aucune équipe ne peut les apprécier, et le cycle de vie rompt aux étapes suivantes, là où un candidat bien formulé doit devenir une décision que quelqu’un devra plus tard justifier.
Cette note parcourt les étapes, dit ce que le Cyber Resilience Act européen, le règlement (UE) 2024/2847, exige à chacune, et dit où se situe une revue adversariale indépendante. Son poids est dans les étapes qui suivent la première.
Recenser : là où nous ne vendons pas
Les candidats viennent de partout : analyse statique, outils de dépendances et de nomenclature logicielle, fuzzers, plateformes de revue, assistants, vos propres ingénieurs, et signalants extérieurs. Une revue adversariale produit elle aussi des candidats (les nôtres ont comporté des défauts corrigés par la suite en amont), mais trouver est ce qu’une mission rapporte en chemin, non ce sur quoi elle est tarifée. Une pratique positionnée ici concurrencerait votre scanner au volume.
Ce que le CRA exige ici. Le fabricant doit recenser et documenter les vulnérabilités et les composants du produit, notamment par l’établissement d’une nomenclature des logiciels (annexe I, partie II, point 1), et doit fournir une adresse de contact pour le signalement et faciliter le partage d’informations sur les vulnérabilités potentielles (annexe I, partie II, point 6). Ce sont les obligations du fabricant ; les constats d’un relecteur extérieur les alimentent et ne les acquittent pas.
Apprécier : de l’opinion bien formulée à l’échelon de preuve
C’est la première étape où le cycle de vie rompt, car tous les outils ci-dessus émettent des opinions sur le code avec la même aisance, que le chemin soit atteignable ou non. L’appréciation est l’étape où ces opinions sont soit tranchées, soit graduées. Notre règle est : l’oracle d’abord. Une affirmation décidable (ce chemin s’exécute-t-il, la spécification permet-elle cette valeur) va à ce qui peut y répondre, une exécution, un compilateur ou la spécification, avant que quiconque soit invité à donner un avis. Ce qui subsiste est gradué selon l’échelon de preuve réellement atteint (trace dans la source, preuve à la compilation, test, reproduction en conditions réelles, et pour toute affirmation probabiliste un taux avec son intervalle et les journaux de chaque essai), ou marqué plausible seulement. La gravité suit alors la preuve, non la confiance d’un modèle. Un constat n’est pas un verdict en est le traitement détaillé.
Ce que le CRA exige ici. Soumettre régulièrement le produit à des tests et examens de sécurité efficaces (annexe I, partie II, point 3), et, dans la documentation technique, les rapports des essais effectués pour vérifier la conformité du produit et des processus de gestion des vulnérabilités (annexe VII, point 6). Un rapport d’essais effectués est un rapport de ce qui a été examiné, comment, et ce qui a été établi, ce qu’un dossier gradué par la preuve est et qu’une liste classée par gravité n’est pas. Et pendant quelque temps encore ces rapports seront écrits avant que la norme harmonisée définissant « réguliers et efficaces » soit citable ; ils doivent donc tenir par leurs propres mérites : Les normes peuvent glisser, la date de notification non.
Décider : quand l’outil et l’équipe divergent
La deuxième rupture. Un outil signale une vulnérabilité critique ; l’ingénierie répond que le cadriciel l’atténue ; l’équipe sécurité n’a ni le temps de le prouver ni l’autorité de passer outre une échéance, et le ticket se ferme par épuisement. Nos règles de clôture sont celles de la page revue de code adversariale : un décompte n’établit jamais rien ; là où les relecteurs divergent sur ce que fait le code, la source tranche ; là où un rejet repose sur « incertain », l’affirmation part dans une file conservée avec un responsable, une échéance et un critère de réouverture, et elle est réexposée à une lignée fraîche. Cette file existe pour qu’incertain ne puisse pas être silencieusement converti en risque accepté. Ce qui tranche un constat traite la première de ces règles, y compris le cas où l’objet de la revue était notre propre outil.
Ce que le CRA exige ici. Le fabricant doit gérer et corriger les vulnérabilités sans retard, y compris par des mises à jour de sécurité (annexe I, partie II, point 2), et doit mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités (annexe I, partie II, point 5). Une décision de ne pas corriger est une décision que le dossier technique devra expliquer ; une entrée en file conservée, avec un responsable et un critère de réouverture, est cette explication, écrite sur le moment.
Corriger et vérifier
À nous de soutenir, non de porter : nous pouvons rester pendant les correctifs et vérifier chaque correction contre le constat qu’elle vise, à la révision qui l’a close, consignée comme un résultat à part entière. Une correction vérifiée par relecture n’est pas une correction vérifiée par réexécution ; le dossier nomme l’échelon que la vérification elle-même a atteint.
Ce que le CRA exige ici. Distribution sécurisée des mises à jour, et correctifs de sécurité diffusés sans retard et gratuitement, accompagnés d’informations d’avis (annexe I, partie II, points 7 et 8) ; communication publique sur les vulnérabilités corrigées dès qu’une mise à jour est disponible (annexe I, partie II, point 4).
Notifier : là où le tiers gagne ses honoraires
La troisième rupture, et celle pour laquelle les acheteurs viennent d’ordinaire. Une exécution interne (quel que soit le nombre de modèles, quel que soit leur isolement) produit votre propre parole sur votre propre code. D’après notre expérience, trois des quatre parties qui liront votre dossier ne l’acceptent pas : le conseil d’un acquéreur en diligence, le souscripteur d’un assureur cyber, l’équipe sécurité d’un client grand compte. Ce qu’elles achètent, c’est l’indépendance organisationnelle : un dossier apprécié et signé par une personne nommée extérieure à votre organisation, qui peut être citée, et qui se rétracte par écrit si un constat ne tient pas. C’est la propriété qu’aucune équipe ne peut fournir sur son propre travail, et c’est la totalité de ce que nous vendons.
La quatrième partie, le régulateur, est l’exception, et elle tranche dans l’autre sens : il acceptera souvent votre auto-évaluation, puis vous tiendra à chaque pièce qui la soutient.
Ce que le CRA exige ici. Deux voies de notification, toutes deux par la plateforme de notification unique et toutes deux en vigueur depuis le 11 septembre 2026 (article 14). Pour une vulnérabilité activement exploitée : une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification dans les 72 heures, et un rapport final au plus tard 14 jours après qu’une mesure corrective ou d’atténuation est disponible. Pour un incident grave : les mêmes étapes à 24 et 72 heures, et un rapport final dans le mois suivant la notification. Une revue externe n’est pas une notification et ne s’y substitue pas ; ce qu’elle peut faire, c’est transformer le « ce que nous savions, quand, et comment nous l’avons établi » derrière une notification en dossier plutôt qu’en reconstitution. Séparément, les produits classés importants (annexe III) ou critiques (annexe IV) relèvent de procédures d’évaluation de la conformité au titre de l’article 32 qui peuvent faire intervenir un organisme notifié, ce que nous ne sommes pas, et à quoi rien sur cette page ne se substitue.
Conserver
La documentation technique et la déclaration UE de conformité sont tenues à disposition pendant au moins dix ans après la mise sur le marché du produit, ou pendant la période d’assistance, la période la plus longue étant retenue (article 13, paragraphe 13). Un dossier conservé une décennie sera lu par quelqu’un qui n’était pas dans la pièce, avec plus de temps et moins de bienveillance que quiconque l’a écrit. Chaque affirmation du nôtre nomme l’échelon de preuve atteint, chaque surface examinée et jugée saine nomme la méthode et le contrôle, chaque rétractation est écrite, parce que c’est ce lecteur-là pour qui il est bâti.
Une phrase
Les outils produisent des candidats. Ce que nous produisons, c’est le dossier signé et gradué par la preuve qui dit à votre acquéreur, à votre assureur et à votre régulateur ce qui a été établi sur votre code, à quel échelon, ce qui demeure incertain et qui en répond. Non ce qui est vrai (aucun relecteur ne peut le promettre) mais ce qui a été montré, et comment.
Les limites qui ont leur place ici : nous n’avons pas montré qu’un panel trouve plus de défauts réels qu’un seul bon relecteur et ne le prétendons pas ; l’indépendance de nos instances est bornée par la procédure et non mesurée ; notre banc de relecture compte deux personnes ; nous appartenons à un groupe qui construit des infrastructures de paiement et de conservation, et nous le déclarons par écrit avant toute mission ; nous ne sommes pas un organisme notifié et rien ici ne constitue un conseil juridique. Les renvois au règlement visent le règlement (UE) 2024/2847, vérifiés contre le texte français officiel avant la mise en ligne de cette note ; la lecture du cycle de vie et l’affirmation sur l’étape autrefois coûteuse sont les nôtres. Si un renvoi est faux, nous le corrigeons ici, par écrit.