In 2022, security will be the number one job of Linux and open source developers


Linux is everywhere. This is what all clouds, even Microsoft Azure, run. This is what makes the Top 500 supercomputers run. Heck, even the Linux desktop is growing if you can believe Pornhub, who claims Linux users are up 28%, while Windows users are down. 3%.

Open source software is also growing by leaps and bounds. According to the 2021 Gartner Free Software (OSS) Hype Cycle: “By 2025, more than 70% of businesses will increase their IT spend on OSS relative to their current IT spend. In addition, by 2025, Software as a Service (SaaS) will become the preferred consumer model of OSSs due to its ability to provide improved operational simplicity, security and scalability. “

Thinking of databases, the beef and potatoes of enterprise software, Gartner predicts that more than 70% of new internal applications will be developed on an open source database. At the same time, 50% of the existing proprietary relational database instances will have been converted or are in the process of converting to open source DBMS.

I will buy these numbers. I have been Linux and open source software since day one. Everywhere I go and everyone I talk to recognizes that the pair run the software world.

But with great power also comes great responsibility as Spider-Man knows. And, as many developers recently discovered when several security vulnerabilities with the open source Apache Java log4j2 logging library were discovered, it also causes great headaches.

The problems with log4j2 are as serious as it gets. According to the National Vulnerability Database (NVD) scale, it is rated at 10.0 CVSSv3, which is utterly awful.

Its real problem isn’t so much with open-source itself. There is nothing magic about the open source methodology and security. Security errors can still enter the code. Linus’ law is that with enough eyeballs all insects are superficial. But, if there aren’t enough developers to research, security holes will still go unnoticed. Like what I now call Schneier’s law, “Security is a process, not a product,” emphasizes that constant vigilance is required to secure all software.

That said, the real problem with log4j is the way Java hides the libraries used by its source code and binaries in many variations of Java Archive (JAR). The result? You may be using a vulnerable version of log4j and don’t know until it has been exploited.

As Josh Bressers, Anchore’s VP of Security, recently explained, “One of the challenges with the log4j vulnerability is finding it. Java applications and dependencies are usually in some sort of packaging format that makes distribution and execution really easy, but it can make it difficult to understand what’s inside those software packages. “

Fortunately, there are log4j scanners that can help you spot faulty log4j libraries that are in use. But, they are not perfect.

Another problem behind the log4j mess is “How do you know which open source components your software is using?” For example, log4j2 has been in use since 2014. You can’t expect anyone to remember if they used that first version in a program you still use today.

The answer is one that the open source community has started to take seriously in recent years: the creation of software classifications (SBOMs). An SBOM spells out exactly what software libraries, routines, and other code have been used in a program. Armed with this, you can examine which component versions are used in your program.

As David A. Wheeler, Linux Foundation’s director of open source supply chain security, explained, using SBOMs and verified reproducible versions, you can make sure you know what’s in it. your programs. That way, if a security hole is found in a component, you can just fix it rather than freaking out for a possible trouble code before you can fix it.

“A repeatable version,” Wheeler explains, is one that always produces the same outputs with the same inputs so that the results of the build can be verified. A verified repeatable build is a process where independent organizations produce a build at from the source code and verify that the generated results are from the claimed source code. “

To do this, you and your developers must track your programs in an SBOM using the Linux Foundation’s Software Package Data Exchange (SPDX) format. Then, to further ensure that your code is really what it claims to be, you need to legalize and verify your SBOM with services like the Codenotary Community Attestation Service and Tidelift Catalogs.

It is all easy to say. Do it hard. In 2022, pretty much all open source developers will spend a lot of time checking their code for issues and then building SPDX-based SBOMs. Users worried about Solarwind-type disasters and log4j security issues will ask.

At the same time, Linux developers are working to further secure the operating system by making Rust Linux the second language. Why? Because, unlike C, the main language of Linux, Rust is much more secure. Specifically, Rust is much safer than C at handling memory errors.

As Ryan Levick, one of Microsoft’s leading advocates for cloud developers, explained, “Rust is totally memory safe.” This is huge because, as Linux kernel developers Alex Gaynor and Geoffrey Thomas pointed out at the 2019 Linux Security Summit, nearly two-thirds of Linux kernel security vulnerabilities come from memory security issues. . And where do these come from? Problems inherent with C and C ++.

Now Linux is going to be rewritten in Rust. At least not this decade, check back with me in the 2030s, but a lot of Linux drivers and other code will be written in Rust in the future.

As Linus Torvalds told me, while he “isn’t pushing for Rust in any way,” he’s “open to it given the benefits promised and avoiding certain safety traps. Nonetheless, he concluded. : “I also know that sometimes promises don’t keep. . ”

We will see how it all plays out. Regardless of the details, one thing is certain. We’re going to see securing code become the number one issue for Linux and open source developers in 2022. They’ve both grown too important to be otherwise.

Related stories:

About Mariel Baker

Check Also

Fujitsu and RIKEN team up

TOKYO, May 17, 2022 — (JCN Newswire) — Fujitsu Limited and RIKEN today launched a …