The top open-source security events in 2024

What have been the most significant security-related incidents for the open-source community in 2024 (so far)? Marta Rybczyńska recently ran a poll and got some interesting results. At the 2024 Open Source Summit Japan, she presented those results along with some commentary of her own. The events in question are unlikely to be a surprise to LWN readers, but the overall picture that was presented was worth a look.

Fun with CVE numbers

A relatively low-scoring (but still significant) episode in her poll had to do with the handling of CVE numbers. There has never been, she began, a machine-readable database of CVE numbers until earlier this year; instead, they have been managed as free-form text. She cited CVE-2009-1377 as an example, the entry for which contains a single sentence describing the vulnerability. There is no easy way to extract the relevant information — the vulnerable package, version numbers, the nature or severity of the vulnerability, etc. — from this entry. The National Vulnerability Database (NVD) was created in response to this problem; it was designed to absorb CVE data with additional metadata. Compare, for example, the NVD entry for CVE-2009-1377 with the original. The NVD database is now heavily used by vulnerability scanners and other types of security software.

The "NVD crisis" hit in February of this year, she said, when the NVD suddenly stopped adding new entries; it is still not clear why that happened. CVE numbers were still being assigned, but they were not making their way into the NVD. The process restarted a few months later, but the addition of NVD entries remains slow, and the backlog is large. This has created problems for software that relies on NVD data.

On the CVE side, the assignment of numbers is proceeding more quickly than ever. A number of prominent projects, including curl, the Linux kernel, and the WikiMedia Foundation, have set themselves up as CVE numbering authorities (CNAs) — but they are late to the party, since most large projects had already made that move. Some of these projects, such as the kernel, are issuing a lot of CVE numbers. There is a new JSON-based format for CVE entries that is being rolled out now; it should help with the automated processing of CVE numbers in the future.

As a response to the NVD crisis, security developers have been asking for the creation of an open security database that is not dependent on any single-vendor solution, she said. But this database will only be feasible to create and maintain if all CVE entries are machine readable. There is new legislation that will force automated processing of vulnerability information, and the increasing flow of CVE numbers from the new CNAs is creating scalability problems. Whether a new vulnerability database should be created or an existing one improved is an open question. There are various databases out there, including OSV and the GitHub Advisory Database, but they are single-vendor solutions. Another open question is whether vulnerability databases with a regional or national focus are needed.

Meanwhile, the NVD backlog is still high, and the CVE program is still working to get the CNAs to properly encode their entries. There is a full set of CVE data available from GitHub in JSON format, but it is a read-only database. Nobody can submit a pull request to fix or improve an entry; instead, all such changes have to go through the appropriate CNA.

Trends

Turning to trends that have made themselves felt in 2024, Rybczyńska mentioned the work to enable the use of Rust for writing kernel code. The kernel is not the only place where that sort of change is happening, though. Agencies like the US Cybersecurity and Infrastructure Security Agency have been pushing hard in that direction. The Android project has been moving toward Rust since 2019, she said, and that has already resulted in a significant reduction in bugs.

Meanwhile, compilers for languages like C and C++ are gaining new warnings that are intended to head off vulnerabilities. It has reached the point, she said, where it is difficult to write a buffer-overflow vulnerability in C without generating a warning. The static analyzer in the GCC 14 release has also gained the ability to detect and illustrate a number of types of bugs, including buffer overflows and infinite loops.

On the legislative front, the big news is the European Cyber Resilience Act (CRA), which adds mandatory security requirements for all products sold there. By default, she said, vendors must perform a self-assessment of their compliance with those requirements, though products deemed important or critical require a higher degree of scrutiny. Vendors must offer security updates, free of charge, for a minimum support period of five years. They are required to fix vulnerabilities, including those introduced by dependencies incorporated into their products. There is also a requirement to exercise due diligence with incorporated software and to report security incidents.

The CRA will likely be published in November, she said, and will go into full force three years later. The effect of this legislation on open-source projects has been the subject of a lot of conversation; that has resulted in numerous modifications to the CRA over time. There are protections in place for contributors to projects; the obligations land on those who monetize a project rather than those who contribute patches to it. "Stewards" that support open-source projects are also protected, but they are required to have security-related processes in place.

Open-source software, she said, is now far too big to be overlooked by legislators. This can be seen in areas beyond the CRA; she mentioned the recent removal of some Russian kernel maintainers as an example. The CRA is one of the biggest examples, though; it is "a big deal", and three years is not a long time to prepare for it.

There have been some initiatives for the funding of open-source security work, she said. The OpenSSF Alpha-Omega project and Sovereign Tech Agency are a couple of prominent examples; the latter has been explicitly directing grants toward maintainers. The economic climate is becoming more difficult, though, and it is not entirely clear that those resources will continue to be available.

With regard to software bills of materials (SBOMs), she noted that SPDX 3.0 was released in April; it is a complete rewrite of that standard that includes vulnerability reporting. There was a new release of the CycloneDX standard as well. The generation of SBOMs is growing, she said, but the actual use of that data is lagging behind.

Other minor incidents

There were a couple of specific vulnerabilities that drew attention over the year as well. The XZ backdoor attempt was one of those; it was a two-year effort to insert malicious code into a piece of little-known (but omnipresent) software. This attack nearly succeeded; like the Log4j vulnerability, it highlights the risks that come with single-maintainer projects. In both cases, the problem arose in a project that does not normally look like a security risk. And it raises the question of just how we can develop and maintain trust in the developers who write and maintain our software.

XZ was not the most significant security event of the year, though, according to her poll; that was, instead, the CrowdStrike incident. But, she asked, who cares since it only affected Windows? There is a Linux version of CrowdStrike's software that didn't break; perhaps that is a result of a better architecture (including the use of BPF rather than kernel modules) on the Linux side. But it is also a matter of luck, which was in our favor this time around.

Had the XZ attack been detected later, she concluded, it would have resulted in a backdoor that affected something like half of the SSH servers on the net. That is easily an incident on the same scale as the CrowdStrike fiasco — or worse. The lesson to take away from these events is that a security failure of that magnitude can happen to the open-source community as well.

A video of this talk is available on YouTube.

[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting our travel to this event.]

Index entries for this article
Security	News
Conference	Open Source Summit Japan/2024

---

to post comments