The Leopard

The Cyber Resilience Act demands a 24-hour report for an actively exploited vulnerability but sets no remediation deadline, while exploitation now measures in hours. Four flaws run through the text. Compliance changes shape; Europe's condition of dependency stays the same.
The Leopard
The ball goes on. (The Leopard - 1967)

"Se vogliamo che tutto rimanga come è, bisogna che tutto cambi." Europe changes its regulatory framework. It does not change its condition of dependency.


On March 19, 2026, the European Union Agency for Cybersecurity (ENISA) published a technical advisory on secure use of package managers¹. The document covers risks associated with third-party software dependencies: malicious packages, compromised maintainers, typosquatting, dependency confusion. It recommends dependency tracking, SBOM generation, provenance verification, continuous monitoring and remediation documentation.

This guide arrives six months before the first binding deadline of the Cyber Resilience Act. On September 11, 2026, manufacturers of digital products sold in Europe must report actively exploited vulnerabilities within 24 hours, provide full notification within 72 hours, and submit a final report within 14 days². Penalties reach €15 million or 2.5% of global annual turnover. Regulators can withdraw non-compliant products from the European market³.

I examined each recommendation in the ENISA guide, then tested each against incidents documented between January and April 2026. The guide is sincere, competent and methodical. Its implicit assumptions are wrong.

What the CRA builds

The CRA imposes four substantive obligations on manufacturers of products with digital elements. First, a documented and continuously updated cybersecurity risk assessment. Second, the absence of known exploitable vulnerabilities at the time of market placement. Third, a machine-readable Software Bill of Materials (SBOM). Fourth, free security updates for at least five years⁴.

The intent is clear: hold publishers accountable. Kill the "ship and forget" model. Force a baseline hygiene that the industry never adopted voluntarily. ENISA's NIS Investments 2025 report documents the scale of the gap: 28% of organisations take more than three months to remediate critical vulnerabilities (51% among SMEs), and 30% have not conducted any security assessment in the past twelve months (63% among SMEs)⁵. The CRA is right to force the issue.

The ENISA guide translates these obligations into operational practices for dependency management. The Open Regulatory Compliance Working Group (ORCWG) summarises the stakes: full supply chain compliance has never been required before the CRA⁶. The regulation impacts every layer of that chain, including open source dependencies embedded in commercial products. An ANSSI market study published in April 2026 confirms the demand-side diagnosis: current regulatory frameworks remain high-level, providing limited operational guidance on how to implement their requirements⁶ᵇ.

The calendar ahead is dense. By June 11, 2026, Member States must have designated their notifying authorities and published the procedures for assessing conformity assessment bodies. The bodies themselves will follow only afterwards: the regulation targets a sufficient number of notified bodies only by December 11, 2026, and states that the aim is to avoid bottlenecks to market entry⁷. On September 11, reporting obligations enter into force. On December 11, 2027, all obligations become applicable. Manufacturers will therefore have to reach compliance before the apparatus meant to assess them is guaranteed operational. For a regulation that entered into force on December 10, 2024, the pace is demanding.

So far, the reasoning holds. The CRA creates the framework. ENISA translates it into practices. Organisations tool up. Auditors verify. The problem begins when these practices are confronted with the threat they are supposed to cover.

The composition flaw

Verifying package provenance, validating cryptographic signatures, monitoring dependency behaviour: the ENISA guide recommends these controls. They assume that a malicious package is distinguishable from a legitimate one if the right procedures are applied.

On March 13, 2026, Socket Security published its analysis of the GlassWorm campaign: 72 malicious extensions on the Open VSX marketplace, the marketplace used by open source IDEs (VSCodium, Eclipse Theia)⁸. The distinguishing feature: the extensions themselves are clean. The malicious code is buried in a transitive dependency, a dependency of a dependency. The extension satisfies every control the ENISA guide recommends. The signature is valid. The maintainer is authentic. The metadata is correct. The malicious behaviour emerges from the composition, not the component.

Two days later, StepSecurity documented ForceMemo: hundreds of Python repositories on GitHub compromised through dormant account takeover, followed by a force-push that rewrites Git history⁹. The malicious code replaces the legitimate code in the source repository. The dependency tree points to the same identifier, the same URL, the same package name. Only the content has changed, and the history has been erased.

Six weeks later, the pace accelerated. Between April 21 and 23, 2026, three supply chain attacks hit npm, PyPI and Docker Hub simultaneously¹⁰. The official Checkmarx KICS Docker images were compromised. A self-propagating worm (CanisterSprawl) infected npm packages via a postinstall hook, stole the developer's publish tokens, injected a payload into every package the victim could publish, and jumped to PyPI if a PyPI token was found on the machine. The command-and-control channel used an ICP (Internet Computer Protocol) canister, resistant to conventional takedowns. On April 30, PyTorch Lightning fell: versions 2.6.2 and 2.6.3 compromised on PyPI, 31,000 GitHub stars, millions of downloads per month¹¹.

CanisterSprawl marks a mutation. The worm does not compromise a component: it compromises a maintainer, then uses that maintainer's credentials to publish malicious versions of legitimate packages, through official channels, with correct signatures. The victim project's SBOM will be accurate. Provenance will be verified. The package will be malicious. And it will have crossed registry boundaries, from npm to PyPI, in a movement the ENISA guide does not model, since it reasons registry by registry.

On May 12, 2026, the Mini Shai-Hulud campaign crossed a further threshold: the compromise of TanStack, Mistral AI and UiPath (over 160 npm and PyPI packages) came with the first documented forgery of SLSA Build Level 3 provenance attestations, the most demanding integrity standard currently deployed¹¹ᵇ. Provenance is no longer merely insufficient, it can now be falsified.

The guide treats dependency security as a component problem. Attackers have shifted it to the level of composition. Compliance targets the parts. The threat targets the assembly.

Thirteen months before disclosure

Within 24 hours of discovering an actively exploited vulnerability, the CRA requires a report. This timeline assumes that discovery precedes exploitation, or at minimum follows it closely. The data tells a different story.

In December 2025, Huntress observed an intrusion using the MAESTRO toolkit: three VMware ESXi zero-days chained (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226) enabling escape from a virtual machine to the hypervisor¹². The toolkit's development paths contain a date of February 2024 and simplified Chinese strings ("全版本逃逸--交付", "all version escape, delivery"). The toolkit was developed as a zero-day exploit more than a year before Broadcom's public disclosure in March 2025. It supports 155 ESXi builds, from version 5.1 to 8.0. During this thirteen-month window, no SBOM, no monitoring, no reporting procedure would have produced any signal, since the vulnerabilities did not exist in any public database.

MAESTRO is not an isolated case. Mandiant's M-Trends 2026 report, based on over 500,000 hours of incident response investigations in 2025, measures an average time-to-exploit of -7 days: exploitation routinely occurs before the patch is released¹³. 67% of exploited CVEs in 2026 are zero-days¹⁴. The CRA imposes a 24-hour reporting obligation, calibrated for a world in which vulnerabilities are discovered by defenders and published before being massively exploited. That world no longer exists for state or state-adjacent actors. It no longer exists for cybercriminals either: the hand-off time between an initial access broker and a ransomware affiliate has dropped to 22 seconds¹³.

Verizon's 2026 DBIR, published on May 19 and based on more than 31,000 incidents across 145 countries, records a shift. For the first time in the report's nineteen-year history, vulnerability exploitation becomes its leading initial access vector, ahead of stolen credentials and phishing: 31% of breaches, up by a little over half year on year¹³ᵇ. The same report measures a median time to full remediation of 43 days in 2025, against 32 the previous year, and only a quarter of the actively exploited flaws in CISA's catalogue patched within the year¹³ᵇ. The 24-hour obligation accelerates the declaration to the authority, not the defense of the product.

But the tempo flaw also operates in the other direction: too many vulnerabilities, too fast.

On February 5, 2026, Anthropic announced that Claude Opus 4.6 had discovered over 500 critical vulnerabilities in production open source code¹⁵. In a single analysis campaign. On May 13, the UK AI Security Institute published an update to its cyber evaluations: the length of tasks that frontier models complete autonomously is doubling every 4.7 months since late 2024, and the two most recent models tested exceed even that trend¹⁶. A recent Claude Mythos Preview checkpoint solves both of the AISI's cyber ranges, including a 32-step corporate compromise scenario (estimated at 20 hours of human work) in 6 of 10 attempts, and a previously unsolved industrial scenario in 3 of 10 attempts. Reconnaissance, exploitation, lateral movement, privilege escalation and takeover chain together without human intervention. AISI notes that the ranges include no active defenders, which limits the result to weakly defended targets. But that is precisely the profile of a significant share of the European economic fabric subject to the CRA.

Twenty-four hours to report an actively exploited vulnerability. When the full attack chain executes in hours and vulnerability discovery scales industrially, the reporting deadline becomes longer than the exploitation window. NVD CVE submissions rose 263% between 2020 and 2025, and the first quarter of 2026 is up by a third on the same period in 2025¹⁷. With models capable of finding hundreds of flaws in hours and chaining them into complete attack scenarios, the CRA's reporting obligations will be pressured by volume and speed simultaneously. The CRA was calibrated for a pre-AI world of vulnerability hunting. That calibration is already obsolete.

An infrastructure under construction

Monitoring dependency vulnerabilities, correlating with CVE databases, maintaining an up-to-date inventory: these processes depend on infrastructure whose foundations are unstable.

Since 2024, the NIST National Vulnerability Database (NVD) has been accumulating processing delays. In April 2025, NIST marked "Deferred" all CVEs published before January 1, 2018, abandoning retroactive enrichment for tens of thousands of entries¹⁸. Jon Boyens, acting chief of the Computer Security Division, wants to "stop using the word backlog"¹⁹. The MITRE CVE programme, funded at $57.8 million per year by the US federal government, narrowly avoided funding interruption twice in 2025²⁰. MITRE laid off 440 employees and cancelled $28 million in contracts²¹.

Europe is building. ENISA's European Vulnerability Database (EUVD) has been in beta since May 2025. The GCVE (Global CVE) from Luxembourg's CIRCL, launched in January 2026, offers a decentralised model with 25 public sources²². VulnCheck's analysis of the EUVD identifies over 50,000 CVEs missing from the main API²³. ENISA became a CVE Root CNA in November 2025, and at VulnCon26 in Scottsdale, on April 14, 2026, the agency confirmed its onboarding by CISA to become a Top-Level Root CNA, the third in the world after CISA and MITRE²⁴. The ambition is clear. Eighty of the world's five hundred CNAs are European, and operational ramp-up is still in progress²⁴.

The same agency made another choice in the spring of 2026. On June 2, Anthropic expanded Project Glasswing to roughly one hundred and fifty organisations across more than fifteen countries, and admitted ENISA into it²⁴ᵇ. Glasswing grants access to Claude Mythos Preview, a private frontier model its developer does not sell, to find and fix vulnerabilities in critical software. The agency that publishes the package-manager guide, that sets the practices European manufacturers will have to follow, and that aspires to become the third root authority of the CVE system, relies for its own discovery capacity on an American provider. The infrastructure flaw runs deeper than the calendar. The capacity the CRA presupposes exists; Europe buys it from an American provider rather than producing it²⁴ᶜ.

Eleven days later, on June 12, 2026, a Commerce Department directive made any transfer of Anthropic's frontier cyber models to a non-US person subject to prior governmental approval, on national security grounds²⁴ᵈ. The access a European agency had just obtained now runs through an American state gate.

The Single Reporting Platform (SRP), mandated by the CRA to centralise vulnerability notifications, must be operational on September 11, 2026, the same day reporting obligations enter into force. As of April 30, 2026, the platform is not operational. The procurement (ENISA/2025/OP/0001, four-year contract) closed in March 2025. The contractor has not been publicly disclosed. The testing phase has not begun²⁵. Manufacturers will therefore report vulnerabilities through a platform they will not have been able to test, correlating with databases of which the most complete (the NVD) is in crisis and the youngest (the EUVD) is incomplete.

The ENISA guide prescribes processes that depend on infrastructure it does not mention. I have documented this dependency in detail²⁶. The CRA creates obligations for European manufacturers. It does not create the data infrastructure necessary for those obligations to be fulfilled within the timelines it imposes.

The invisible layer

The ENISA guide covers packages published in registries (npm, PyPI, Maven, NuGet). It does not cover code that enters projects without passing through a package manager.

Developer surveys in 2025 converge at 84-91% adoption of AI code generation tools (JetBrains: 85%, Stack Overflow: 84%, DX: 91%)²⁷. This code enters repositories with the same treatment as manually written code: same commit, same metadata, no distinction. 62% of security practitioners surveyed have no way to know where LLMs are being used in their organisation²⁸. Generated code contains vulnerabilities in 45% of cases, a rate that has been stable for two years despite model evolution²⁹. Fewer than half of developers review AI code before committing it³⁰.

The CRA requires an SBOM. The AI Act imposes transparency obligations on AI models. Neither text covers the question: was this code generated by an AI, with which model, from which prompt, and were the dependencies it imports chosen by a human or suggested by the model? Traditional SBOMs do not capture this layer. The concept of an AI-BOM (AI Bill of Materials) is beginning to emerge in the literature, but no standard has stabilised³¹.

A tool like git-memento attempts to address traceability by attaching AI sessions to commits via git notes³². The approach is voluntary and declarative. Nothing prevents a developer from copy-pasting AI code without declaring it. The integrity control is not technical, it is procedural. It is the code equivalent of a self-certification form.

The ENISA guide optimises security for a supply chain of which a growing share escapes the controls it defines. Dependencies chosen by an AI agent (Claude Code, Copilot, Codex) do not pass through the selection workflow the guide describes. They enter the project at generation time, without provenance review, without maintainability assessment, without licence verification.

What I know and what I don't

The CRA corrects a real gap. Before December 2024, no European text required software manufacturers to maintain an inventory of their components, report exploited vulnerabilities or provide free patches. The CRA imposes a floor. That floor did not exist. Its existence is progress. And the ENISA guide faithfully translates these obligations into operational practices. Each recommendation is reasonable taken in isolation. Verifying a package's provenance is better than not verifying it. Generating an SBOM is better than not having one.

The four flaws I have identified (composition, tempo, infrastructure, invisible layer) are not fixable by amending the CRA. The composition flaw is a property of modular systems: the security of components does not guarantee the security of the assembly. The tempo flaw follows from the economics of vulnerability: offensive actors hold a temporal advantage that regulation cannot reduce by decree. The infrastructure flaw is geopolitical: Europe is building its own capabilities (EUVD, GCVE, TL-Root candidacy) but operational capacity does not yet match ambition, and the CRA's calendar will not wait. The invisible layer is technological: AI code enters projects through channels the CRA did not foresee.

What I don't know: how fast these flaws will manifest operationally. The first test will come on September 11, 2026, when reporting obligations enter into force. If a CanisterSprawl-type campaign compromises a maintainer whose packages are embedded in products sold in Europe, manufacturers will need to determine whether they are affected, assess the reachability of the vulnerability in their implementation and produce a report within 24 hours, through an SRP platform they will have had only weeks to test. Manufacturers who treated the CRA as a checklist will discover that the checklist does not cover the scenario.

One question remains open: will European alternatives reach operational maturity before dependency on American infrastructure becomes critical? ENISA is gaining ground in the CVE system. The trajectory of NIST and MITRE in 2025 and 2026 suggests continued degradation²⁶. Europe is building. The CRA's calendar runs faster than it does.

Compliance as a floor

The CRA produces verifiable compliance. Auditors will be able to confirm the presence of an SBOM, the existence of a monitoring process, the documentation of a reporting procedure. These verifications assess the existence of processes, not their capacity to detect the actual threat.

An organisation can be sincerely compliant with the CRA, have implemented every recommendation in the ENISA guide, and remain exposed to all four flaws I have described. Compliance and protection are not synonymous. They never have been, but the CRA risks reinforcing the confusion by creating a framework whose apparent completeness masks its blind spots.

ENISA's NIS Investments 2025 report notes that 70% of organisations cite regulatory compliance as the primary driver of cybersecurity investment⁵. If CRA compliance becomes the objective rather than the starting point, those investments will produce paper, not resilience.

For organisations selling digital products in Europe, the CRA imposes a floor. It must be respected. But treating that floor as a ceiling would be the most expensive mistake a CISO could make in 2026. The threats documented in this article operate above the threshold the CRA defines. Real protection begins where compliance ends: in systems architecture, in reducing critical dependencies, in the ability to operate when the databases and standards relied upon degrade or disappear.

Europe changes its forms. The condition that makes its organisations vulnerable remains the same.


Eighteenth article in a series on the structural flaws of Western cybersecurity:


Notes and sources

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

² Cyber Resilience Act, Regulation (EU) 2024/2847, Article 14 — Reporting obligations: early warning 24h, full notification 72h, final report 14 days (actively exploited vulnerabilities) or 1 month (severe incidents). Reporting applicable: September 11, 2026. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

³ CRA, Article 64 — Penalties up to €15,000,000 or 2.5% of global annual turnover. Market withdrawal possible for non-compliant products. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

⁴ CRA, Articles 13 and 23 — Essential requirements: risk assessment, absence of known exploitable vulnerabilities, machine-readable SBOM, free security updates for minimum 5 years. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

⁵ ENISA, "NIS Investments 2025" — 28% of organisations take over 3 months to remediate critical vulnerabilities (51% SMEs). 30% have not conducted any security assessment in 12 months (63% SMEs). 70% cite regulatory compliance as the primary investment driver. https://www.enisa.europa.eu/publications/nis-investments-2025

⁶ ORCWG (Open Regulatory Compliance Working Group) — Full supply chain compliance has never been required before the CRA. https://orcwg.org/cra/

⁶ᵇ ANSSI / Wavestone, "S-SDLC / DevSecOps: What are the current and future challenges for the European market?" (April 2026, v1.0) — 13 vendors and 9 organisations interviewed. Finding: current regulatory frameworks remain high-level, providing limited operational guidance on implementing their requirements. 100% of vendors integrate AI, but "current AI capabilities in DevSecOps remain limited" relative to expectations.

⁷ European Commission, "Cyber Resilience Act — Implementation" (updated April 23, 2026) — Timeline: June 11, 2026 (designation of notifying authorities and publication of procedures for assessing conformity assessment bodies, Chapter IV), September 11, 2026 (reporting obligations, Article 14), December 11, 2026 (target of a sufficient number of notified bodies to avoid bottlenecks to market entry), December 11, 2027 (full application). CRA guidance published March 3, 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" (March 13, 2026). https://socket.dev/blog/open-vsx-transitive-glassworm-campaign

⁹ StepSecurity, "ForceMemo: Hundreds of GitHub Python Repos Compromised via Account Takeover and Force Push" (March 2026). 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" (April 23, 2026) — Checkmarx KICS Docker images compromised, self-propagating CanisterSprawl worm via postinstall hook, exfiltration to an ICP canister. 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" (April 22, 2026). https://www.theregister.com/2026/04/22/another_npm_supply_chain_attack/

¹¹ Socket Security, "lightning PyPI Package Compromised in Supply Chain Attack" (April 30, 2026) — PyTorch Lightning (31,000 GitHub stars, millions of downloads/month), versions 2.6.2 and 2.6.3 compromised. Payload similar to the Shai-Hulud family. Flagged by Socket's AI scanner within 18 minutes. https://socket.dev/blog/lightning-pypi-package-compromised

¹¹ᵇ Tenable, "Mini Shai-Hulud Supply Chain Attack CVE-2026-45321 FAQ" (May 21, 2026) — TeamPCP, Mini Shai-Hulud campaign: TanStack, Mistral AI, UiPath, 160+ npm/PyPI packages compromised. First documented forgery of SLSA Build Level 3 attestations. OIDC token extraction from GitHub Actions runner memory. Persistence hooks targeting AI code agents and IDEs. 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" (May 12, 2026). https://orca.security/resources/blog/tanstack-npm-supply-chain-worm/

¹² Huntress, "The Great VM Escape: ESXi Exploitation in the Wild" (January 7, 2026) — MAESTRO toolkit: three chained VMware ESXi zero-days (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226). Development date February 2024, Broadcom disclosure March 2025. 155 ESXi builds supported (5.1 to 8.0). Initial access via compromised SonicWall VPN. https://www.huntress.com/blog/esxi-vm-escape-exploit

¹³ Mandiant / Google Cloud, "M-Trends 2026" (March 23, 2026) — 500,000+ investigation hours in 2025. Average time-to-exploit: -7 days (exploitation before patch release). IAB-to-ransomware hand-off: 22 seconds (vs 8+ hours in 2022). Median dwell time: 14 days. Exploits = leading initial access vector for the 6th consecutive year (32%). https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026

¹³ᵇ Verizon, "2026 Data Breach Investigations Report" (May 19, 2026) — 31,000+ incidents, 22,000+ confirmed breaches, 145 countries. Vulnerability exploitation became the report's leading initial access vector (31%, +55% year on year), ahead of stolen credentials and phishing, for the first time in nineteen years. Disclosure-to-exploit window compressed "from months to hours" by AI. Median time to full remediation: 43 days in 2025 (32 days in 2024). 26% of CISA KEVs patched over the year. Period covered: Nov. 2024 - Oct. 2025, prior to 2026 AI capabilities. https://www.verizon.com/business/resources/reports/dbir/

¹⁴ Hive Security / VulnCheck (April 2026) — 55% of zero-days exploited within one week of disclosure. 28.96% of KEVs exploited on or before CVE publication day. 67.2% of exploited CVEs in 2026 are zero-days (vs 16.1% in 2018). https://hivesecurity.gitlab.io/blog/from-cve-to-rce-in-hours-attack-timeline-2026/

¹⁵ Anthropic announcement, February 5, 2026 — Claude Opus 4.6: over 500 critical vulnerabilities discovered in production open source code. See in this series: "Status: clean."

¹⁶ AI Security Institute (UK), "How fast is autonomous AI cyber capability advancing?" (May 13, 2026) — Autonomous cyber capability doubling rate: 4.7 months since late 2024, Mythos Preview and GPT-5.5 exceed the trend. Recent Mythos Preview checkpoint: TLO solved 6/10 (vs 3/10 in April), Cooling Tower solved 3/10 (never solved before). Near-100% success on the narrow task suite (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" (April 15, 2026) — +263% CVE submissions 2020-2025, +33% Q1 2026 vs Q1 2025. Three prioritisation criteria: CISA KEV, federal software, EO 14028. Everything else classified "Not Scheduled." See in this series: "Pitch Black" for the full analysis of the eight NIST degradation vectors. https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth

¹⁸ NIST — CVEs prior to January 1, 2018 marked "Deferred" (April 2025). Retroactive enrichment abandoned.

¹⁹ Cybersecurity Dive, "NIST is rethinking its role in analyzing software vulnerabilities" (January 23, 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 — CVE programme: $57.8M/year federal funding. https://swarmnetics.com/blog/mitre-cve-program-safe-until-early-2026-but-what-happens-then/

²¹ CyberScoop — MITRE: 440+ employees laid off, $28M in contracts cancelled. https://cyberscoop.com/cve-program-funding-crisis-cve-foundation-mitre/

²² EUVD: beta since May 2025 (EUVD-2025-XXXXX identifiers). GCVE: launched January 2026 by CIRCL (Luxembourg), 25+ public sources, decentralised model. https://euvd.enisa.europa.eu/ https://www.infosecurity-magazine.com/news/global-cybersecurity-vulnerability/

²³ VulnCheck, "Does ENISA EUVD live up to all the hype?" (May 2025) — 50,000+ CVEs missing from the main API. https://www.vulncheck.com/blog/enisa-euvd

²⁴ Infosecurity Magazine, "ENISA Seeks Top-Tier Status in CVE Program" (April 25, 2026) — VulnCon26, Scottsdale. Nuno Rodrigues Carvalho (ENISA) confirms TL-Root CNA onboarding by CISA. Target: "2026 or early 2027." Process described as "uncharted territory." ~80 European CNAs out of 500+ worldwide. https://www.infosecurity-magazine.com/news/enisa-europe-seeks-top-level-root/

²⁴ᵇ Anthropic, "Expanding Project Glasswing" (June 2, 2026) — Expansion to ~150 organisations across 15+ countries (on top of the ~50 initial partners of April 2026), including power, water, healthcare and telecommunications operators. ENISA admitted to the programme. Access to Claude Mythos Preview for vulnerability discovery and remediation. Model not commercialised. https://www.anthropic.com/news/expanding-project-glasswing Cybersecurity Dive, "Anthropic shares Mythos with 150 more organizations, including critical infrastructure operators" (June 2, 2026) — Confirms ENISA's admission to Project Glasswing. https://www.cybersecuritydive.com/news/ai-anthropic-claude-mythos-project-glasswing-expand/821714/

²⁴ᶜ On the reading of Glasswing as capacity capture under selective sovereign adoption, see in this series: "The Conversation." On the discovery/remediation bottleneck of the Mythos model (530 flaws disclosed, 75 fixed), see: "Status: clean."

²⁴ᵈ US Department of Commerce, export directive — letter from Secretary Howard Lutnick to Anthropic CEO Dario Amodei, access disabled on June 12, 2026, Anthropic compliance confirmed on June 13, 2026. Any export, re-export or domestic transfer of Claude Fable 5 and Claude Mythos 5 to a non-US person is subject to prior governmental approval. Global suspension, including Amazon Bedrock, with no migration window. Stated rationale: the models' cyber capabilities, national security. For the weaponized interdependence reading, see in this series: "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" (June 13, 2026). https://cryptobriefing.com/anthropic-mythos-models-us-export-controls/

²⁵ ENISA, Single Reporting Platform FAQ — SRP operational target: September 11, 2026. Testing phase before launch (not yet started as of April 30, 2026). Procurement ENISA/2025/OP/0001 (4-year contract), closed March 2025. Contractor not publicly disclosed. https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp European Commission, "CRA — Reporting obligations" (updated April 23, 2026). https://digital-strategy.ec.europa.eu/en/policies/cra-reporting

²⁶ See in this series: "Pitch Black" (topological dependency on American infrastructure, eight simultaneous vectors hitting NIST), "The vulnerability of vulnerability management" (NVD), "European dependency on American standards."

²⁷ JetBrains, "State of Developer Ecosystem 2025" — ~85% regular AI usage, 62% relying on at least one coding assistant or agent. Stack Overflow, "2025 Developer Survey" — 84% using or planning to use AI tools, 51% daily. DX Q4 2025 (135,000+ developers) — 91% adoption, 22% of merged code AI-authored. https://www.jetbrains.com/lp/devecosystem-2025/ https://survey.stackoverflow.co/2025

²⁸ See in this series: "Status: clean" — Detailed sources and data on AI code.

²⁹ See in this series: "Status: clean" — AI code vulnerability rate stable at ~45%. Veracode: "completely flat" for two years.

³⁰ See in this series: "Status: clean" — Fewer than 50% of developers review AI code before committing.

³¹ AI-BOM: emerging concept, no stabilised standard. CycloneDX and SPDX SBOMs do not capture AI provenance of source code.

³² git-memento — Open source tool attaching AI sessions to commits via git notes. "Gate" mode blocking PRs without attached AI session. Voluntary and declarative architecture. https://github.com/mnott/git-memento