Ghost in the Binary

Quand la réglementation ne voit pas ce qu'elle déclare conforme

Le 1er février 2026, René Meusel monte sur scène au FOSDEM à Bruxelles. Meusel maintient Botan, une bibliothèque cryptographique recommandée par le BSI allemand, et travaille comme ingénieur chez Rohde & Schwarz Cybersecurity. Son sujet : "Trust the Math, Fear the Compiler." Sa démonstration : GCC 15.2, compilé avec le flag d'optimisation -O3, supprime les protections contre les attaques par canal auxiliaire dans du code cryptographique correct¹.

Le compilateur ne casse pas le code. Il l'optimise. Il détecte une boucle de vérification qui sort tôt quand le caractère est correct, en déduit que le code de normalisation du timing qui suit est inutile, et l'élimine. Résultat : un timing side-channel exploitable apparaît dans le binaire compilé. Le code source est sûr. Le binaire ne l'est plus.

Sept mois plus tard, le 11 septembre 2026, les obligations de signalement du Cyber Resilience Act européen entrent en vigueur². Chaque fabricant de produit à éléments numériques devra signaler les vulnérabilités activement exploitées à l'ENISA sous 24 heures³, avec des amendes pouvant atteindre 15 millions d'euros ou 2,5% du chiffre d'affaires mondial⁴.

Le CRA évalue la conformité du code source. Le compilateur modifie le binaire. Le régulateur ne voit pas la différence.

Ce que le CRA couvre

Le CRA et la nouvelle directive sur la responsabilité des produits (PLD 2024/2853) forment le dispositif réglementaire le plus complet conçu à ce jour pour réduire les risques liés aux produits numériques en Europe.

Le CRA impose aux fabricants d'évaluer les risques cyber durant toutes les phases du cycle de vie, de la conception à la maintenance, et de ne pas mettre sur le marché des produits présentant des vulnérabilités connues⁵. Les fabricants doivent produire un SBOM (Software Bill of Materials) documentant tous les composants intégrés⁶. L'obligation de signalement couvre même les produits déployés avant l'entrée en vigueur du texte⁷.

La PLD va plus loin. Le logiciel devient un produit au sens juridique, soumis à la responsabilité stricte, sans faute⁸. Le fabricant répond des défauts même s'il n'a commis aucune négligence. Le plafond de responsabilité de l'ancienne directive disparaît⁹. Les entreprises ne peuvent pas contractuellement exclure ou limiter leur responsabilité pour les défauts de cybersécurité¹⁰.

Le dispositif repose sur un présupposé : le fabricant maîtrise son produit. Ce qu'il écrit, ce qu'il teste, ce qu'il déclare conforme, c'est ce qui tourne chez le client.

La démonstration de Meusel au FOSDEM invalide ce présupposé.

Le compilateur, acteur invisible

L'optimisation agressive des compilateurs modernes transforme les propriétés de sécurité du code. Meusel décrit une escalade en trois étapes pour protéger une simple vérification de mot de passe contre les timing attacks.

Première étape : remplacer les valeurs booléennes par des entiers sur deux bits, avec des opérations bitwise. GCC détecte le subterfuge. Il reconnaît les comparaisons booléennes déguisées et réintroduit les branchements optimisés.

Deuxième étape : appliquer des fonctions d'obfuscation sur les entrées et les sorties. Ces fonctions n'apportent rien au programme. Elles existent pour empêcher le compilateur d'optimiser les protections de sécurité.

Troisième étape : injecter de l'assembleur inline qui ne fait rien, qui retourne la même valeur inchangée. Le compilateur ne comprend pas l'assembleur. Il cesse de toucher aux valeurs concernées¹.

Du code écrit pour tromper un outil de traduction. Trois couches d'obfuscation dont la seule fonction est d'empêcher GCC de supprimer les protections que le développeur a intentionnellement placées.

Un second talk au même FOSDEM propose une approche plus ambitieuse. Le projet GnuSecret introduit un attribut secret directement dans GCC, permettant de propager la notion de donnée confidentielle à travers les passes d'optimisation¹¹. Le langage C n'a aucune notion de donnée secrète dans sa machine abstraite. Le compilateur ne peut pas protéger ce qu'il ne sait pas devoir protéger.

Meusel montre le contournement artisanal, GnuSecret montre la solution de fond. Les deux confirment que le compilateur est un acteur autonome dans la chaîne de sécurité, et que ni le CRA ni la PLD ne l'ont prévu.

Qui paie quand le compilateur casse le binaire

GCC est un logiciel libre, développé hors de toute activité commerciale. Le CRA exempte explicitement les stewards open source des obligations de fabricant¹². Leurs seules contraintes : maintenir une politique de cybersécurité, coopérer avec les autorités de surveillance, signaler les vulnérabilités activement exploitées (Article 24 CRA). La PLD exclut les logiciels libres fournis en dehors d'une activité commerciale (Article 2(2) PLD)¹³.

L'exemption s'arrête net quand un composant open source entre dans un produit commercial. Le CRA est explicite : quand un fabricant intègre des composants tiers dans son produit, il doit exercer une diligence raisonnable pour que ces composants ne compromettent pas la cybersécurité du produit (Article 13(5) CRA)¹²ᵇ. La PLD enfonce le clou : un logiciel libre développé hors activité commerciale est exclu de son champ d'application (Article 2(2) PLD). Le Recital 15 précise la conséquence : quand un fabricant intègre un tel logiciel dans un produit commercial, il peut être tenu responsable des défauts de ce logiciel, mais pas le fabricant du logiciel, puisque celui-ci n'a jamais mis de produit sur le marché au sens de la directive¹³ᵇ.

Traduit en clair : vous compilez votre produit avec GCC. GCC optimise votre code et casse une protection constant-time. Votre binaire est vulnérable. Vous êtes responsable au titre du CRA pour le défaut de conformité. Vous êtes liable au titre de la PLD pour le dommage causé. Et vous ne pouvez pas vous retourner contre GCC, parce que GCC n'est pas un opérateur économique au sens de la directive.

Le fabricant porte 100% de la responsabilité pour un défaut qu'il n'a pas introduit, dans un binaire dont le compilateur a modifié les propriétés de sécurité, par un outil que le régulateur a choisi d'exclure du périmètre. L'entité qui cause le défaut n'existe pas au regard de la PLD. L'entité qui est responsable n'a pas causé le défaut. Et il n'y a personne contre qui exercer un recours.

La PLD aggrave la situation. La responsabilité est stricte : le fabricant n'a pas besoin d'être négligent pour être tenu responsable¹⁴. Le fait qu'il ait écrit un code source correct, testé et audité, ne constitue pas une défense, car la PLD évalue le produit tel qu'il est mis sur le marché, pas tel qu'il a été conçu¹⁵. Si le fabricant ne peut pas démontrer sa conformité aux processus requis, les tribunaux peuvent présumer la défectuosité¹⁶. Or démontrer la conformité du code source ne suffit pas si le binaire a des propriétés différentes. Et les processus de vérification post-compilation (valgrind, ct-verif) ne font partie d'aucune norme de conformité CRA. Enfin, la PLD crée une cascade de responsabilité : fabricant, puis importateur, puis distributeur (Article 8 PLD)¹³ᵇ. Si le fabricant n'est pas identifiable ou n'a pas d'entité dans l'Union, c'est le distributeur européen qui porte la responsabilité, pour un défaut dont il ignore tout.

Ce que le SBOM ne voit pas

Le CRA impose les SBOM pour améliorer la transparence de la chaîne d'approvisionnement⁶. Un SBOM documentera : Botan 3.x, compilé avec GCC 15.2, flag -O3. Il ne documentera pas que GCC a supprimé la protection constant-time de la fonction de vérification à la ligne 247, exposant un side-channel de 3 nanosecondes exploitable à distance.

Le SBOM inventorie ce qu'on met dans la boîte. Pas ce qui en sort.

Une montée de version du compilateur, de GCC 14 à GCC 15, peut introduire de nouvelles optimisations qui cassent des protections cryptographiques dans du code inchangé. Le SBOM reflétera le changement de version du compilateur. Il ne reflétera pas la régression de sécurité silencieuse dans le binaire.

Les évaluations de conformité, les certifications Critères Communs, les audits CSPN de l'ANSSI examinent le code source ou, au mieux, le binaire à un instant donné. Une recompilation avec un compilateur mis à jour peut invalider ces certifications sans que personne ne le détecte.

L'infrastructure américaine en contraction

Le trou dans le binaire n'est que le premier angle mort. Le second concerne l'infrastructure sur laquelle le CRA s'appuie pour fonctionner.

Les obligations de signalement présupposent que les vulnérabilités sont identifiées, cataloguées, scorées. En pratique, cette infrastructure repose sur trois piliers américains : le système CVE de MITRE, la base NVD du NIST, et le catalogue KEV de la CISA.

J'ai documenté la fragilité de ces piliers dans les articles précédents de cette série¹⁷. Rappel des faits à date.

Le NVD accumule plus de 26 000 CVE non analysés¹⁸. Fin janvier 2026, NIST a reconnu devant son advisory board qu'il « combat une bataille perdue » et cessé d'utiliser le mot « backlog », un terme qui supposait l'intention de rattraper le retard. NIST ne rattrapera pas. Il va désormais prioriser quels CVE enrichir, en abandonnant le reste¹⁸ᵇ. Le financement du programme CVE par MITRE, prolongé jusqu'en avril 2026, reste sans garantie à long terme¹⁹. La CISA a perdu la quasi-totalité de ses cadres dirigeants et subi des coupes budgétaires de 30%²⁰. Le catalogue KEV couvre environ 0,5% des CVE publiés²¹, alimenté par des sources essentiellement américaines : capteurs déployés sur des réseaux américains, renseignement provenant de la NSA, du FBI, d'éditeurs US.

L'Europe n'a pas d'alternative opérationnelle. L'EUVD lancé en 2025 est embryonnaire. Le GCVE (Global CVE Allocation System) européen, lancé en réaction aux défaillances américaines, inquiète NIST qui craint une « balkanisation » du système¹⁸ᵇ. Aucun catalogue européen de vulnérabilités activement exploitées n'existe. 85% des solutions européennes de sécurité s'appuient sur les données du NVD²².

Le CRA impose aux fabricants européens de signaler les vulnérabilités sous 24 heures. Pour identifier ces vulnérabilités, ces fabricants dépendent d'une infrastructure américaine qui ne prétend même plus assurer l'exhaustivité du traitement²³.

Conformité et visibilité

Le CRA produit une mécanique de conformité : SBOM documenté, CVE monitorés, signalement en 24 heures, processus de patch, marque CE apposée. Le fabricant coche les cases. L'auditeur valide. Le régulateur est satisfait.

Cette conformité couvre les vulnérabilités cataloguées, celles qui ont un identifiant CVE, un score CVSS, une fiche NVD. Le quadrant "vulnérabilité connue, exploitation connue" dans la matrice classique connu/inconnu. Tout le reste échappe au dispositif.

Un 0-day activement exploité mais sans identifiant CVE reste invisible au CRA tant qu'aucune attribution n'existe. Le KEV exige un CVE pour inclure une vulnérabilité dans son catalogue²¹. Pas de CVE, pas de KEV, pas de signal, pas d'obligation de signalement.

Une vulnérabilité introduite par le compilateur dans un binaire déclaré conforme échappe à toute détection : aucun scanner ne la repère, aucun CVE ne la référence, aucun SBOM ne la documente. Elle existe dans le binaire déployé chez le client, pas dans le code source audité. Et une classe de vulnérabilités inconnue, découverte par un attaquant utilisant l'IA pour fuzzer des binaires compilés, est par définition absente de tout catalogue.

Le CRA transforme un biais de visibilité en attestation de conformité. L'organisation conforme croit son périmètre couvert. Le périmètre couvert représente une fraction du risque réel.

L'IA dans l'angle mort

L'article 4 de cette série documentait le déséquilibre entre IA défensive et offensive²⁴. L'IA défensive améliore le traitement des menaces connues, une amélioration linéaire. L'IA offensive explore l'espace de l'inconnu, découvre de nouveaux chemins d'attaque, génère des techniques non documentées, et multiplie exponentiellement le nombre d'attaquants capables.

Le cas du compilateur illustre ce déséquilibre avec une précision chirurgicale.

Ce que Meusel fait manuellement avec valgrind, vérifier qu'un binaire compilé préserve les propriétés constant-time du code source, une IA offensive peut le faire à l'échelle industrielle. Fuzzer des binaires compilés avec différentes versions de GCC, Clang, MSVC. Cartographier les optimisations qui introduisent des timing variations. Identifier les bibliothèques cryptographiques dont les protections sont silencieusement supprimées. Cibler les produits conformes au CRA dont le binaire ne correspond plus aux garanties du code source.

En février 2026, Anthropic a publié les résultats de Claude Opus 4.6 en recherche de vulnérabilités : plus de 500 failles sévères validées dans des projets open source majeurs (Ghostscript, OpenSC, CGIF), dont certaines présentes depuis des décennies et résistantes à des millions d'heures de fuzzing automatisé²⁵. Le modèle ne fuzze pas : il lit le code source, analyse l'historique Git, raisonne sur la logique algorithmique. Coût : environ 45 dollars par tentative. Anthropic estime que les fenêtres de divulgation de 90 jours pourraient devenir inadéquates face au volume de découvertes²⁵ᵇ. Google Big Sleep et Microsoft Security Copilot confirment la tendance²⁶.

Ces résultats portent sur le code source, pas sur les binaires compilés. L'extrapolation vers l'analyse binaire est une projection, pas un fait établi. Mais la direction est claire : quand un modèle raisonne sur la logique d'un algorithme de compression pour déclencher un dépassement de tampon que le fuzzing ne peut trouver statistiquement, appliquer ce raisonnement aux transformations d'un compilateur est une question de temps et d'orientation, pas de rupture technologique.

L'IA maximise le jeu offensif dans le plan exact que le CRA ne couvre pas. Les vulnérabilités cataloguées, les fabricants savent les gérer, même mal. Les vulnérabilités émergentes, créées par l'interaction entre couches du stack, invisibles aux scanners, absentes des catalogues, voilà le terrain où l'IA offensive opère sans contrainte et où le CRA est aveugle.

La chaîne complète

Récapitulons. Le compilateur introduit des vulnérabilités dans le binaire que le code source ne contient pas, mais le CRA évalue la conformité du code source. L'infrastructure de détection (CVE/NVD/KEV) qui alimente les obligations du CRA est sous contrôle américain, en contraction, et biaisée géographiquement. Et l'IA offensive découvre et exploite des classes de vulnérabilités que le système CVE/NVD/KEV ne catalogue pas par définition, puisqu'elles n'existaient pas avant d'être trouvées.

Ces trois failles ne s'additionnent pas. Elles se multiplient. Le compilateur crée des vulnérabilités que le CVE ne référence pas, que le scanner ne détecte pas, que le SBOM ne documente pas, et que l'IA offensive peut chercher à un coût marginal de 45 dollars par tentative, avec des taux de succès qui doublent tous les six mois. La conformité CRA, loin de protéger, rassure l'organisation sur un périmètre couvert pendant que le risque se concentre hors du périmètre.

En termes militaires, c'est une ligne Maginot. Une fortification coûteuse, techniquement impressionnante, construite face à la menace visible. L'attaque passera par les Ardennes.

Ce que je ne sais pas

L'étendue du problème n'est plus une hypothèse. Une étude d'octobre 2024, « Breaking Bad: How Compilers Break Constant-Time Implementations », a analysé 44 604 cibles compilées à travers les principales bibliothèques cryptographiques, six architectures processeur (x86-64, ARM, RISC-V, MIPS), plusieurs versions de GCC et LLVM, et tous les niveaux d'optimisation²⁵ᶜ. Résultat : les vulnérabilités introduites par le compilateur sont « widespread ». Les chercheurs en trouvent dans toutes les configurations testées, y compris dans les bibliothèques les plus réputées pour leur résistance aux canaux auxiliaires. Un second papier de juillet 2025 identifie les passes d'optimisation spécifiques responsables et propose des mitigations par flags compilateur²⁵ᵈ.

Ce que je ne sais pas : l'étendue au-delà des bibliothèques open source étudiées. Les implémentations cryptographiques internes aux entreprises, les firmwares embarqués, les bibliothèques propriétaires non auditées, personne n'a mesuré l'impact des optimisations compilateur sur ce périmètre. Et c'est là que le CRA mord : les produits conformes mis sur le marché européen incluent massivement ce type de code non vérifié.

Je ne sais pas non plus si la Commission européenne a connaissance de cet angle mort. Les discussions autour du CRA ont porté sur les SBOM, les processus de patch, les obligations de signalement. La question "le binaire compilé a-t-il les mêmes propriétés de sécurité que le code source audité ?" n'apparaît dans aucun document préparatoire que j'ai pu consulter.

L'avenir du projet GnuSecret reste incertain. Si GCC intègre un attribut secret dans une version future, ce serait un premier pas vers un compilateur qui comprend la sécurité, pas seulement la performance. Mais GCC évolue lentement, et l'intégration d'un tel changement prendrait des années. Quant à l'EUVD européen ou au nouveau GCVE, rien ne dit qu'ils pourront couvrir les vulnérabilités introduites par les compilateurs. Ce type de vulnérabilité ne rentre pas dans le modèle CVE classique : il n'y a pas de bug dans le code source, pas de bug dans le compilateur (il se comporte conformément au standard C), et pourtant le binaire est vulnérable. Le cadre conceptuel actuel n'a pas de catégorie pour ce phénomène.

Sept mois pour agir

Le CRA entre en vigueur par étapes : signalement des vulnérabilités en septembre 2026, conformité complète en décembre 2027²⁷. La PLD s'applique à partir de décembre 2026²⁸.

Les fabricants qui préparent leur conformité CRA ont sept mois pour intégrer un fait que la réglementation ignore : le binaire qu'ils livrent n'a pas nécessairement les propriétés de sécurité du code qu'ils ont écrit.

Intégrer la vérification post-compilation dans la chaîne CI/CD est la première urgence. Des outils comme valgrind (mode memcheck), ct-verif, ou timecop permettent de détecter les timing leaks dans les binaires compilés. Aucune norme CRA ne l'exige. La PLD l'exigera de fait, puisqu'un fabricant incapable de démontrer qu'il a vérifié son binaire se retrouvera sans défense face à une présomption de défectuosité.

Documenter les flags de compilation et les justifier vient ensuite. Le choix entre -O2 et -O3 a des conséquences sur les propriétés de sécurité du binaire. Un SBOM augmenté, incluant la version du compilateur, les flags d'optimisation, et les résultats de vérification post-compilation, constitue une preuve de diligence qui n'existe dans aucun standard actuel mais que tout tribunal comprendra.

Enfin, traiter chaque montée de version du compilateur comme un événement de sécurité. Une mise à jour de GCC 14 vers GCC 15 peut introduire de nouvelles optimisations qui cassent des protections cryptographiques dans du code inchangé. Le processus de gestion des changements doit inclure la re-validation des propriétés de sécurité du binaire après chaque changement de compilateur.

Ces mesures ne résolvent pas le problème de fond. Elles réduisent l'exposition juridique et le risque technique pendant que le cadre réglementaire rattrape la réalité.

Le problème de fond est un défaut de conception dans le CRA. Un règlement qui vise à réduire les risques liés aux produits numériques européens sans adresser la chaîne de transformation entre le code source et le binaire déployé, et sans alternative européenne aux bases de vulnérabilités américaines dont il dépend, produit de la conformité, pas de la sécurité. Et il produit un effet pervers : des coûts de conformité et une responsabilité stricte que seuls les acteurs déjà établis peuvent absorber, dans un marché dominé par des acteurs non-européens qui peuvent choisir de ne pas y entrer.

Douzième article d'une série sur les failles structurelles de la cybersécurité occidentale :

• Article 1 : La vulnérabilité de la gestion des vulnérabilités
• Article 2 : La dépendance européenne aux standards américains
• Article 3 : Les États, architectes cachés du marché noir des vulnérabilités
• Article 4 : L'IA ou l'effondrement du modèle défensif occidental
• Article 5 : Desert Power — survivre sans l'Empire
• Article 6 : I Am Altering the Deal
• Article 7 : Le dernier canal
• Article 8 : Lord of Cyber War
• Article 9 : Les faucons du numérique
• Article 10 : They Live... we sleep
• Article 11 : Soylent Green

¹ Meusel, R. (2026). "Trust the Math, Fear the Compiler", FOSDEM 2026, Security Devroom https://fosdem.org/2026/schedule/event/fosdem-2026-6174-trust-the-math-fear-the-compiler/

² Regulation (EU) 2024/2847, Article 69(3) — obligations de signalement applicables à partir du 11 septembre 2026 https://digital-strategy.ec.europa.eu/en/policies/cra-summary

³ Regulation (EU) 2024/2847, Article 14(1) — notification sous 24 heures à l'ENISA et aux CSIRT nationaux https://www.european-cyber-resilience-act.com/

⁴ Regulation (EU) 2024/2847, Article 64 — pénalités maximales de 15 millions d'euros ou 2,5% du CA mondial https://www.whitecase.com/insight-alert/cyber-resilience-act-clock-ticking-compliance

⁵ Regulation (EU) 2024/2847, Annex I, Part I — exigences essentielles de cybersécurité https://cycode.com/blog/cyber-resilience-act/

⁶ Regulation (EU) 2024/2847, Preamble 77 — obligation de SBOM https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Preamble_71_to_80.html

⁷ Regulation (EU) 2024/2847, Article 69(3) — application aux produits mis sur le marché avant décembre 2027 https://www.keysight.com/blogs/en/tech/nwvs/2025/09/11/one-year-countdown-to-eu-cra-compliance-september-11-2026-changes-everything

⁸ Directive (EU) 2024/2853, Article 4 — le logiciel explicitement inclus dans la définition de "produit" https://www.ibanet.org/European-Product-Liability-Directive-liability-for-software

⁹ Directive (EU) 2024/2853 — suppression du plafond de responsabilité https://www.ibanet.org/European-Product-Liability-Directive-liability-for-software

¹⁰ Reed Smith (2025). "The new EU Product Liability Directive: Implications for software, digital products, and cybersecurity" https://www.reedsmith.com/articles/eu-product-liability-directive-software-digital-products-cybersecurity/

¹¹ "Tentative Definition of the Secret Attribute in GCC", FOSDEM 2026 https://fosdem.org/2026/schedule/event/HGLHTN-tentative_definition_of_the_secret_attribute_in_gcc/

¹² Regulation (EU) 2024/2847, Article 24 — obligations des "open-source software stewards" : politique de cybersécurité, coopération avec les autorités, signalement des vulnérabilités exploitées https://digital-strategy.ec.europa.eu/en/policies/cra-open-source

¹²ᵇ Regulation (EU) 2024/2847, Article 13(5) — obligation de diligence raisonnable du fabricant sur les composants tiers intégrés, y compris open source. La Commission prévoit des « voluntary security attestation programmes » par actes délégués (Article 25) https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

¹³ Directive (EU) 2024/2853, Article 2(2) — exclusion du logiciel libre hors activité commerciale. Un service payant ou fourni en échange de données personnelles rétablit le caractère de produit https://www.ibanet.org/European-Product-Liability-Directive-liability-for-software

¹³ᵇ Directive (EU) 2024/2853, Recital 15 (un fabricant qui intègre un logiciel libre dans un produit commercial peut être tenu responsable des défauts de ce logiciel, mais pas le fabricant du logiciel, exclu du champ par l'Article 2(2)), Article 8 (cascade de responsabilité : fabricant → importateur → représentant autorisé → prestataire logistique → distributeur) et Article 12(2) (le recours contre un fabricant de composant logiciel peut être exclu contractuellement si celui-ci est une micro ou petite entreprise) https://eur-lex.europa.eu/eli/dir/2024/2853/oj/eng

¹⁴ Directive (EU) 2024/2853 — régime de responsabilité stricte (no-fault) https://www.fladgate.com/insights/the-eus-new-product-liability-directive-what-it-means-for-software

¹⁵ Directive (EU) 2024/2853, Article 7(2) — évaluation de la défectuosité des produits numériques https://riskandcompliance.freshfields.com/post/102jk3j/the-eu-product-liability-directive-key-implications-for-software-and-ai

¹⁶ Reed Smith (2025), ibid. — présomption de défectuosité en cas de complexité technique https://www.reedsmith.com/articles/eu-product-liability-directive-software-digital-products-cybersecurity/

¹⁷ Voir articles 1, 2 et 7 de cette série

¹⁸ Gamblin, J. (2026). "NVD Analysis Status" — 26 628 CVE non analysés depuis février 2024, 484 jours estimés pour résorber au rythme pré-crise https://github.com/jgamblin/NVDAnalysisStatus

¹⁸ᵇ Cybersecurity Dive (janvier 2026). "NIST is rethinking its role in analyzing software vulnerabilities" — NIST admet « We're fighting a losing battle » et annonce la priorisation plutôt que l'enrichissement exhaustif https://www.cybersecuritydive.com/news/nist-cve-vulnerability-analysis-nvd-review/810300/

¹⁹ Voir article 1 de cette série : crises de financement MITRE 2024 et 2025

²⁰ Cybersecurity Dive, "CISA loses nearly all top officials as purge continues", mai 2025 https://www.cybersecuritydive.com/news/cisa-senior-official-departures/748992/

²¹ Voir article 7 de cette série : "Le KEV couvre environ 0,5% des CVE publiés" ; le KEV exige un CVE pour inclusion

²² Voir article 2 de cette série : "85% des solutions européennes s'appuient sur les données du NVD"

²³ GIS Reports, "U.S. cybersecurity policy under Trump", novembre 2025 https://www.gisreportsonline.com/r/trump-cyber/

²⁴ Voir article 4 de cette série : "L'IA ou l'effondrement du modèle défensif occidental"

²⁵ Anthropic Frontier Red Team (février 2026). "0-Days" — Claude Opus 4.6 découvre 500+ vulnérabilités sévères validées dans des projets open source majeurs sans scaffolding spécialisé https://red.anthropic.com/2026/zero-days/

²⁵ᵇ Anthropic (février 2026). "Building AI Cyber Defenders" — Sonnet 4.5 reproduit des vulnérabilités connues dans 66,7% des cas à 30 essais ($45/essai) ; taux de succès doublé en six mois https://www.anthropic.com/research/building-ai-cyber-defenders

²⁵ᶜ Music, N. et al. (2024). "Breaking Bad: How Compilers Break Constant-Time Implementations", ACM CCS — 44 604 cibles analysées, vulnérabilités compilateur « widespread » dans toutes les configurations testées https://arxiv.org/abs/2410.13489

²⁵ᵈ "Fun with flags: How Compilers Break and Fix Constant-Time Code" (juillet 2025) — Identification des passes d'optimisation GCC/LLVM responsables, mitigations par flags compilateur https://arxiv.org/abs/2507.06112

²⁶ Google Project Zero "Big Sleep" (octobre 2024), première vulnérabilité exploitable (SQLite) découverte par un agent IA ; Microsoft Security Copilot (mars 2025), 20 failles dans les bootloaders GRUB2, U-Boot et Barebox https://projectzero.google/2024/10/from-naptime-to-big-sleep.html https://www.microsoft.com/en-us/security/blog/2025/03/31/analyzing-open-source-bootloaders-finding-vulnerabilities-faster-with-ai/

²⁷ Regulation (EU) 2024/2847 — calendrier d'application : signalement 11 septembre 2026, conformité complète 11 décembre 2027 https://orcwg.org/cra/

²⁸ Directive (EU) 2024/2853 — transposition nationale au plus tard le 9 décembre 2026 https://iclg.com/practice-areas/product-liability-laws-and-regulations/01-the-new-eu-product-liability-directive