The EU Is About to Make Linux’s Vulnerability Management Problem Harder to Ignore

More CVEs, sprawling deployments, and new EU reporting rules are turning vulnerability management into a matter of evidence as well as patching.

For Linux administrators, keeping systems patched has always been one of those jobs that sounds considerably easier than it actually is. Run the updates. Reboot when necessary. Watch the security mailing lists. Done.

Except that isn’t how real Linux environments work.

Servers accumulate packages. Applications bring dependencies. Containers multiply. Somebody keeps an old system running because one application still needs it. A developer installs something outside the normal package-management process. Meanwhile, another batch of CVEs arrives before anyone has finished dealing with the previous one.

And lately, there are a lot more CVEs. The CVE Program recorded 48,244 published vulnerabilities in 2025, up from 40,077 in 2024 — an increase of more than 20%. The acceleration in 2026 has been considerably sharper. During the first half of the year, 35,885 CVE records were published, including 20,709 in the second quarter alone.

Some of that is actually good news.

We are getting better at finding vulnerabilities. More organizations participate in vulnerability disclosure, security research continues to improve, and AI-assisted code analysis can find bugs that might previously have remained undiscovered for years.

Linux users have already seen what that can look like. This spring brought a remarkable run of Linux vulnerabilities, including Copy Fail, Dirty Frag, Fragnesia, and ssh-keysign-pwn. AI-assisted vulnerability research is making it possible to inspect enormous amounts of source code much faster than humans could do alone.

That’s potentially very good for open source security. There is, however, an obvious catch: defenders aren’t the only people with access to AI.

Finding the CVE Is No Longer the Hard Part

For organizations running Linux in production, the security problem is increasingly shifting away from simply asking: Is there a vulnerability? Instead, administrators have to answer several more difficult questions. Is the vulnerable package actually installed on one of our systems? Is that particular machine exposed? Is the vulnerability exploitable in our configuration? Is a fix available from our distribution? Has the fix been deployed everywhere it needs to be? And can we prove afterward what happened?

Since September 11, some organizations have another reason to answer those questions quickly. That’s when the first reporting requirements under the European Union’s Cyber Resilience Act, or CRA, became applicable.

Manufacturers covered by the CRA will be required to report actively exploited vulnerabilities and severe security incidents affecting products with digital elements. An early warning must generally be submitted within 24 hours after becoming aware of the issue, followed by a more complete notification within 72 hours. For actively exploited vulnerabilities, a final report is required no later than 14 days after a corrective or mitigating measure becomes available.

That doesn’t mean somebody maintaining a hobby project on GitHub suddenly needs a Brussels compliance department.

Open Source Isn’t Suddenly Regulated Like Microsoft

This distinction is important, particularly for the open source community.

The CRA deliberately treats free and open source software differently. Software developed or supplied outside commercial activity generally isn’t subject to the same manufacturer requirements, and somebody contributing code to an open source project they don’t control doesn’t suddenly become the “manufacturer” responsible for CRA compliance.

Open source software stewards also have their own, lighter regulatory regime. But there’s another side to that distinction. A company doesn’t escape its obligations for a commercial product simply because much of the software inside that product happens to be open source.

If your company puts a commercial product containing software onto the European market, somebody needs to know what is running inside it. When a vulnerability appears, somebody needs to determine whether the product is affected. When a patch becomes available, somebody needs to know whether it was deployed.

And if somebody later asks what happened, “we normally run dnf update on Fridays” isn’t much of an audit trail.

Eventually, the CRA carries substantial penalties for violations of some of its core cybersecurity requirements: as much as €15 million or 2.5% of worldwide annual turnover, whichever is higher. That makes vulnerability management something more than routine system administration.

Linux Already Gives Us Some Good Tools

The good news is that Linux administrators aren’t starting from zero.

Debian has an excellent public Security Tracker, publishes Debian Security Advisories, provides machine-readable vulnerability information, and offers unattended-upgrades for automatically installing security updates.

Rocky Linux publishes security errata and exposes update information administrators can query directly using tools such as dnf updateinfo.

AlmaLinux similarly provides public security advisories, OVAL vulnerability data, OpenSCAP tooling, security hardening resources, and SBOM information.

Those distribution-level resources remain some of the best places to start because the question administrators really need answered isn’t whether a CVE exists somewhere in the world. It’s whether their distribution, version, and installed package are actually affected.

There are also commercial tools moving down-market into territory where smaller Linux shops can use them without writing a check. Codenotary, for example, recently expanded its free Trust offering from AlmaLinux to Debian and Ubuntu. It provides the platform for up to 25 machines at no charge, including continuous vulnerability scanning, patch management, CIS compliance checks, SBOM export and audit history, without a time-limited trial.

There are other ways to assemble those capabilities from open source tools, of course. And for plenty of experienced Linux administrators, that’s exactly what they’ll want to do. The important point isn’t which tool you choose. It’s knowing what happened.

Patching Isn’t Enough Anymore

For years, Linux security could often be treated as a fairly straightforward cycle. A vulnerability was disclosed. Distribution maintainers evaluated it. A patched package appeared in the repository. Administrators installed it.

That model still works remarkably well. What is changing is the scale.

When vulnerability discovery accelerates, the difficult part becomes maintaining a continuously updated picture of what is installed, which vulnerabilities actually affect those systems, which fixes are available, where those fixes have been deployed, and what evidence remains afterward.

That last part matters. A patched machine is secure.

A record showing when the vulnerability was discovered, which machines were affected, when the patch became available, and when those systems were remediated is something else. It’s evidence.

And for companies selling software-containing products into Europe, evidence is about to become much more valuable.

The Cyber Resilience Act doesn’t suddenly make open source software insecure, nor does it turn every Linux user into a compliance officer. What it does is make something Linux administrators have known for years much harder for organizations to ignore: Installing the patch is the easy part. Knowing where you need it – and proving afterward that you installed it – is the real vulnerability-management problem.

Codenotary is a Platinum-level sponsor of FOSS Force.