When the Code Stays Clean and Trust Collapses Anyway

Why Europe’s third way needs sovereign open-source assurance, and what the openSUSE community, the SUSE ecosystem and the businesses built on them should do about it

Accompanying article to the openSUSE Conference 2026 keynote by Hans de Raad (OpenNovations) - “Open Source Won Distribution. Now It Must Win Assurance.”

---

Most writing about European digital policy starts in Brussels. This article starts in a package manager, because that is where the abstraction becomes real and where the openSUSE community already lives.

In May 2026, a project called GSD, short for “Get Shit Done,” became one of the more instructive open-source episodes of the agentic-AI era. It is worth dwelling on, not because it was the most dramatic security event of the year, but because it was the clearest. GSD was a genuinely useful tool. It was an open-source framework that sat on top of Claude Code and around a dozen other AI coding runtimes and solved a real and widely felt problem: the degradation in quality that sets in when an AI coding session fills its context window, the phenomenon its own documentation called context rot. It worked by breaking development into phases and running each in a fresh agent context, and by early May 2026 it had earned roughly 59,000 stars on GitHub, 138 contributors, and adoption across the kind of teams who do serious work with AI assistance. People installed it because it helped, which is the only reason anyone installs anything.

Then the trust around it collapsed. The original maintainer became unreachable on 1 April 2026, the associated social accounts were deleted, and a Solana-based token tied to the project, the $GSD token, was publicly linked to a rug pull around 21 to 22 May 2026. The community responded within a day, forking the codebase to a continuation called get-shit-done-redux, preserving the MIT-licensed code with all of its branches and tags, stripping the token and social references, and republishing under a new package scope. The original repository was locked. None of this is in dispute; it is documented across the project’s own pages, the community fork, and the coverage that followed.

What makes GSD instructive is what the security review found, and what it did not. The fork team published its own security audit, and an independent reviewer went through the same code. Both agreed on the headline: there was no active backdoor and no exfiltration payload in the reviewed source, and the listed security tests passed. If your mental model of open-source risk is “scan the code for malware,” GSD passed. And yet the independent review reached a sharper and more uncomfortable conclusion. It found the community audit honest but incomplete, and it identified the single highest risk in the entire situation as something that was not in the code at all: the previous maintainer still held the keys to publish to the original package on the registry. Anyone who kept installing from the original package name was trusting a person who had already demonstrated a willingness to walk away from the project and the community without warning, and the relevant question was not whether the package was malicious today but who could push an update to it tomorrow. The review went further still, naming structural gaps the audit had downplayed: the tool handed its AI agents broad shell and filesystem access and then relied on guardrails that warn but never block, emitting their warnings into the very context window that a prompt-injection attack would occupy.

This is the pattern worth naming, because it is the pattern the rest of this article is about. Call it trust-state inversion. It is the situation where the visible artifact still looks acceptable while the trust relationships around it no longer do: maintainer continuity, registry authority, release governance, financial incentives, package ownership, update channels, and the downstream estate that has to be cleaned up afterwards. For a passive library that would already matter. For an agentic AI development tool that can read files, write files, execute commands, install dependencies and rewrite a project’s lockfile, it matters a great deal more, because the blast radius of a hostile update is no longer a bad formatting function but the developer’s source code, credentials, SSH keys, environment files and continuous-integration secrets.

GSD also shows why the old model of open-source risk is no longer sufficient on its own. A vulnerability scanner answers one class of question: is a known-vulnerable component present. A source review answers another: was suspicious code found in what was inspected. Both still matter. Neither answers who can publish the next version, whether release authority is resilient, whether the project has a succession plan, whether financial incentives have quietly distorted governance, or whether an AI tool can add a dependency before a human notices. Those are the questions that decide whether a dependency is trustworthy, and they are not questions a scanner is built to ask.

It is worth being precise about what is and is not established here, because the discipline of being precise is itself part of the lesson. The amount of money involved in the token event was reported by community and crypto sources at roughly half a million dollars, but the most-cited coverage stated plainly that there was no confirmed figure in public reporting at the time, so the number should be treated as an estimate rather than a fact. The creator’s public identity is well documented across many sources that predate the incident, so naming the project’s creator is not an accusation, but the characterisation of the token event as deliberate fraud by that person is a community classification rather than a proven legal finding, and the careful formulation is that the event is publicly linked to the maintainer rather than proven against him. The fork maintainer himself modeled exactly this restraint. His continuity announcement separated what was known from what was inferred and stated, in plain words, that absence of news is not the same as evidence, declining to assert intent he could not prove and inviting anyone with contrary evidence to bring it. That is what producing trustworthy evidence under pressure looks like, and it is a better illustration of the discipline this article will argue for than any abstract definition.

There is a constructive ending, too, and it deserves to be told alongside the failure. The community fork did not stop at rebranding. It added package-legitimacy checks through a tool that screens dependencies across the major registries using signals such as registry age, download count, source-repository linkage and naming distance to popular packages, with a fallback that forces a human checkpoint before any install if the checker is unavailable. The downstream plugin packaging moved installation inside the editor session rather than the host shell and bundled its own copy of the tooling, specifically to remove the global-install trust dependency. In other words, the community looked at the gaps the independent review had surfaced and built defences against them. That is the open-source ecosystem doing what it does best, in public, under scrutiny.

This is the right place to begin a discussion of the Cyber Resilience Act, the NIS2 Directive, the revision of the Cybersecurity Act and the EU Tech Sovereignty Package, for an openSUSE audience, because GSD is not really a story about one tool. It is a story about what open-source assurance is up against in 2026. And the point is not that GSD is itself automatically a matter for the CRA or NIS2 or the AI Act. The point is that the toolchain which builds regulated and customer-facing software has become part of the evidence chain. If an agentic tool contributed to validated software, to security evidence, to product code, to test artifacts or to a regulated AI system, a mature organisation should be able to say which tool and which version was used, what it touched, what it changed, what human review occurred, and how the dependency risk was assessed. That is not bureaucracy. It is traceability, and the rest of this article is about why Europe is now building an entire policy stack on top of that single idea.

The same lesson in the classic distribution chain

GSD is the agentic-AI restatement of a lesson the open-source world already learned the hard way through xz-utils. The two cases are worth holding side by side, because together they define the problem more completely than either does alone.

The xz backdoor, catalogued as CVE-2024-3094 and rated at the maximum severity, was discovered in March 2024 by a Microsoft engineer who noticed that secure-shell logins on a test machine were running about half a second slower than they should and spent several hours tracing the anomaly. What he found was the culmination of a campaign that had run for roughly two and a half years. A contributor operating under a pseudonym had built credibility in the xz project through legitimate work, while a set of sock-puppet accounts applied steady pressure on the project’s lone, overextended maintainer to add a co-maintainer. Once granted that authority, the attacker introduced a backdoor, and the way it was introduced is the part that matters for a distribution audience. The malicious code was not in the public source repository. It existed only in the release tarballs, in a modified build script that the attacker, now a trusted maintainer, produced and signed. The backdoor targeted the specific way that several Linux distributions link the compression library into the secure-shell daemon through systemd, and it would have given its author the ability to run code remotely on a very large number of machines. It was caught before it reached stable distributions, and only because one engineer chased a latency anomaly that he had every reason to ignore.

The xz incident showed that a distribution’s trust machine can be attacked through the release path, by turning the gap between what people review in source control and what they actually ship in a release artifact into a hiding place. GSD showed that the same trust machine can be bypassed entirely, when developers pull high-privilege tooling straight from a registry or a code-hosting platform into their local workflow, outside the curation and signing that a distribution provides. In the first case the artifact was poisoned. In the second the publish channel and the governance context around it became unsafe to rely on. Both point to the same conclusion, and it is the conclusion this whole article turns on: open-source assurance is no longer only about scanning code. It is about governing the chain of authority around the code.

It is worth saying clearly what a Linux distribution actually is, because the openSUSE audience knows this in their hands but the wider readership often does not, and the policy world almost never does. A distribution is not a pile of packages. It is a trust machine. It takes thousands of upstream components, each maintained by different people under different conventions in different parts of the world, and it reviews them, patches them, builds them in a controlled build service, signs them, publishes them through repositories and mirrors, and updates them on a managed lifecycle, turning a sprawl of independent projects into a coherent operating environment that a downstream user can install and rely on without ever meeting an upstream maintainer. The Open Build Service, reproducible-build work, package signing, security advisories, and long-term-support branch policy are not compliance theatre invented for a regulation. They are the assurance infrastructure of a distribution, built over decades because distributions learned the hard way that trust has to be manufactured, not assumed. This matters enormously for what follows, because much of what the Cyber Resilience Act will ask manufacturers to do, a good distribution already does. The task is less to invent new compliance machinery and more to make existing engineering evidence legible to the legal, procurement and conformity-assessment systems that are now asking to see it.

The chain of authority that now needs governing includes the classic layers of an open-source supply chain: source repositories, maintainers, package managers, build systems, mirrors, signing keys, software bills of materials, advisories, vulnerability databases and distribution channels. It also now includes a newer layer that GSD made visible. Agentic AI coding tools can recommend packages, run install commands, edit lockfiles, and normalise dependency choices that no human has properly examined. The early warning sign already has a name, slopsquatting, which describes attackers registering plausible package names that an AI system is prone to hallucinate and suggest, so that a developer who accepts the suggestion installs an attacker’s code. The consequence is that the dependency graph is no longer only what developers deliberately chose. It is increasingly what their tools suggested, installed, or made easy to accept. This is what we are up against, and it is the reason the evidence layer, which the second half of this article is about, now matters more than it ever has.

The sausage factory and the view from orbit

Against that background, the European policy landscape can look almost comically complicated. CRA. NIS2. CSA. CADA. Chips Act 2.0. The Open Source Strategy. The Digital Commons EDIC. The ENISA Single Reporting Platform. M/606. EUCC. EUCS. EUVD. The Open Regulatory Compliance Working Group. STAN4CR. CYBERSTAND. To anyone not paid to follow the Brussels machinery, this is alphabet soup, and the natural reaction is to assume that the people producing it have lost the thread.

The old line about laws and sausages is useful here, and you should use it without cynicism. Up close, policy formation is genuinely messy. It is consultations and compromises and impact assessments and lobbying and standardisation requests and delegated acts and guidance documents and implementation deadlines and budget fights and late corrections. From the floor of the factory it looks like disorder. But the disorder is not evidence of incoherence. It is evidence of asynchrony, and the asynchrony has a cause. Policy does not move in lockstep because reality does not move in lockstep. Different crises expose different failures at different moments, and each failure produces its own instrument on its own timetable.

The pattern becomes legible when you line up the crises against the responses. Heartbleed, in 2014, exposed the underfunding of critical cryptographic infrastructure: a library securing a large fraction of the web was being maintained on roughly two thousand dollars a year in donations by a handful of people, one of them full-time. Log4Shell, in December 2021, exposed the operational blast radius of a single widely embedded open-source component, a logging library maintained by volunteers under a foundation, whose flaw set off a global scramble and a long tail in which a large share of affected systems were still vulnerable many months later. The xz backdoor, in 2024, exposed maintainer sustainability and release-path trust. GSD, in 2026, exposed registry control, agentic-AI privilege and maintainer-trust collapse. Cloud dependency exposed Europe’s strategic exposure to a small number of non-European providers. Artificial intelligence and semiconductors exposed capacity gaps. Each of these produced or accelerated a policy response, and the responses arrived in the order the crises did, which is why they look unrelated.

From higher orbit, they resolve into a single structure that is worth stating as plainly as possible, because it is the spine of the entire argument. Europe is trying to turn digital dependency into a trust market. The Cyber Resilience Act creates product accountability. NIS2 creates organisational resilience. The revision of the Cybersecurity Act aims to build certification, cyber-posture assurance and trusted-supplier logic. The Tech Sovereignty Package tries to build capacity through chips, cloud, AI infrastructure, open source, energy planning, procurement and funding. The standardisation request M/606 tries to translate legal requirements into harmonised standards that produce repeatable evidence. The Open Source Strategy names open source as a pillar of technological sovereignty. The Digital Commons EDIC and the Sovereign Tech funding models point toward maintenance and stewardship as public infrastructure. And public procurement turns the whole strategy into market demand. Seen that way, the alphabet soup is not random. It is a layered attempt to answer one question: how can Europe build and operate digital infrastructure that is open, secure, interoperable, competitive and trustworthy under pressure.

The instruments are asynchronous. The direction of travel is not. That single sentence is worth more to an audience than any acronym-by-acronym walkthrough, because it converts a sense of chaos into a sense of architecture, and architecture is something you can engage with.

Europe’s third way is a trust market

Europe’s digital strategy is often framed as a binary choice: depend on American hyperscalers or risk exposure to Chinese state-backed infrastructure. That framing is too narrow, and it concedes too much. Europe’s stronger idea is a third way, built on open standards, open source, interoperability, rights-based governance, cybersecurity and a competitive market that rewards transparency over opacity.

This third way is not digital autarky, and it is important to say so, because the caricature of European sovereignty is a wall. It is not a call to cut Europe off from partners or from global open-source collaboration, both of which Europe depends on and benefits from. It is a rejection of blind dependency. A sovereign digital capability is not defined by where the servers physically sit or by the word “sovereign” appearing in a procurement document. It is defined by a set of capabilities: the ability to know what is in your systems, to maintain them, to port them, to audit them, to replace a supplier, to recover from a failure, and to produce evidence for all of the above. Sovereignty, in this reading, is not a label. It is a capability to know, maintain, replace, verify and recover.

Open source is central to this model because it can provide the control layer. Open code can be inspected. Open standards reduce lock-in. Open implementations can become shared reference infrastructure. Open collaboration spreads cost and expertise. Open licensing enables forking, adaptation and continuity when a vendor or a maintainer fails. These are real properties, and they are the reason open source is the natural substrate for a sovereignty strategy.

But open source is not automatically sovereign, and pretending otherwise is the fastest way to discredit the whole idea. A package maintained by one exhausted volunteer can be entirely open and still dangerously fragile, as both Heartbleed and xz showed. A foundation can be trusted and still underfunded. A public administration can migrate to open source and still struggle if the underlying projects lack support markets, security processes or long-term maintainability. A company can build on open-source components and still have no defensible account of what is inside its product, where it came from, who maintains it, or how quickly a vulnerability could be assessed. The licence file says one thing about freedom; the governance and the funding and the evidence say something else about reliability, and reliability is what a trust market runs on.

The strategic question, then, is not whether Europe supports open source in principle. Everyone supports open source in principle. The strategic question is whether Europe can build sovereign open-source assurance: the ability to know, maintain, secure, evidence, procure, replace and recover the open-source components on which critical products and services depend. That is the missing layer between the policy language about sovereignty and the operational burden that lands on the smallest actors in the chain, and it is the layer this article, and the keynote it accompanies, exist to make visible.

The CRA turns sovereignty into an evidence problem

The Cyber Resilience Act is the first hard operational test of this model, and it is worth understanding in enough detail to act on, because the businesses in the SUSE audience will be living inside these mechanics.

The CRA entered into force on 10 December 2024, twenty days after its publication in the Official Journal, and its main obligations apply from 11 December 2027. But the date that should anchor your planning is earlier. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. This is the first moment the trust stack has to produce operational evidence, and it arrives more than a year before full application. The reporting sequence is not a vague obligation to tell someone eventually. It is four distinct clocks. An early warning is due within 24 hours of the manufacturer becoming aware of an actively exploited vulnerability or a severe incident. A fuller notification is due within 72 hours. A final report on an actively exploited vulnerability is due no later than 14 days after a corrective or mitigating measure is available. A final report on a severe incident is due within one month. These reports go through a single channel, the ENISA Single Reporting Platform, to the coordinating national computer security incident response team at the manufacturer’s main establishment, and onward to ENISA and other relevant teams. The platform is the only channel; national email is not a substitute, and at this stage there is no programmatic interface, so the process is a human one. Crucially, these reporting obligations apply to products already on the market, not only to products placed on the market after full application, which means legacy fleets, long-lived software and long-term-support branches are in scope from September 2026.

For a manufacturer, this is an evidence machine, and it has to be built before the clock starts rather than improvised after the first incident. A company has to be able to say, under time pressure, which products are affected, which components are involved, which versions are exposed, whether the vulnerability is actually exploitable in the context of its product, whether upstream has a fix, whether a mitigation exists, which customers are affected, what they need to be told, and what can be reported defensibly within the legal deadlines. None of that is possible without an inventory of products and components, a vulnerability-intake and triage process, a way to map a vulnerability to the specific shipped artifacts it affects, and a record of who decided what and when.

There is a second mechanic that the SUSE audience should understand because it bears directly on distributions and on the businesses that build on them: substantial modification. The CRA’s obligations attach to whoever places a product on the market under their own name or trademark, but they also attach to whoever substantially modifies a product, because a substantial modification can make the modifier the manufacturer for the modified version. A substantial modification is not merely a new release; it is a change that alters the intended purpose or introduces new or increased cybersecurity risk not already covered by the original risk assessment. For software ecosystems this is a live question. Enabling a connector, changing a cryptographic default, adding a remote-management capability, forcing a cloud dependency, or shipping a hardened and rebranded stack can all cross the line. A desktop operating system released in 2026 that receives a feature update in 2028 which changes its intended purpose or increases its cybersecurity risk triggers obligations for that updated version, and the entity making the modification becomes the manufacturer for compliance purposes. For integrators who take a distribution, modify it, brand it and ship it, this is the difference between being a distributor and being a manufacturer, and it is worth knowing which side of the line a given activity falls on before a market-surveillance authority asks.

Alongside reporting and modification sits the support-period obligation. The manufacturer must determine and communicate a support period for the product, must handle vulnerabilities throughout the product’s lifecycle, and must keep the technical documentation and certain records available for at least ten years after placing the product on the market, or longer if the support period exceeds ten years. For long-lived software this is a documentation and lifecycle-governance commitment that has to be designed in, not retrofitted.

This is where the small and medium-sized enterprise becomes the compliance shock absorber, and naming the problem honestly is more useful than pretending it away. A fifteen-person company in healthtech, industrial automation, security or data management may ship a product built on a Linux base, a database, cryptographic libraries, web frameworks, container images, package managers, cloud-backed functions, open-source build tooling, and now AI-assisted development workflows. Under the CRA it may be the manufacturer for the product it places on the market, with all the reporting and documentation duties that implies. But many of the upstream projects it depends on are non-commercial, outside direct manufacturer obligations, or supported by a foundation or steward with a lighter role. The SME sits close to the market and the customer and far from control over its upstream dependencies. If upstream evidence is weak, the SME has to translate informal community practice into formal regulatory evidence, under time pressure, every time something goes wrong. That is expensive, it is fragile, and it is unfair, and if Europe gets the model wrong it is the SME that pays.

If Europe gets it right, the same pressure becomes an advantage. An SME that understands its open-source supply chain, maintains a real component inventory, supports the upstream projects it depends on, uses secure build pipelines and can produce evidence quickly will become a more trusted supplier than a competitor who cannot. But that outcome requires the open-source ecosystem to produce reusable assurance, not only reusable code. The rest of this article is about how that assurance gets built, funded and recognised.

A final point on the CRA, and it is the one that justifies the keynote’s “deadline fixed, machinery in flight” framing. The deadline is genuinely fixed. The machinery genuinely is not finished. As of early June 2026, no CRA harmonised standard has been ratified or cited in the Official Journal, which means the presumption of conformity that harmonised standards are supposed to provide is not yet available for any product category. No notified bodies have been designated, and the machinery that lets member states designate them only opened on 11 June 2026, with the Commission’s best-efforts target for sufficient capacity set at 11 December 2026. The ENISA Single Reporting Platform is not yet live and is scheduled to become operational on the reporting date itself, 11 September 2026, with ENISA publishing the registration, training and dry-run materials during June 2026. The honest message to a manufacturer is therefore not to wait for the system to become comfortable. The conformity standards are not ready, the notified bodies are not designated, and the reporting platform is not live, and none of that postpones the reporting obligation or the underlying requirement to meet the essential cybersecurity requirements directly. The rational response is to build your own evidence pipeline now and demonstrate conformity directly against the requirements, because the alternative is to discover in September that the machinery you were waiting for never arrived in time.

The steward is a bridge, not a command structure

The CRA’s treatment of open source is far more nuanced than the early drafts led the community to fear, and the story of how it got that way is itself one of the most encouraging things an open-source audience can hear.

When the Commission first proposed the CRA in September 2022, the open-source community warned that as drafted it would have a chilling effect, because it would have pulled most consequential open-source projects into manufacturer-grade obligations, including the prospect of affixing a conformity mark to releases. In April 2023, the Eclipse Foundation and eleven other organisations, twelve in total, published an open letter to the European institutions, with a second letter following. Their central argument was that open-source software made up more than seventy percent of the software in products with digital elements in Europe and was about to be regulated without proper consultation of the people who actually produce it. The institutions listened. The political agreement reached in December 2023 substantially improved the open-source treatment and, for the first time in any regulation, created a new category of economic actor, the open-source software steward, and the implementation period was extended to give the ecosystem time to adapt. The community changed the law once, through organised engagement, and the steward concept exists because of it. That is the precedent the keynote closes on, and it is true.

The steward role itself needs careful explanation, because it is easy to get wrong in both directions. A steward, in the CRA’s terms, is a legal person that provides sustained support for free and open-source software intended for commercial activities and plays a main role in ensuring its viability. A steward is not a manufacturer under another name; it does not put a conformity mark on the downstream products that integrate the software it supports. The Commission’s position is that stewards have tailored obligations, including a documented cybersecurity policy, cooperation with market-surveillance authorities, and certain reporting responsibilities, and that stewards are not subject to administrative fines for CRA infringements. But the steward is also not a regulator sitting above a project, and this is the part the simplified framing gets wrong. The Eclipse Foundation’s Open Regulatory Compliance Working Group, in a November 2025 analysis of the steward role, made the point precisely: the CRA’s text can read as though a steward imposes a security policy onto a project, whereas real open-source projects already maintain their own security policies and governance cultures, with the steward providing coordination and infrastructure rather than direction. The most credible way to understand the steward is as a bridge. It provides legal continuity, infrastructure support, coordinated vulnerability handling, evidence support, communication and funding, and it makes a project’s existing security practices legible to the downstream users who now need to see them. A good steward helps a project become easier to trust and easier to integrate. It does not turn volunteers into a compliance department, and any implementation that tries to will fail in contact with how open source actually works.

Voluntary security attestation, which the CRA also provides for, could become a second bridge of the same kind. Designed well, it would let open-source projects or stewards publish evidence that helps downstream manufacturers satisfy their due-diligence obligations for third-party components, so that the same upstream component does not have to be separately audited by every downstream manufacturer in incompatible ways. Designed badly, it becomes paperwork that only large foundations can afford to produce. The executive director of the Eclipse Foundation made the underlying argument well: doing the bulk of the conformance work once, in the upstream project, rather than repeating it across hundreds of downstream products, is obviously more efficient, and the optimistic hypothesis is that once companies are legally required to meet secure-development practices they will be incentivised to invest in the upstream they depend on. Whether attestation becomes a genuine shared-evidence layer or another cost centre will depend on the implementation, the standards and the funding, which is the recurring theme of everything that follows.

Standards are where the trust stack becomes testable

Standards are the layer where the European trust stack stops being a legal aspiration and becomes something you can demonstrate. Legal text says what must be achieved. Standards describe repeatable ways to show that it has been. This is why the standards section of the keynote is not an appendix, and why the openSUSE community has a direct stake in it.

The CRA standardisation request, M/606, was issued through a Commission implementing decision in early 2025 and accepted by the three European standards organisations, CEN, CENELEC and ETSI. It covers around 41 standards, split into roughly 15 horizontal standards, which set a common framework, methodology and taxonomy applying to every product with digital elements, and the remainder vertical, covering the specific risks of particular product types. The timeline runs on three dates. The two core horizontal standards, on secure development and on vulnerability handling, are targeted for 30 August 2026. The vertical, product-specific standards are targeted for 30 October 2026. The remaining horizontal standards are targeted for 30 October 2027, about a year before full application. It is important to keep two milestones distinct, because the distinction is exactly the kind of thing a standards-literate audience will check. A standard being delivered is not the same as a standard being cited in the Official Journal, and only the citation triggers the presumption of conformity. As of early June 2026, several of the horizontal drafts have closed their public enquiry and an ETSI vertical is at final draft, but none has been ratified or cited, and the first citations are expected no earlier than the second half of 2026 on a timetable the Commission has not confirmed.

Here is where the standards landscape becomes concrete for a distribution audience, and it is worth making the point vividly because it dissolves the abstraction. The vertical standards now in mature draft cover browsers, password managers, antivirus software, virtual private networks, network management systems, security information and event management systems, and boot managers. Every one of those is something a Linux distribution ships, packages, or supports. When the CRA’s vertical standards talk about the security of a password manager or a boot manager, they are talking about software the openSUSE community builds and maintains. This is the opposite of an abstract regulatory exercise happening somewhere else. It is a set of requirements being written, right now, about the exact software this community produces, and the question is only whether the community helps write them.

That question matters because of what happens if the answer is no. If the standards are written around the assumptions of traditional proprietary product manufacturers, open-source development models risk being treated as exceptions or edge cases, and practices that are normal and healthy in open source can end up looking like deviations that have to be explained away. If open-source communities engage early, the standards can instead recognise how open source actually works: public issue tracking, distributed maintainership, signed releases, reproducible builds, package provenance, software bills of materials and exploitability records, coordinated disclosure, downstream distribution channels and transparent advisory processes. The mechanism for that engagement already exists and the door is open. Apache, Blender, OpenSSL, PHP, Python, Rust and Eclipse, seven major foundations, announced joint work in 2024 to establish common secure-development specifications based on open-source best practice, hosted at the Eclipse Foundation and explicitly intended to feed the European standards process. The Open Regulatory Compliance Working Group is producing CRA implementation resources and the steward analysis described above. The CRA Expert Group includes open-source representation. The standards section of the keynote is therefore not a lament that someone should do something. It is an invitation, because the people who will be most affected are already in the room where it is being decided, and there is space for more of them.

There is also a head-start answer for organisations that feel behind. The ENISA standards-mapping study identifies the existing standards with the strongest alignment to the CRA’s requirements, and an organisation that already follows them has meaningful coverage to build on: ETSI EN 303 645 for consumer device security, the IEC 62443 series for industrial and operational-technology systems, ISO/IEC 27002 for information-security controls, and ISO/IEC 30111 with 29147 for vulnerability handling and disclosure. Conformance with these supports CRA work without replacing the CRA-specific conformity assessment, but it means few organisations are starting from zero. The principle to leave the audience with is simple and worth stating as a line: standards without implementation become paper, and open-source code without standards can fragment, and Europe’s opportunity is to connect the two through open specifications, reference implementations, conformance suites and shared evidence tooling.

Evidence discipline is the hinge

The word “evidence” sounds dry, and it is the most important word in this article, because evidence is the hinge between a legal obligation and the technical reality of a running system. Everything upstream of evidence is aspiration. Everything downstream of it is enforcement. The quality of the evidence is what decides whether the trust stack carries load.

It helps to be precise about what evidence means here, because it is a layered thing and the layers answer different questions. A software bill of materials answers what is inside a product. Provenance answers where an artifact came from and through which pipeline. Reproducibility answers whether the artifact can be rebuilt from its source, which is the property that would have caught the xz backdoor, since the backdoor lived in a release tarball that did not match the repository. Exploitability records, in formats such as VEX or CSAF, answer whether a given vulnerability actually applies to a given product, which is what stops a manufacturer from drowning in irrelevant findings. A security advisory answers what happened and what changed. Release signing answers whether an artifact is what it claims to be. Registry governance answers who can publish the next version, which is the question GSD turned into a headline. Succession planning answers what happens when a maintainer disappears, which is the question xz answered badly. Incident records answer what was known and when. No single one of these is sufficient, and the recurring mistake in compliance discussions is to treat the software bill of materials as the whole answer when it is only the first question.

This is where the metric I work with, Mean Time to Evidence, earns its place, because the CRA reporting clocks make it operationally real. Mean Time to Evidence is the time between a security-relevant event and the existence of a defensible, attributable record of what happened, what was affected, what was done, and what downstream users can rely on. Mean Time to Patch has always mattered and still does. But the CRA’s twenty-four-hour and seventy-two-hour clocks turn evidence delay into legal and operational risk, because a manufacturer who cannot reconstruct what happened, when it happened, which versions were affected, and what evidence supports the assessment, cannot meet the deadlines no matter how good its engineering is. Evidence delay becomes reporting delay, and reporting delay becomes exposure. The metric has two dimensions that the keynote should make explicit. Upstream Mean Time to Evidence is how fast a project can produce trustworthy information about a vulnerability’s status, the affected versions, the availability of a fix, and the integrity of a release. Downstream Mean Time to Evidence is how fast a manufacturer or a regulated user can map that upstream information onto its own shipped products and its own reporting obligations. The crucial relationship is that upstream sets the floor for downstream. If an upstream project has no advisory discipline, no clear release identity, no support lifecycle and no maintainer continuity, every downstream manufacturer has to reconstruct the evidence from scratch, under pressure, every time. That is the precise mechanism by which weak upstream maintenance becomes a downstream compliance cost, and it is the argument for funding maintenance that the next section makes.

The companion concept, which I describe as Evidence-In, Trust-Out, is the positioning that ties this together. Trust is not an assertion that enters the market and is then taken on faith. Evidence enters the market, and trust is what emerges from it. The discipline that makes evidence worth trusting is well understood in regulated industries, where it goes by the shorthand ALCOA-plus: a record should be attributable, legible, contemporaneous, original, accurate, and then also complete, consistent, enduring and available. Those properties translate to cybersecurity evidence almost without modification. A vulnerability record is not useful if no one knows who made the decision, when it was made, what data it relied on, whether it maps to the shipped versions, and whether it will still be available when an auditor or a market-surveillance authority asks for it two years later. Trust, in the end, is what remains when the question becomes: show me the record.

Two of the examples in this article illustrate the two ends of the evidence spectrum, and they are worth pairing deliberately. curl is the positive model. It is a small-team upstream project with enormous downstream reach, and its security process is unusually disciplined. It operates as its own vulnerability-numbering authority, it publishes advisories that identify the affected version ranges and the exact commits that introduced and fixed each issue along with credit to the reporter, it provides those records in machine-readable form, and it coordinates disclosure through established channels and notifies the distributions ahead of a release. That is upstream evidence that is directly useful downstream, and it is the reason a distribution can act quickly on a curl advisory. It is also, as of recent confirmation from the Sovereign Tech Agency’s own material, a funded project, which makes it the exact pairing Europe needs more of: upstream evidence discipline backed by sustainable maintenance capacity. GSD is the cautionary counterpart, and its evidence lesson is the one about the continuity announcement: under pressure, the responsible move was to separate what was known from what was inferred and to decline to assert what could not be proven. Confident speculation would have been worse than careful uncertainty. The distance between curl’s advisory discipline and the absence of it in a project run by one exhausted volunteer is the maintenance gap, measured in evidence.

Funding the boring work

Open source will not become sovereign infrastructure because Europe declares it important. It will become infrastructure when the unglamorous work that makes it trustworthy is funded: release engineering, security triage, dependency mapping, build reproducibility, package signing, vulnerability coordination, test infrastructure, maintainer continuity, documentation, migration support and incident response. None of that is exciting, and all of it is what the trust stack stands on.

The scale of the gap is worth stating with figures, because the figures make the argument unanswerable. Open source is present in roughly 96 percent of codebases and contributes a minimum of 65 to 95 billion euros a year to the European economy, according to the feasibility study commissioned to scope a European funding instrument. And yet around a third of maintainers are unpaid, and many critical projects are maintained by teams of three people or fewer. That is the structural condition that produced Heartbleed and Log4Shell and xz, and it is the condition GSD ran into from a different direction. The supply side of the trust market is chronically underfunded, and the cost of that underfunding does not show up as a line item until it shows up as a crisis.

There is a working model for fixing this, and it is German. The Sovereign Tech Agency, which began in 2022 as the Sovereign Tech Fund under the federal innovation agency, is a publicly funded body that invests in the open-source components that other software depends on. As of early 2026 it had invested around 34 million euros across roughly 95 technologies, and the list reads like the dependency graph of a Linux distribution: systemd, PHP, FFmpeg, GNOME, Samba, reproducible-builds work, and many others. Two of its investments matter especially for an openSUSE audience. It funds curl, which is the pairing of evidence discipline and funding described above. And in 2026 it invested about 1.2 million euros in KDE Plasma technologies, covering Plasma, KDE Linux and the underlying frameworks, which connects the funding argument directly to the desktop that a meaningful part of this community ships and that the public-sector migrations described in the next section have chosen. The Agency is also the explicit model for a European instrument: the Digital Commons EDIC is piloting a European Sovereign Tech Fund, and the EU Open Source Strategy names an Open Source Maintenance Instrument, with the feasibility study proposing a minimum European contribution of around 350 million euros from the 2028 to 2034 budget. That figure, set against the Agency’s 34 million and against the chronic underfunding the same study documents, is what makes the gap measurable rather than rhetorical.

The principle should be stated bluntly, because bluntness is what makes it land: funding maintainers is not charity, it is supply-chain risk reduction. And the design of the funding matters as much as the amount. If a maintenance instrument rewards activity, it buys goodwill. If it rewards evidence-producing maintenance, it buys assurance. A funded maintainer should shorten not only the time to patch but the time to evidence. A funded project should become easier to identify, assess, integrate, support, procure and recover. That is the link between maintenance funding and the world of the CRA, NIS2 and the Cybersecurity Act, and it is the argument that turns a community concern about burnout into an industrial-policy and security argument that finance ministries can act on.

Procurement turns strategy into demand

Funding stabilises the supply side of the trust market. Procurement creates the demand side, and without demand the supply side has nothing to sustain it. Strategy documents do not create markets. Purchases do.

The strongest public-sector example for an openSUSE audience is Schleswig-Holstein, the northern German state that has turned open-source strategy into an operational migration rather than a pilot. The state is moving on the order of 30,000 workstations away from the proprietary stack, with tens of thousands of public servants and teachers in scope, replacing the proprietary office suite with LibreOffice, the mail and calendar system with Open-Xchange and Thunderbird, the collaboration platform with Nextcloud, the directory with an open alternative, and the desktop with Linux running KDE Plasma, with the Open Document Format mandated as the administrative standard. The email migration was reported through the Commission’s own open-source observatory as completed, moving more than forty thousand mailboxes and well over a hundred million items off the proprietary platform, with the office migration substantially advanced, license savings in the tens of millions of euros, and a portion of the savings reinvested into the open-source ecosystem. The exact figures should be reconciled against the observatory’s wording at the moment of publication, since the migration is in progress and the numbers move, but the direction is unambiguous and the relevance to this community is direct: the desktop the state has chosen is the one openSUSE ships, and the migration is a live demonstration that public buyers can create real demand for open-source infrastructure and make digital sovereignty operational rather than rhetorical.

The honest caveat is the one that ties procurement back to the rest of the argument: adoption without assurance only relocates dependency. Moving from a proprietary stack onto an underfunded open stack is not sovereignty if the open components are themselves a single exhausted maintainer away from the next xz. The cautionary case is Munich, which migrated to Linux in the 2000s, ran the migration for years, and then reversed course, for reasons that were largely political and organisational rather than technical: weak change management, friction with counterparts still on the proprietary stack, and a loss of political continuity across administrations. The contrast with Schleswig-Holstein is instructive precisely because Schleswig-Holstein built a cross-party consensus designed to survive elections. The lesson is that sovereignty is earned through governance, funding and evidence, and not declared by a single procurement decision, which is the same lesson the whole article keeps arriving at from different directions. The positive durability case is worth naming too: the French national gendarmerie has run its own Linux-based distribution across more than a hundred thousand workstations for close to two decades, which is the standing rebuttal to the claim that public-sector open-source migrations always fail.

The role of the buyer, then, is not only to buy open source but to buy it in a way that builds the assurance layer. Public administrations and regulated entities should not consume open source as free raw material while asking the smallest actors in the chain to provide enterprise-grade assurance for nothing. Procurement should reward open standards, portability, documented support periods, vulnerability-handling processes, release integrity, component transparency, and contribution back to the critical dependencies a buyer relies on. When a buyer requires those things and pays for them, it converts the sovereignty strategy into market demand for maintained, evidenced, portable open systems, which is the only thing that makes the supply side sustainable. The phrase to leave the audience with is that buyers create the market, and that begins with the end in mind: every procurement should ask how the organisation would leave, migrate and verify continuity if the supplier failed, was acquired, changed its terms, or could no longer be trusted.

NIS2 and the Cybersecurity Act widen the frame

The CRA is product law, focused on products with digital elements and on the actors who place them on the market. It is not the whole of the trust stack, and an audience that only hears about the CRA will misjudge its own exposure. Two other instruments widen the frame from product security to operational trust.

NIS2 is the organisational layer. It concerns cybersecurity risk management, supply-chain security, incident handling, business continuity and governance for the essential and important entities across a wide range of sectors. It is a directive, which means it is transposed into national law and its details vary by member state, but its direction is consistent: organisations have to manage their risk, including the risk in their software supply chains, and they have to be able to show that they do. The revision of the Cybersecurity Act, proposed in January 2026, adds a further layer, aiming to strengthen the European cybersecurity certification framework, to develop schemes faster with ENISA in a stronger scheme-management role, to introduce a notion of an entity’s cyber posture, and to build trusted-supplier logic for critical infrastructure. It is a proposal, not yet binding law, and it should be presented as such, but its direction tells you where assurance is heading: toward certification that becomes reusable evidence rather than a slow parallel bureaucracy.

The reason this matters for open source is that it changes who needs evidence and why. A manufacturer needs CRA evidence for its product. But a hospital, an energy company, a cloud provider, a public administration or a digital-service provider needs NIS2-style organisational controls for the environment in which products and open-source systems actually run, even when it is not itself a CRA manufacturer for any particular component. Certification schemes, even where formally voluntary, become procurement signals, because a buyer in a regulated sector will treat a certificate as a trust signal and will ask suppliers for evidence of secure development, vulnerability handling, support periods, supplier risk, continuity and incident readiness. This is the route by which the assurance expectations of the CRA reach organisations that the CRA does not directly regulate, and it is why an organisation that uses open source directly, without placing any product on the market, still has to manage its open-source dependencies as part of its NIS2 risk management, its supplier assurance, and its incident response. The market does not wait for every legal boundary to be litigated. Buyers ask a simpler question, and they ask it of everyone: can we rely on you, and can you prove it.

The Linux distribution as the working model

It is worth drawing the threads together around the openSUSE audience specifically, because the distribution is not only the lens of this talk. It is the working model of what sovereign open-source assurance looks like when it is done well, and the community that builds it is better positioned than almost anyone to lead.

Map the CRA’s roles onto a distribution ecosystem and the picture is clear. A commercial enterprise distribution placed on the market under a company’s name, such as SUSE Linux Enterprise, is a product with digital elements for which that company is the manufacturer, with the full set of obligations: risk assessment, secure-by-design requirements, technical documentation, conformity assessment, support-period determination, vulnerability handling and reporting. A genuinely non-commercial community distribution may sit outside direct manufacturer obligations where it is not made available on the market in the course of a commercial activity, which is the role much of openSUSE’s community work occupies. A legal person that provides sustained support for the open-source software intended for commercial activities, which a foundation or a commercial sponsor may do, can occupy the steward role, with its tailored obligations and its exemption from administrative fines. An integrator that takes the distribution, substantially modifies it, brands it and ships it for commercial downstream use can become the manufacturer for that modified product. The same ecosystem contains all of these roles at once, which is exactly why role clarity is the first compliance control, and why the common mistake, that commercial use of open source makes every upstream contributor a manufacturer, is both wrong and damaging. The keynote should make this triad concrete, because the audience lives inside it, and seeing their own work mapped onto the regulation is what turns the talk from a policy briefing into something they can act on.

The deeper point is that the distribution already implements most of what the regulation is asking for. The Open Build Service produces a controlled, auditable build pipeline. Package signing establishes integrity. Reproducible-build work establishes that an artifact matches its source, which is the property that defends against the xz class of attack. Security advisories, mapped to package versions, are exactly the downstream-consumable evidence the CRA’s reporting regime needs. Long-term-support branch policy is lifecycle governance. Mirrors and repository policy are distribution-channel integrity. None of this was built for a regulation. It was built because distributions learned that trust has to be manufactured. The work that remains is to make this existing engineering evidence legible to the legal, procurement and conformity-assessment systems that are now asking to see it, and to help write the standards so that they recognise these practices rather than treating them as exceptions. That is a translation task and an engagement task, and it is squarely within this community’s competence.

What communities should do now

Open-source communities do not need to become corporate compliance departments, and any advice that pushes them in that direction will be ignored, correctly. What they need to do is make trust inspectable, which is a lighter and more achievable thing.

At a minimum, a strategically important project should be able to answer a short list of questions, and the value is less in any single answer than in the project having thought about them. Who can publish a release. Is release authority shared, or does it rest with one person. Are the registry accounts protected with strong authentication and, where possible, trusted publishing rather than long-lived tokens. Are releases signed, and is provenance available. Is there a security policy and a contact route for reporting vulnerabilities. Is there a coordinated disclosure process. What happens if a maintainer disappears, which is the succession question that xz answered badly. Are the dependencies known. Are downstream users told what changed in a release. Is there a route to publish advisories. And is there any financial entanglement, such as an associated token, that should be disclosed, which is the question GSD raised.

For agentic AI development tools specifically, the checklist has to go further, because the privileges are higher. What can the tool read, write, execute and transmit. Can it install dependencies. Can it edit lockfiles. Are its guardrails advisory or blocking, which was the gap the GSD review found. Can it run safely without access to production secrets. Can it be sandboxed. And can an organisation remove it within twenty-four hours if trust collapses. These are not exotic questions. They are the questions that distinguish a tool you have evaluated from one you have merely adopted.

This points to a small set of maturity dimensions that the classic open-source maturity models, valuable as they were, did not foreground, because they were built for an earlier era. Registry governance: who can publish, transfer, revoke or deprecate. Release-authority distribution: how many independent people control the release flow. Succession and bus factor: what happens when the maintainer is gone. Financial entanglement: whether a token, grant, sponsorship or equity arrangement could distort governance. Build and package provenance: whether releases are signed, reproducible and accompanied by a bill of materials. Agent-privilege transparency: what an AI tool can read, write, execute and install. And dependency-autonomy controls: whether the tool can add dependencies without human approval. For high-privilege development tooling, a bus factor of one should prevent professional adoption unless compensating controls are documented, and a project with an associated tradeable token should be treated as a financially entangled supplier rather than as neutral community infrastructure. None of this is a counsel of perfection. It is a counsel of visible maturity, and the difference between a project that has these answers and one that does not is the difference between a dependency a regulated buyer can trust and one it cannot.

What companies should do now

For the business owners and organisations in the SUSE audience, the response to all of this is not panic and it is not a retreat from open source or from agentic AI, both of which deliver real value and are not going away. The response is professionalisation, and it can be organised into four loops that fit how a company actually operates.

The first is the adoption loop, which runs before a high-privilege tool enters normal engineering use. Write down why the tool is being adopted, what it can access, who controls its package registry, how its releases are published, whether versions are signed, whether provenance exists, whether there is a security policy, whether there is a succession plan, and whether financial incentives could distort its governance. For a small company this is a one-page intake record, not a procurement bureaucracy, but it has to exist, because “everyone was using it” is not a governance position and will not survive an audit.

The second is the runtime loop, which runs while the tool is in use. Pin versions, and do not pull the latest tag for high-privilege tooling, which is the single change that would have neutralised a large share of recent registry-based incidents. Run agentic development tools in constrained environments where possible: containers, virtual machines, or restricted workspaces. Keep production secrets out of the environments where development agents run, so that a compromised tool cannot reach the secure-shell keys, cloud credentials and registry tokens that turn a local incident into a breach. Require human approval for dependency installation and lockfile changes. Record which AI tool, which version and which mode contributed to important artifacts, which is the traceability that the CRA-adjacent and AI-Act-adjacent worlds will increasingly expect. And treat dependencies that an agent introduced as untrusted until a human has checked them.

The third is the response loop, and it is the one most companies do not have, because it is genuinely new. A maintainer-trust-collapse playbook is not the same as a vulnerability playbook. In the GSD case there was no vulnerability identifier, no exploit and no malware signature; the trigger was the loss of trust in maintainer continuity, registry control and project governance. The response to that trigger is its own procedure: freeze updates, identify where the tool is installed across machines and pipelines, inspect lockfiles and global installs and caches and continuous-integration configuration and project templates, rotate credentials if there is any plausible exposure path, compare package versions to see what actually changed, reconstruct the window during which the tool was in use and what it touched, and then decide whether to migrate, fork, replace or retire. A company that has rehearsed this once will handle the next GSD calmly. A company that has not will improvise under pressure, which is how mistakes happen.

The fourth, for any company that is a CRA manufacturer, is the evidence loop, and it has a deadline. Know which products are affected by a given issue. Maintain a component inventory and an upstream-dependency register. Track upstream vulnerabilities and assess their exploitability in your product’s context. Prepare reporting templates and decide in advance who is authorised to make a report-or-no-report decision. Keep records of awareness, decision, mitigation and closure. And test the whole process before 11 September 2026, because the first time you exercise your reporting pipeline should not be during a real incident with a twenty-four-hour clock running.

The openSUSE role, and why this community matters

The openSUSE community sits at exactly the right point in this conversation, and that is not flattery, it is structure. A distribution community understands packaging, reproducibility, signing, update channels, advisories, mirrors, maintainers, upstream relationships and downstream users. It understands that software trust is social and technical at the same time, that a maintainer is a person and a release is a commitment. That understanding is precisely what the European standards and policy process needs and most lacks, because the process is full of people who understand law and procurement and short of people who understand release engineering.

The stakes of participation are concrete. If open-source communities do not engage, the standards that govern browsers and password managers and boot managers will be written around the assumptions of proprietary product models, and open-source practices will be treated as deviations to be justified. If they do engage, they can show how open-source development already implements much of what Europe is asking for: transparent source, public review, reproducible builds, package metadata, shared advisories, dependency transparency, community governance and downstream distribution. The CRA was improved because open-source organisations engaged once already, and the steward concept exists as a direct result. The next stage is implementation, which is guidance and harmonised standards and voluntary attestations and stewardship models and maintenance funding and procurement criteria and evidence tooling, and all of it is being decided now. The pen is still moving, and this community has standing to hold it.

Europe’s third way must be earned

Europe’s third way is attractive because it does not have to be anti-American or anti-Chinese. It can be pro-openness, pro-standards, pro-competition and pro-trust. It can offer European buyers and partner countries a real alternative to closed-platform dependency on one side and state-controlled infrastructure on the other: an open, rights-based, interoperable, security-conscious digital market that other regions might actually want to join.

But that model will not be proven by rhetoric, and the gap between the rhetoric and the reality is where this article has lived. It will be proven by whether small companies can comply without becoming the shock absorber of the software supply chain, by whether stewards and foundations can produce evidence that downstream users can actually rely on, by whether the standards reflect how open-source development really works, by whether procurement rewards portability and maintained dependencies instead of buying closed platforms while praising sovereignty, and by whether Europe funds the unglamorous work that makes strategic software trustworthy. The visible machinery will stay messy. Policy will keep moving asynchronously, because reality keeps moving asynchronously, and new crises will keep producing new instruments. That is unavoidable, and it is not the test. The test is whether the output becomes coherent enough to carry load.

The windows are open now, all of them at once, which is unusual and will not last. The CRA reporting obligations start on 11 September 2026. The harmonised standards are being drafted, with the first citations expected before the year is out. The Cybersecurity Act revision and the Cloud and AI Development Act are still proposal-level architecture that can be shaped. The Open Source Maintenance Instrument is still under-specified, and the budget window that runs from 2028 to 2034 will decide whether open source remains a thin line item in a strategy document or becomes funded infrastructure. The community shaped the CRA once. It can shape the implementation, the standards and the funding, and the people who show up will determine whether open-source reality is recognised or interpreted by others.

The lesson of GSD, in the end, is the lesson of this entire argument. A community audit with passing tests and no backdoor was not the same as a trustworthy tool, and the only reason anyone could tell the difference was that a second, independent pass was run against the same material. That is what assurance is. It is not a clean scan, which is only a timestamp. It is the discipline of producing, and independently checking, the evidence that lets someone else rely on your work under pressure. Open source has won distribution because it could be used everywhere. It will win the next phase only if it can be trusted everywhere, and trust, when the question finally comes, is simply this: show me the record.

That is sovereign open-source assurance, and building it is the work in front of us.

---

Source notes for final publication

The published version of this article should carry direct citations or endnotes for the following source families. All were verified against primary or strong secondary sources current to June 2026; the items marked for re-check are those most likely to move before publication.

1. CRA dates and reporting mechanics. European Commission CRA summary and reporting pages, and the ENISA Single Reporting Platform page, for entry into force (10 December 2024), the 11 June 2026 conformity-assessment-body machinery, the 11 September 2026 reporting obligations, the four reporting clocks, and the SRP operational schedule. Re-check the SRP onboarding status and any final guidance Communication at freeze.

2. CRA conformity and standards status. The CRA harmonised-standards tracker and the cyberresilienceact.eu guidance summary, for the confirmed position as of early June 2026 that no harmonised standard has been cited in the Official Journal, no notified bodies are designated, and the three-date standards model (two core horizontals targeted 30 August 2026, verticals 30 October 2026, remaining horizontals 30 October 2027). The vertical product categories in mature draft (browsers, password managers, antivirus, VPNs, network management, SIEM, boot managers) are from the Hogan Lovells 2026 readiness note and Honeywell supplier guidance. Re-check the OJ citation status at freeze, and keep EN 40000 subpart identifiers out of the text unless re-verified.

3. CRA open source and stewardship. European Commission CRA open-source page for the FOSS scope, the steward role and the Article 64(10) fine exemption; the Eclipse Foundation Open Regulatory Compliance Working Group November 2025 steward analysis for the steward-as-bridge nuance; the April 2023 Eclipse-led open letters and the December 2023 political agreement for the community-engagement history.

4. The seven-foundation specification initiative. Eclipse Foundation April 2024 announcement, for the joint secure-development specification work by Apache, Blender, OpenSSL, PHP, Python, Rust and Eclipse.

5. The GSD incident. The Open GSD continuity announcement and security-audit material, the independent review of that audit (GitHub Discussion #119), and cautious independent reporting (AI Weekly), for the trust-state-inversion pattern, the registry-key finding, the advisory-only guardrail gaps, and the post-incident hardening. Maintain the wording discipline: the dollar figure and the fraud attribution are not formally confirmed; frame the token event as publicly linked rather than proven.

6. The underfunding arc. Primary and strong secondary sources for Heartbleed (CVE-2014-0160) and the Core Infrastructure Initiative, Log4Shell (CVE-2021-44228) and the OpenSSF response, and xz-utils (CVE-2024-3094).

7. Slopsquatting. Trend Micro and Socket research on AI-hallucinated package names as a supply-chain vector.

8. Maintenance funding. Sovereign Tech Agency statements for the approximately 34 million euros across roughly 95 technologies as of early 2026, and for the curl and KDE Plasma investments; the 2025 feasibility study (OpenForum Europe, Fraunhofer ISI, European University Institute) for the 96 percent codebase figure, the 65 to 95 billion euro annual contribution, the maintainer-funding gap, and the proposed approximately 350 million euro European instrument. Use the live Sovereign Tech Agency total at freeze if a more current figure is available.

9. Procurement. Interoperable Europe and the Open Source Observatory for the Schleswig-Holstein migration figures (reconcile exact numbers at freeze); standard retrospectives for Munich and the French gendarmerie.

10. NIS2 and the Cybersecurity Act revision. Directive (EU) 2022/2555 for NIS2; the European Commission cybersecurity-package Q&A for the January 2026 CSA revision proposal. Keep the proposal caveat on the CSA revision, CADA and the Chips Act 2.0.