Le Guépard

"Se vogliamo che tutto rimanga come è, bisogna che tutto cambi." L'Europe change son cadre réglementaire. Elle ne change pas sa condition de dépendance.

Le 19 mars 2026, l'Agence de l'Union européenne pour la cybersécurité (ENISA) publie un guide technique sur l'utilisation sécurisée des gestionnaires de paquets¹. Le document couvre les risques liés aux dépendances logicielles tierces : packages malveillants, mainteneurs compromis, typosquatting, confusion de dépendances. Il recommande le suivi des dépendances, la génération de SBOM, la vérification de provenance, le monitoring continu et la documentation des remédiations.

Ce guide arrive six mois avant la première échéance contraignante du Cyber Resilience Act. Le 11 septembre 2026, les fabricants de produits numériques vendus en Europe devront signaler les vulnérabilités activement exploitées dans un délai de 24 heures, notifier complètement sous 72 heures, et produire un rapport final sous 14 jours². Les sanctions prévues atteignent 15 millions d'euros ou 2,5% du chiffre d'affaires mondial. Les régulateurs peuvent retirer du marché européen les produits non conformes³.

J'ai examiné chaque recommandation du guide ENISA, puis confronté chacune aux incidents documentés entre janvier et avril 2026. Le guide est sincère, compétent et méthodique. Ses hypothèses implicites sont fausses.

Ce que le CRA construit

Le CRA impose quatre obligations de fond aux fabricants de produits avec éléments numériques. Premièrement, une évaluation de risque cybersécurité documentée et mise à jour en continu. Deuxièmement, l'absence de vulnérabilités exploitables connues au moment de la mise sur le marché. Troisièmement, un SBOM (Software Bill of Materials) en format lisible par machine. Quatrièmement, des mises à jour de sécurité gratuites pendant au moins cinq ans⁴.

L'intention est claire : responsabiliser les éditeurs. Tuer le modèle « on livre et on oublie ». Forcer une hygiène de base que l'industrie n'a jamais adoptée volontairement. Le rapport ENISA NIS Investments 2025 documente l'ampleur du retard : 28% des organisations mettent plus de trois mois à corriger les vulnérabilités critiques (51% chez les PME), et 30% n'ont réalisé aucune évaluation de sécurité dans les douze derniers mois (63% chez les PME)⁵. Le CRA a raison de forcer le mouvement.

Le guide ENISA traduit ces obligations en pratiques opérationnelles pour la gestion des dépendances. L'ORCWG (Open Regulatory Compliance Working Group) résume l'enjeu : la conformité complète de la chaîne d'approvisionnement logicielle n'a jamais été exigée avant le CRA⁶. Le texte impacte chaque couche de cette chaîne, y compris les dépendances open source embarquées dans les produits commerciaux. Une étude de marché ANSSI publiée en avril 2026 confirme le diagnostic côté demande : les cadres réglementaires actuels restent formulés à haut niveau, avec des orientations opérationnelles limitées quant à la mise en œuvre des exigences⁶ᵇ.

Le calendrier qui suit est dense. Le 11 juin 2026, les États membres doivent avoir désigné leurs autorités notifiantes et publié les procédures d'évaluation des organismes de conformité. Les organismes eux-mêmes ne suivront qu'ensuite : le règlement ne vise un nombre suffisant d'organismes notifiés que pour le 11 décembre 2026, et précise que l'objectif est d'éviter les goulots d'étranglement à l'entrée sur le marché⁷. Le 11 septembre, les obligations de reporting entrent en vigueur. Le 11 décembre 2027, l'ensemble des obligations devient applicable. Les fabricants devront donc se mettre en conformité avant que le dispositif chargé de les évaluer soit garanti opérationnel. Pour un règlement entré en vigueur le 10 décembre 2024, le tempo est exigeant.

Jusqu'ici, le raisonnement tient. Le CRA crée le cadre. L'ENISA le traduit en pratiques. Les organisations s'outillent. Les auditeurs vérifient. Le problème commence quand on confronte ces pratiques à la menace qu'elles sont censées couvrir.

La faille de composition

Vérifier la provenance des packages, valider les signatures cryptographiques, surveiller le comportement des dépendances : le guide ENISA recommande ces contrôles. Ils supposent qu'un package malveillant est distinguable d'un package légitime si l'on applique les bonnes procédures.

Le 13 mars 2026, Socket Security publie l'analyse de la campagne GlassWorm : 72 extensions malveillantes sur le marketplace Open VSX, la place de marché utilisée par les IDE open source (VSCodium, Eclipse Theia)⁸. La particularité : les extensions elles-mêmes sont propres. Le code malveillant est enfoui dans une dépendance transitive, c'est-à-dire une dépendance de dépendance. L'extension satisfait tous les contrôles que le guide ENISA recommande. La signature est valide. Le mainteneur est authentique. Les métadonnées sont correctes. Le comportement malveillant émerge de la composition, pas du composant.

Deux jours plus tard, StepSecurity documente ForceMemo : des centaines de dépôts Python sur GitHub compromis par prise de contrôle de comptes dormants, suivie d'un force-push qui réécrit l'historique Git⁹. Le code malveillant remplace le code légitime dans le dépôt source. L'arbre de dépendances pointe vers le même identifiant, la même URL, le même nom de package. Seul le contenu a changé, et l'historique a été effacé.

Six semaines plus tard, la cadence s'accélère. Entre le 21 et le 23 avril 2026, trois attaques supply chain frappent npm, PyPI et Docker Hub simultanément¹⁰. Les images Docker officielles de Checkmarx KICS sont compromises. Un ver auto-propagatif (CanisterSprawl) infecte des packages npm via un hook postinstall, vole les tokens de publication du développeur, injecte un payload dans chaque package que la victime peut publier, et saute vers PyPI si un token PyPI est trouvé sur la machine. Le canal de commande et contrôle utilise un canister ICP (Internet Computer Protocol), résistant aux takedowns classiques. Le 30 avril, c'est PyTorch Lightning qui tombe : versions 2.6.2 et 2.6.3 compromises sur PyPI, 31 000 stars GitHub, des millions de téléchargements par mois¹¹.

CanisterSprawl marque une mutation. Le ver ne compromet pas un composant : il compromet un mainteneur, puis utilise les credentials de ce mainteneur pour publier des versions malveillantes de packages légitimes, via les canaux officiels, avec les signatures correctes. Le SBOM du projet victime sera exact. La provenance sera vérifiée. Le package sera malveillant. Et il aura traversé les frontières entre registres, de npm vers PyPI, dans un mouvement que le guide ENISA ne modélise pas, puisqu'il raisonne registre par registre.

Le 12 mai 2026, la campagne Mini Shai-Hulud franchit un seuil supplémentaire : la compromission de TanStack, Mistral AI et UiPath (plus de 160 packages npm et PyPI) s'accompagne de la première falsification documentée d'attestations de provenance SLSA Build Level 3, le standard d'intégrité le plus exigeant actuellement déployé¹¹ᵇ. La provenance n'est plus seulement insuffisante, elle est désormais falsifiable.

Le guide traite la sécurité des dépendances comme un problème de composants. Les attaquants l'ont déplacé au niveau de la composition. La conformité porte sur les pièces. La menace porte sur l'assemblage.

Treize mois avant la divulgation

Sous 24 heures après la découverte d'une vulnérabilité activement exploitée, le CRA exige un signalement. Ce délai suppose que la découverte précède l'exploitation, ou au minimum la suit de peu. Les données racontent le contraire.

En décembre 2025, Huntress observe une intrusion utilisant le toolkit MAESTRO : trois zero-days VMware ESXi chaînés (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226) permettant l'évasion d'une machine virtuelle vers l'hyperviseur¹². Les chemins de développement du toolkit contiennent une date de février 2024 et des chaînes en chinois simplifié ("全版本逃逸--交付", « évasion toutes versions, livraison »). Le toolkit a été développé comme exploit zero-day plus d'un an avant la divulgation publique par Broadcom en mars 2025. Il supporte 155 builds ESXi, de la version 5.1 à la 8.0. Pendant cette fenêtre de treize mois, aucun SBOM, aucun monitoring, aucune procédure de reporting n'aurait produit le moindre signal, puisque les vulnérabilités n'existaient dans aucune base publique.

MAESTRO n'est pas un cas isolé. Le rapport M-Trends 2026 de Mandiant, basé sur plus de 500 000 heures d'investigation en 2025, mesure un temps moyen d'exploitation des vulnérabilités de -7 jours : l'exploitation se produit couramment avant la publication du correctif¹³. 67% des CVE exploités en 2026 sont des zero-days¹⁴. Le CRA impose une obligation de signalement de 24 heures, calibrée sur un monde où les vulnérabilités sont découvertes par les défenseurs et publiées avant d'être massivement exploitées. Ce monde n'existe plus pour les acteurs étatiques ou paraétatiques. Il n'existe plus non plus pour les cybercriminels : le temps de hand-off entre un courtier d'accès initial et un affilié ransomware est tombé à 22 secondes¹³.

Le rapport DBIR 2026 de Verizon, publié le 19 mai et fondé sur plus de 31 000 incidents dans 145 pays, enregistre une bascule. Pour la première fois en dix-neuf ans d'historique du rapport, l'exploitation de vulnérabilités y devient le premier vecteur d'accès initial, devant le vol d'identifiants et l'hameçonnage : 31% des compromissions, en hausse d'un peu plus de moitié sur un an¹³ᵇ. Le même rapport mesure un temps médian de correction complète de 43 jours en 2025, contre 32 l'année précédente, et un quart seulement des failles activement exploitées du catalogue CISA corrigées dans l'année¹³ᵇ. Le CRA demande un signalement en 24 heures à des organisations qui mettent 43 jours à corriger. Le délai administratif est plus court que le délai technique qu'il prétend encadrer.

Mais la faille de tempo opère aussi dans l'autre direction : trop de vulnérabilités, trop vite.

Le 5 février 2026, Anthropic annonce que Claude Opus 4.6 a découvert plus de 500 vulnérabilités critiques dans du code open source de production¹⁵. En une seule campagne d'analyse. Le 13 mai, l'AI Security Institute britannique publie une mise à jour de ses évaluations cyber : la durée des tâches que les modèles frontier complètent de manière autonome double tous les 4,7 mois depuis fin 2024, et les deux derniers modèles testés dépassent même cette tendance¹⁶. Un checkpoint récent de Claude Mythos Preview résout les deux cyber ranges de l'AISI, dont un scénario de compromission d'entreprise en 32 étapes (estimé à 20 heures de travail humain) dans 6 tentatives sur 10, et un scénario industriel jusque-là jamais résolu dans 3 tentatives sur 10. La reconnaissance, l'exploitation, le mouvement latéral, l'escalade de privilèges et la prise de contrôle s'enchaînent sans intervention humaine. L'AISI note que les ranges ne comportent pas de défenseurs actifs, ce qui limite le résultat aux cibles faiblement défendues. Mais c'est précisément le profil d'une part significative du tissu économique européen soumis au CRA.

Vingt-quatre heures pour signaler une vulnérabilité activement exploitée. Quand la chaîne complète d'attaque s'exécute en quelques heures et que la découverte de vulnérabilités passe à l'échelle industrielle, le délai de signalement devient plus long que la fenêtre d'exploitation. Les soumissions CVE au NVD ont augmenté de 263% entre 2020 et 2025, et le premier trimestre 2026 est en hausse d'un tiers par rapport à la même période 2025¹⁷. Avec des modèles capables de trouver des centaines de failles en quelques heures et de les enchaîner en scénarios d'attaque complets, les obligations de reporting du CRA vont être mises sous pression par le volume et la vitesse simultanément. Le CRA a été calibré dans un monde pré-IA de chasse aux vulnérabilités. Ce calibrage est déjà obsolète.

Une infrastructure en construction

Le guide recommande de suivre les vulnérabilités des dépendances, de les corréler avec les bases CVE et de tenir un inventaire à jour. Ces processus reposent sur une infrastructure dont les fondations sont instables.

Depuis 2024, le National Vulnerability Database (NVD) du NIST accumule du retard de traitement. En avril 2025, le NIST a marqué « Deferred » l'ensemble des CVE publiés avant le 1ᵉʳ janvier 2018, abandonnant l'enrichissement rétroactif pour des dizaines de milliers d'entrées¹⁸. Jon Boyens, acting chief de la Computer Security Division, veut « arrêter d'utiliser le mot backlog »¹⁹. Le programme CVE de MITRE, financé à 57,8 millions de dollars par an par le gouvernement fédéral américain, a frôlé l'interruption de financement à deux reprises en 2025²⁰. MITRE a licencié 440 employés et annulé 28 millions de dollars de contrats²¹.

L'Europe construit. L'EUVD (European Vulnerability Database) de l'ENISA est en bêta depuis mai 2025. Le GCVE (Global CVE) du CIRCL luxembourgeois, lancé en janvier 2026, propose un modèle décentralisé avec 25 sources publiques²². L'analyse de VulnCheck sur l'EUVD identifie plus de 50 000 CVE absents de l'API principale²³. L'ENISA est devenue CVE Root CNA en novembre 2025, et lors de VulnCon26 à Scottsdale, le 14 avril 2026, l'agence a confirmé son onboarding par CISA pour devenir Top-Level Root CNA, le troisième au monde après CISA et MITRE²⁴. L'ambition est nette. Quatre-vingts des cinq cents CNA mondiaux sont européens, et la montée en puissance opérationnelle reste en cours²⁴.

La même agence a fait un autre choix au printemps 2026. Le 2 juin, Anthropic a élargi Project Glasswing à environ cent cinquante organisations dans plus de quinze pays, et y a admis l'ENISA²⁴ᵇ. Glasswing donne accès à Claude Mythos Preview, un modèle frontière privé que son éditeur ne commercialise pas, pour chercher et corriger des vulnérabilités dans les logiciels critiques. L'agence qui publie le guide sur les gestionnaires de paquets, qui édicte les pratiques que les fabricants européens devront suivre, et qui aspire à devenir la troisième autorité racine du système CVE, s'en remet pour sa propre capacité de découverte à un fournisseur américain. La faille d'infrastructure dépasse la question du calendrier. La capacité que le CRA présuppose existe ; l'Europe l'achète à un fournisseur américain au lieu de la produire²⁴ᶜ.

Onze jours plus tard, le 12 juin 2026, une directive du Département du Commerce a soumis à autorisation gouvernementale préalable tout transfert des modèles cyber de pointe d'Anthropic à une personne non américaine, au nom de la sécurité nationale²⁴ᵈ. L'accès qu'une agence européenne venait d'obtenir passe désormais par un guichet d'État américain.

La Single Reporting Platform (SRP), prévue par le CRA pour centraliser les notifications de vulnérabilités, doit être opérationnelle le 11 septembre 2026, le même jour que l'entrée en vigueur des obligations de reporting. Au 30 avril 2026, la plateforme n'est pas opérationnelle. L'appel d'offres (ENISA/2025/OP/0001, contrat de 4 ans) a été clôturé en mars 2025. Le prestataire n'a pas été rendu public. La phase de test n'a pas commencé²⁵. Les fabricants devront donc signaler des vulnérabilités via une plateforme qu'ils n'auront pas pu tester, en corrélant avec des bases dont la plus complète (le NVD) est en crise et la plus jeune (l'EUVD) est incomplète.

Le guide ENISA prescrit des processus qui dépendent d'une infrastructure qu'il ne mentionne pas. J'ai documenté cette dépendance en détail²⁶. Le CRA crée des obligations pour les fabricants européens. Il ne crée pas l'infrastructure de données nécessaire pour que ces obligations soient remplissables dans les délais qu'il impose.

La couche invisible

Le guide ENISA couvre les packages publiés dans les registres (npm, PyPI, Maven, NuGet). Il ne couvre pas le code qui entre dans les projets sans passer par un gestionnaire de paquets.

Les enquêtes développeurs 2025 convergent vers 84-91% d'adoption des outils de génération de code par IA (JetBrains : 85%, Stack Overflow : 84%, DX : 91%)²⁷. Ce code entre dans les dépôts avec le même traitement qu'un code écrit manuellement : même commit, mêmes métadonnées, aucune distinction. 62% des praticiens sécurité interrogés n'ont aucun moyen de savoir où les LLM sont utilisés dans leur organisation²⁸. Le code généré contient des vulnérabilités dans 45% des cas, un taux stable depuis deux ans malgré l'évolution des modèles²⁹. Moins de la moitié des développeurs relisent le code IA avant de le commiter³⁰.

Le CRA exige un SBOM. L'AI Act impose des obligations de transparence sur les modèles IA. Aucun des deux textes ne couvre la question : ce code a-t-il été généré par une IA, avec quel modèle, à partir de quel prompt, et les dépendances qu'il importe ont-elles été choisies par un humain ou suggérées par le modèle ? Les SBOM traditionnels ne capturent pas cette couche. Le concept d'AI-BOM (AI Bill of Materials) commence à émerger dans la littérature, mais aucun standard n'est stabilisé³¹.

Un outil comme git-memento tente d'adresser la traçabilité en attachant la session IA aux commits via git notes³². L'approche est volontaire et déclarative. Rien n'empêche un développeur de copier-coller du code IA sans le déclarer. Le contrôle d'intégrité n'est pas technique, il est procédural. C'est la version code de l'attestation sur l'honneur.

Le guide ENISA optimise la sécurité d'une chaîne d'approvisionnement dont une part croissante échappe aux contrôles qu'il définit. Les dépendances choisies par un agent IA (Claude Code, Copilot, Codex) ne passent pas par le workflow de sélection que le guide décrit. Elles entrent dans le projet au moment de la génération, sans revue de provenance, sans évaluation de maintenabilité, sans vérification de licence.

Ce que je sais et ce que je ne sais pas

Le CRA corrige un manque réel. Avant décembre 2024, aucun texte européen n'obligeait les fabricants de logiciels à maintenir un inventaire de leurs composants, à signaler les vulnérabilités exploitées ou à fournir des correctifs gratuits. Le CRA impose un plancher. Ce plancher n'existait pas. Son existence est un progrès. Et le guide ENISA traduit fidèlement ces obligations en pratiques opérationnelles. Chaque recommandation est raisonnable prise isolément. Vérifier la provenance d'un package est préférable à ne pas la vérifier. Générer un SBOM est préférable à ne pas en avoir.

Les quatre failles que j'ai identifiées (composition, tempo, infrastructure, couche invisible) ne sont pas corrigeables par amendement. La faille de composition est une propriété des systèmes modulaires : la sécurité des composants ne garantit pas la sécurité de l'assemblage. La faille de tempo découle de l'économie de la vulnérabilité : les acteurs offensifs disposent d'un avantage temporel que la réglementation ne peut pas réduire par décret. La faille d'infrastructure est géopolitique : l'Europe construit ses propres capacités (EUVD, GCVE, candidature TL-Root), mais la capacité opérationnelle ne suit pas encore l'ambition, et le calendrier du CRA n'attend pas. La couche invisible est technologique : le code IA entre dans les projets par des canaux que le CRA n'a pas prévus.

Ce que je ne sais pas : la vitesse à laquelle ces failles vont se manifester opérationnellement. Le premier test sera le 11 septembre 2026, quand les obligations de reporting entreront en vigueur. Si une campagne type CanisterSprawl compromet un mainteneur dont les packages sont embarqués dans des produits vendus en Europe, les fabricants devront déterminer s'ils sont affectés, évaluer la reachability de la vulnérabilité dans leur implémentation et produire un signalement en 24 heures, via une plateforme SRP dont ils n'auront eu que quelques semaines de test. Les fabricants qui auront traité le CRA comme une checklist découvriront que la checklist ne couvre pas le scénario.

Reste une inconnue : les alternatives européennes atteindront-elles la maturité opérationnelle avant que la dépendance aux infrastructures américaines ne devienne critique ? L'ENISA monte en puissance dans le système CVE. La trajectoire du NIST et de MITRE en 2025 et 2026 suggère une dégradation continue²⁶. L'Europe construit. Le calendrier du CRA court plus vite qu'elle.

La conformité comme plancher

Le CRA produit de la conformité vérifiable. Les auditeurs pourront constater la présence d'un SBOM, l'existence d'un processus de monitoring, la documentation d'une procédure de signalement. Ces vérifications portent sur l'existence de processus, pas sur leur capacité à détecter la menace réelle.

Une organisation peut être sincèrement conforme au CRA, avoir implémenté chaque recommandation du guide ENISA, et rester exposée aux quatre failles que j'ai décrites. La conformité et la protection ne sont pas synonymes. Elles ne l'ont jamais été, mais le CRA risque de renforcer la confusion en créant un cadre dont la complétude apparente masque les angles morts.

Le rapport ENISA NIS Investments 2025 note que 70% des organisations citent la conformité réglementaire comme premier moteur d'investissement en cybersécurité⁵. Si la conformité CRA devient l'objectif plutôt que le point de départ, ces investissements produiront du papier, pas de la résilience.

Pour les organisations qui vendent des produits numériques en Europe, le CRA impose un plancher. Il faut le respecter. Mais traiter ce plancher comme un plafond serait l'erreur la plus coûteuse que puisse commettre un RSSI en 2026. Les menaces documentées dans cet article opèrent au-dessus du seuil que le CRA définit. La protection réelle commence là où la conformité s'arrête : dans l'architecture des systèmes, dans la réduction des dépendances critiques, dans la capacité à fonctionner quand les bases de données et les standards sur lesquels on s'appuie se dégradent ou disparaissent.

L'Europe change ses formulaires. La condition qui rend ses organisations vulnérables reste identique.

Dix-huitiè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
• Article 12 : Ghost in the Binary
• Article 13 : Now You See Me
• Article 14 : The Prestige
• Article 15 : Pitch Black
• Article 16 : The Thing That Should Not Be
• Article 17 : Status: clean

Notes et sources

¹ ENISA, « Technical Advisory for Secure Use of Package Managers » (19 mars 2026). https://www.enisa.europa.eu/publications/enisa-technical-advisory-for-secure-use-of-package-managers

² Cyber Resilience Act, Règlement (UE) 2024/2847, Article 14 — Obligations de reporting : alerte précoce 24h, notification complète 72h, rapport final 14 jours (vulnérabilités activement exploitées) ou 1 mois (incidents graves). Application du reporting : 11 septembre 2026. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

³ CRA, Article 64 — Sanctions. Amendes jusqu'à 15 000 000 EUR ou 2,5% du chiffre d'affaires annuel mondial. Retrait du marché possible pour les produits non conformes. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

⁴ CRA, Articles 13 et 23 — Obligations essentielles : évaluation de risque, absence de vulnérabilités exploitables connues, SBOM machine-readable, mises à jour gratuites minimum 5 ans. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

⁵ ENISA, « NIS Investments 2025 » — 28% des organisations mettent plus de 3 mois à corriger les vulnérabilités critiques (51% PME). 30% n'ont réalisé aucune évaluation de sécurité en 12 mois (63% PME). 70% citent la conformité réglementaire comme premier moteur d'investissement. https://www.enisa.europa.eu/publications/nis-investments-2025

⁶ ORCWG (Open Regulatory Compliance Working Group) — La conformité complète de la chaîne d'approvisionnement logicielle n'a jamais été exigée avant le CRA. https://orcwg.org/cra/

⁶ᵇ ANSSI / Wavestone, « S-SDLC / DevSecOps : quels sont les défis actuels et futurs du marché européen ? » (avril 2026, v1.0) — 13 fournisseurs et 9 organisations interrogés. Constat : « Les cadres réglementaires actuels restent formulés à haut niveau, fournissant des orientations opérationnelles limitées quant à la mise en œuvre des exigences. » 100% des fournisseurs intègrent l'IA, mais « les capacités actuelles de l'IA dans le DevSecOps restent encore limitées » face aux attentes.

⁷ Commission européenne, « Cyber Resilience Act — Implementation » (mis à jour 23 avril 2026) — Calendrier : 11 juin 2026 (désignation des autorités notifiantes et publication des procédures d'évaluation des organismes de conformité, chapitre IV), 11 septembre 2026 (obligations de reporting, article 14), 11 décembre 2026 (objectif d'un nombre suffisant d'organismes notifiés pour éviter les goulots d'étranglement à l'entrée sur le marché), 11 décembre 2027 (application complète). Guidance CRA publiée le 3 mars 2026. https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation

⁸ Socket Security, « 72 Malicious Open VSX Extensions Linked to GlassWorm Campaign Now Using Transitive Dependencies » (13 mars 2026) — Extensions propres, code malveillant dans les dépendances transitives. Marketplace Open VSX utilisé par VSCodium et Eclipse Theia. https://socket.dev/blog/open-vsx-transitive-glassworm-campaign

⁹ StepSecurity, « ForceMemo: Hundreds of GitHub Python Repos Compromised via Account Takeover and Force Push » (mars 2026) — Prise de contrôle de comptes dormants, réécriture de l'historique Git. https://www.stepsecurity.io/blog/forcememo-hundreds-of-github-python-repos-compromised-via-account-takeover-and-force-push

¹⁰ GitGuardian, « No Off Season: Three Supply Chain Campaigns Hit npm, PyPI, and Docker Hub in 48 Hours » (23 avril 2026) — Checkmarx KICS Docker images compromises, ver CanisterSprawl auto-propagatif via postinstall hook, exfiltration vers canister ICP. Socket/StepSecurity tracking. https://blog.gitguardian.com/three-supply-chain-campaigns-hit-npm-pypi-and-docker-hub-in-48-hours/ The Register, « Another npm supply chain worm hits dev environments » (22 avril 2026). https://www.theregister.com/2026/04/22/another_npm_supply_chain_attack/

¹¹ Socket Security, « lightning PyPI Package Compromised in Supply Chain Attack » (30 avril 2026) — PyTorch Lightning (31 000 stars GitHub, millions de téléchargements/mois), versions 2.6.2 et 2.6.3 compromises. Payload similaire à la famille Shai-Hulud. Flaggé par le scanner IA Socket en 18 minutes. https://socket.dev/blog/lightning-pypi-package-compromised The Hacker News, « PyTorch Lightning Compromised in PyPI Supply Chain » (30 avril 2026). https://thehackernews.com/2026/04/pytorch-lightning-compromised-in-pypi.html

¹¹ᵇ Tenable, « Mini Shai-Hulud Supply Chain Attack CVE-2026-45321 FAQ » (21 mai 2026) — TeamPCP, campagne Mini Shai-Hulud : TanStack, Mistral AI, UiPath, 160+ packages npm/PyPI compromis. Premier cas documenté de falsification d'attestations SLSA Build Level 3. Extraction de tokens OIDC depuis la mémoire du runner GitHub Actions. Hooks de persistance ciblant les agents de code IA et les IDE. https://www.tenable.com/blog/mini-shai-hulud-frequently-asked-questions Orca Security, « TanStack and 160+ npm/PyPI Packages Compromised in Supply Chain Worm Attack » (12 mai 2026). https://orca.security/resources/blog/tanstack-npm-supply-chain-worm/

¹² Huntress, « The Great VM Escape: ESXi Exploitation in the Wild » (7 janvier 2026) — Toolkit MAESTRO : trois zero-days VMware ESXi chaînés (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226). Date de développement février 2024, divulgation Broadcom mars 2025. 155 builds ESXi supportés (5.1 à 8.0). Accès initial via SonicWall VPN compromis. Chaînes de développement en chinois simplifié. https://www.huntress.com/blog/esxi-vm-escape-exploit BleepingComputer, « VMware ESXi zero-days likely exploited a year before disclosure » (19 janvier 2026). https://www.bleepingcomputer.com/news/security/vmware-esxi-zero-days-likely-exploited-a-year-before-disclosure/

¹³ Mandiant / Google Cloud, « M-Trends 2026 » (23 mars 2026) — 500 000+ heures d'investigation en 2025. Temps moyen d'exploitation : -7 jours (exploitation avant publication du correctif). Hand-off IAB → affilié ransomware : 22 secondes (contre 8+ heures en 2022). Dwell time médian : 14 jours. Exploits = premier vecteur d'accès initial pour la 6ᵉ année consécutive (32%). Malware PROMPTFLUX et PROMPTSTEAL interrogent des LLM en cours d'exécution pour échapper à la détection. https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026 Rapport complet : https://cloud.google.com/security/resources/m-trends

¹³ᵇ Verizon, « 2026 Data Breach Investigations Report » (19 mai 2026) — 31 000+ incidents, 22 000+ compromissions confirmées, 145 pays. Exploitation de vulnérabilités devenue premier vecteur d'accès initial dans le rapport (31%, +55% en glissement annuel), devant identifiants volés et hameçonnage, pour la première fois en dix-neuf ans. Délai publication-exploitation compressé « de mois à heures » par l'IA. Temps médian de correction complète : 43 jours en 2025 (32 jours en 2024). 26% des KEV CISA corrigés sur l'année. Période couverte : nov. 2024 - oct. 2025, antérieure aux capacités IA de 2026. https://www.verizon.com/business/resources/reports/dbir/

¹⁴ Hive Security / VulnCheck (avril 2026) — 55% des zero-days exploités dans la semaine suivant la divulgation. 28,96% des KEV exploités le jour même ou avant la publication du CVE. 67,2% des CVE exploités en 2026 sont des zero-days (vs 16,1% en 2018). https://hivesecurity.gitlab.io/blog/from-cve-to-rce-in-hours-attack-timeline-2026/

¹⁵ Anthropic, annonce du 5 février 2026 — Claude Opus 4.6 : plus de 500 vulnérabilités critiques découvertes dans du code open source de production. Voir dans cette série : « Status: clean ».

¹⁶ AI Security Institute (UK), « How fast is autonomous AI cyber capability advancing? » (13 mai 2026) — Taux de doublement des capacités cyber autonomes : 4,7 mois depuis fin 2024, Mythos Preview et GPT-5.5 dépassent cette tendance. Checkpoint récent Mythos Preview : TLO résolu 6/10 (vs 3/10 en avril), Cooling Tower résolu 3/10 (jamais résolu auparavant). Près de 100% de réussite sur la suite étroite de tâches (2,5M tokens). Paper : arXiv 2603.11214. https://www.aisi.gov.uk/blog/how-fast-is-autonomous-ai-cyber-capability-advancing

¹⁷ NIST, « NIST Updates NVD Operations to Address Record CVE Growth » (15 avril 2026) — +263% de soumissions CVE 2020-2025, +33% Q1 2026 vs Q1 2025. Trois critères de priorisation : KEV CISA, logiciels fédéraux, EO 14028. Tout le reste classé « Not Scheduled ». Voir dans cette série : « Pitch Black » pour l'analyse complète des huit vecteurs de dégradation NIST. https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth

¹⁸ NIST — CVE antérieurs au 01/01/2018 marqués « Deferred » (avril 2025). Abandon de l'enrichissement rétroactif.

¹⁹ Cybersecurity Dive, « NIST is rethinking its role in analyzing software vulnerabilities » (23 janvier 2026) — Jon Boyens : « I don't think it serves our mission or our stakeholders to try to go back and enrich every CVE that is out there or that has ever been submitted. » https://www.cybersecuritydive.com/news/nist-cve-vulnerability-analysis-nvd-review/810300/

²⁰ Swarmnetics — Programme CVE : 57,8 M$/an de financement fédéral. https://swarmnetics.com/blog/mitre-cve-program-safe-until-early-2026-but-what-happens-then/

²¹ CyberScoop — MITRE : 440+ employés licenciés, 28 M$ de contrats annulés. https://cyberscoop.com/cve-program-funding-crisis-cve-foundation-mitre/

²² EUVD : lancé en bêta mai 2025 (identifiants EUVD-2025-XXXXX). GCVE : lancé janvier 2026 par le CIRCL (Luxembourg), 25+ sources publiques, modèle décentralisé. https://euvd.enisa.europa.eu/ https://www.infosecurity-magazine.com/news/global-cybersecurity-vulnerability/

²³ VulnCheck, « Does ENISA EUVD live up to all the hype? » (mai 2025) — 50 000+ CVE absents de l'API principale. https://www.vulncheck.com/blog/enisa-euvd

²⁴ Infosecurity Magazine, « ENISA Seeks Top-Tier Status in CVE Program » (25 avril 2026) — VulnCon26, Scottsdale. Nuno Rodrigues Carvalho (ENISA) confirme l'onboarding TL-Root CNA par CISA. Objectif : « 2026 ou début 2027 ». Processus qualifié d'« uncharted territory ». ~80 CNA européens sur 500+ mondiaux. ENISA devenue Root CNA en novembre 2025. https://www.infosecurity-magazine.com/news/enisa-europe-seeks-top-level-root/

²⁴ᵇ Anthropic, « Expanding Project Glasswing » (2 juin 2026) — Extension à ~150 organisations dans 15+ pays (en sus des ~50 partenaires initiaux d'avril 2026), dont des opérateurs d'énergie, d'eau, de santé et de télécommunications. ENISA admise dans le programme. Accès à Claude Mythos Preview pour la découverte et la correction de vulnérabilités. Modèle non commercialisé. https://www.anthropic.com/news/expanding-project-glasswing Cybersecurity Dive, « Anthropic shares Mythos with 150 more organizations, including critical infrastructure operators » (2 juin 2026) — Confirme l'admission de l'ENISA dans Project Glasswing. https://www.cybersecuritydive.com/news/ai-anthropic-claude-mythos-project-glasswing-expand/821714/

²⁴ᶜ Sur la lecture de Glasswing comme captation de capacité sous adoption souveraine sélective, voir dans cette série : « The Conversation ». Sur le goulot découverte/correction du modèle Mythos (530 failles divulguées, 75 corrigées), voir : « Status: clean ».

²⁴ᵈ Département du Commerce des États-Unis, directive d'export — lettre du secrétaire Howard Lutnick au CEO d'Anthropic Dario Amodei, accès désactivé le 12 juin 2026, conformité d'Anthropic confirmée le 13 juin 2026. Tout transfert, réexport ou cession domestique de Claude Fable 5 et Claude Mythos 5 à une personne non américaine est soumis à autorisation gouvernementale préalable. Suspension mondiale, Amazon Bedrock inclus, sans fenêtre de migration. Motif invoqué : capacités cyber des modèles, sécurité nationale. Pour la lecture en interdépendance armée, voir dans cette série : « The Conversation ». https://www.cnbc.com/2026/06/12/anthropic-disables-access-to-fable-5-and-mythos-5-to-comply-with-government-directive.html Crypto Briefing, « Anthropic cuts global access to Mythos models after US export controls » (13 juin 2026). https://cryptobriefing.com/anthropic-mythos-models-us-export-controls/

²⁵ ENISA, Single Reporting Platform FAQ — SRP opérationnelle prévue au 11 septembre 2026. Phase de test avant le lancement (pas encore commencée au 30 avril 2026). Appel d'offres ENISA/2025/OP/0001 (contrat 4 ans), clôturé mars 2025. Prestataire non rendu public. https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp Commission européenne, « CRA — Reporting obligations » (mis à jour 23 avril 2026). https://digital-strategy.ec.europa.eu/en/policies/cra-reporting

²⁶ Voir dans cette série : « Pitch Black » (dépendance topologique aux infrastructures américaines, huit vecteurs frappant simultanément le NIST), « La vulnérabilité de la gestion des vulnérabilités » (NVD), « La dépendance européenne aux standards américains ».

²⁷ JetBrains, « State of Developer Ecosystem 2025 » — ~85% d'utilisation régulière de l'IA, 62% s'appuyant sur au moins un assistant ou agent de code. Stack Overflow, « 2025 Developer Survey » — 84% utilisent ou prévoient d'utiliser des outils IA, 51% quotidiennement. DX Q4 2025 (135 000+ développeurs) — 91% d'adoption, 22% du code mergé est AI-authored. https://www.jetbrains.com/lp/devecosystem-2025/ https://survey.stackoverflow.co/2025

²⁸ Voir dans cette série : « Status: clean » — Sources et données détaillées sur le code IA.

²⁹ Voir dans cette série : « Status: clean » — Taux de vulnérabilité du code IA stable à ~45%. Veracode : « completely flat » depuis deux ans.

³⁰ Voir dans cette série : « Status: clean » — Moins de 50% des développeurs relisent le code IA avant commit.

³¹ AI-BOM : concept émergent, pas de standard stabilisé. Les SBOM CycloneDX et SPDX ne capturent pas la provenance IA du code source.

³² git-memento — Outil open source attachant les sessions IA aux commits via git notes. Mode « gate » bloquant les PR sans session IA attachée. Architecture volontaire et déclarative. https://github.com/mnott/git-memento