Linux gets into the CVE security business

We rely on Common Vulnerabilities and Exposures (CVE) bulletins to track and catalog security problems.  It's the best system we have for keeping on top of security holes. Unfortunately, it doesn't work that well. The Linux kernel community is all too aware of this, so after years of debate, they've decided to take matters into their own hands regarding Linux kernel security problems.

As Greg Kroah-Hartman, the Linux stable kernel maintainer and a prominent member of the Linux kernel security team, reported, "The Linux kernel project has been accepted as a CVE Numbering Authority (CNA) for vulnerabilities found in Linux."

Kernel.org has done this, Kroah-Hartman explained, because while the  CVE"system overall is broken in many ways, but this change is a way for us to take more responsibility for this, and hopefully make the process better over time." It will also ensure that no other group can assign Linux CVEs without the Linux developers getting their say. 

How are CVEs broken? Let us count the ways. 

While businesses and security companies rely on CVEs, they're not that trustworthy. Kroah-Hartman pointed out years ago that "the database is incomplete, with many vulnerabilities missing altogether or rejected for a variety of reasons. Even when CVE numbers are assigned for a vulnerability, the process tends to take a long time, and updating the National Vulnerability Database (NVD) takes even longer."

The system also does a poor job of tracking security problem fixes. For example, there is a single CVE entry (CVE-2017-5753) for the extremely nasty Linux Spectre version 1 security problem, but there are over one hundred patches addressing it. A CVE number may or may not lead to the patches that fixed it. 

CVE numbers are also abused by security developers looking to pad their resumes. As a result, many "stupid things" are submitted for CVE numbers, and getting the invalid ones revoked is difficult. With the rise of artificial intelligence (AI) code scanning tools, numerous CVEs are being granted for bugs that don't really exist.  

Kroah-Hartman also noted that many engineers are abusing CVE numbers to force code updates. If they can get a CVE issued, it will force their company to ship a particular patch in a product update, even if there's no real security problem behind the CVE. 

He declared that "Many of these [bogus CVEs] are just worthwhile fixes that couldn't be merged into a shipping kernel without a CVE number behind them." In such cases, the CVEs no longer carry any useful information.

The Linux kernel hackers aren't the only open-source programmers taking charge of their CVEs. The Python project and curl project are both doing it as well for the same reasons. As Daniel Steinberg, founder and lead developer of the popular open-source command line copy tool curl, said, "We do not particularly want to be a CNA, but we hope that this move will make it harder to file more stupid curl CVEs in the future."

Kroah-Hartman believes many other open-source groups will be joining them. That's because "it looks like all open-source projects might be mandated" to assign and monitor CVEs" with the recent rules and laws being enacted in different parts of the world." The Open Source Security Foundation (OpenSSF) has released a guide on how an open-source project can become a CNA.

This all sounds good to me, but some people are in a tizzy about the Linux developers becoming a CNA. They fear that since, to quote Linux founder Linus Torvalds, "security problems are primarily just bugs," the Linux developers will issue CVEs for all patches and make them worthless. 

That is not the plan. That was never the plan. 

As Dan Lorenc, CEO and co-founder of Chainguard, a leading software supply chain company, explained, "Some folks acting out of bad faith started stirring up drama that the Linux team was going to file CVEs for every single change to the kernel (which is one of the most active codebases on the planet). This isn't happening. It's wrong, dumb, false, and designed to create a panic."

Instead, Lorenc added, "The team will be carefully reviewing fixes and only issuing CVEs when they believe it's warranted. As Greg said, 'We know it [security holes] when we see it.' … Don't panic. This is fine. This is good. There's lots to fix in the CVE ecosystem, but the kernel team isn't "burning it down out of spite."

Exactly. The plan is to make CVEs more active and useful for Linux developers, security professionals, and users. With Linux experts now in charge, that's exactly what will happen. 

Noteworthy Linux and open-source stories:

• Do you need antivirus on Linux?

• Damn Small Linux revived my original Eee PC. Here’s how to use it on any old computer

• Red Hat Enterprise Linux Modifies Pricing Model for Cloud Deployments