The Answer Was Already on the Shelf

EU CRA: From Threat to Answer

Most of the open source world first heard the CRA as a threat. For the people who had spent years building the required tools, the law’s arrival felt like something else. “For me, it was ‘finally’,” Hemel says.

He casts the law and tooling as two sides of one push. The CRA is the stick; the open, high-quality data of a project like CodeSupply is the carrot, the thing that keeps the compliance overhead as low as it will go. “Though a carrot,” he adds, “can also be used as a very short, and probably orange, stick.”

Pressed to make the case for the CRA as the answer rather than a fresh burden, Ombredanne lands on one word. “It forces transparency,” he says, “or at least more transparency,” and calls that a real first step. He is honest about its limits. He and Hemel both think the law would work better organized around software packages rather than finished products. Treat the package as the unit, Hemel says, and security and license information becomes something you simply attach to it, “like decorating a Christmas tree.” Ombredanne had hoped the reporting rules might let Europe gather every SBOM into a single census of what open source software is actually in use across the continent; that is not in the plan.

He is just as honest about readiness. The requirement to report an exploited vulnerability inside a tight window is, in his words, close to physically impossible for most companies today. They mostly do not yet know what software their products contain, and the first deadline is set for September 2026. Faced with the choice, many companies will quietly under-report and hope. “The data is shit,” he says, “and the tools are not complete.”

That is the case for building Europe’s own foundation rather than borrowing someone else’s. Whoever decides what counts as an exploitable vulnerability decides how much compliance work a company has to do. Ombredanne puts the question plainly: Should a European organization depend on a defunded US federal agency to define its legal obligations? He is not describing a hypothetical. The US National Vulnerability Database, the resource much of the world’s security automation quietly relies on, spent 2024 watching its backlog of unanalyzed vulnerabilities climb past 27,000. In April 2026, the institute that runs it conceded it could not keep up and narrowed its full analysis to prioritize US federal and US-critical systems: roughly 15 to 20 percent of incoming vulnerabilities, by independent estimates. A month later, a US government watchdog reported the database could no longer be considered reliable. Europe had no vote in any of the decisions that led there.

The answer was already on the shelf when the law came looking for it: two European efforts. VulnerableCode is the community side, an open database that cross-checks many sources instead of trusting any single one. The European Union Agency for Cybersecurity is the institutional side, standing up a European vulnerability database and moving to take a senior role in the global CVE system. Rather than a European data source for its own sake, “it’s about having a correct, open, verifiable, traceable data source,” Ombredanne says.

What an ordinary buyer might notice 10 years from now is quieter than the politics and more concrete: a device whose code stays maintained and secure for longer. What changes for the companies shipping that software, in Ombredanne’s telling, is a pair of habits that come to seem ordinary: tracking the security of every dependency and paying back into the open source projects they build on, in cash or in kind. Hemel expects new markets to open alongside that development, hardware sold on full traceability and long-term support rather than on price.

Hemel also expects businesses to find angles the legislators never imagined, such as companies spun up to ship a product and dissolved before anyone can hold them to account — with escrow and mandatory pre-market audits as the eventual counter, and at the cost of slower time to market. “The CRA is not the end of the game,” he says. “It is probably just the end of the beginning of the game. We are in for a ride.”

Ombredanne’s horizon runs further out. Peer review and decentralization are only a step, he says, toward an endgame in which open source projects publish the security and license data for their own code, and no single government’s funding decisions can degrade what the rest of the world relies on. An open, independently governed record of what is inside a product and what is wrong with it is not a convenience. It is what digital autonomy looks like in practice: the ability to see clearly, and to fix what you find, without asking anyone’s permission.

This article was made possible by support from NLnet Foundation through Linux New Media’s Topic Subsidy Program (https://www.linuxnewmedia.com/Topic\_Subsidy). NLnet Foundation is the Coordinator of the NGI Zero Consortium. NGI Zero programs are made possible with financial support from the European Commission.

Disclosure: Philippe Ombredanne co-maintains ScanCode, VulnerableCode, and other AboutCode tools listed below and authored the Package-URL (PURL) specification.

Links for further reading:

Links for your toolkit:

A minimum practice for the CRA: Keep a continuous inventory of third-party code inside your products, then track its licenses and vulnerabilities against that inventory, keyed by Package URL. Ombredanne points to a ready-now stack: Dependency-Track or SecObserve to watch the inventory and Syft and Grype to generate and scan a software bill of materials backed by open vulnerability data from OSV, Vulnerability-Lookup, PurlDB, and VulnerableCode.

« Previous 1 2

Buy Linux Magazine

SINGLE ISSUES

Print Issues

Digital Issues

SUBSCRIPTIONS

Print Subscriptions

Digital Subscriptions