Open-source software is also growing by leaps and bounds. According to Gartner’s 2021 Hype Cycle for Open-Source Software (OSS): “Through 2025, more than 70% of enterprises will increase their IT spending on OSS, compared with their current IT spending. Plus, by 2025, software as a service (SaaS) will become the preferred consumption model for OSS due to its ability to deliver better operational simplicity, security, and scalability.” Thinking of databases, the beef and potatoes of enterprise software, Gartner predicts that over 70% of new in-house applications will be developed on an open-source database. Simultaneously, 50% of existing proprietary relational database instances will have been converted or are being converted to open-source DBMSs. I’ll buy those numbers; I’ve been following Linux and open-source software since day one. Everywhere I go and everyone I talk to acknowledges that the pair run the software universe. But with great power also comes great responsibility, as Spider-Man knows. And it also comes, as many developers recently found out when multiple security vulnerabilities with the Apache Java logging open-source library Log4j2 were discovered, with great headaches. Also: ZDNet’s 2022 technology trend review: Open source, cloud, blockchain The log4j2 problems are as bad as bad can get. By the National Vulnerability Database (NVD) scale, it’s rated as 10.0 CVSSv3, which is perfectly awful. Its real trouble isn’t so much with open-source itself; there’s nothing magical about open-source methodology and security. Security mistakes can still enter the code. Linus’s law “is that given enough eyeballs, all bugs are shallow.” But if not enough developers are looking, security vulnerabilities will still go unnoticed. As what I’m now calling Schneier’s law says, “security is a process, not a product.” This reveals that constant vigilance is needed to secure all software. That said, the real pain-in-the-rump with log4j is with how Java hides what libraries its source code and binaries use in numerous Java Archive (JAR) variations. The result? You may be using a vulnerable version of log4j and not know until it’s been exploited. As Josh Bressers, Anchore’s vice president of security, recently explained, “One of the challenges the log4j vulnerability poses is actually finding it. Java applications and dependencies are usually in some sort of packaging format that makes the distribution and running really easy, but it can make figuring out what’s inside of those software packages difficult.” Fortunately, there are log4j scanners that can help you spot defective log4j libraries in use. But, they’re not perfect. Behind the log4j mess is another problem: How do you know what 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 some program you’re still using today. The answer is one that the open-source community started taking seriously in recent years: The creation of Software Bills of Material (SBOM). An SBOM spells out exactly what software libraries, routines, and other code has been used in any program. Armed with this, you can examine what component versions are used in your program. As David A. Wheeler, the Linux Foundation’s Director of Open Source Supply Chain Security, has explained, by using SBOMs and verified reproducible builds, you can make sure you know what’s what in your programs. That way, if a security hole is found in a component, you can simply patch it rather than search like a maniac for any possible problem code before being able to fix it. “A reproducible build,” explains Wheeler, is one “that always produces the same outputs given the same inputs so that the build results can be verified. A verified reproducible build is a process where independent organizations produce a build from source code and verify that the built results come from the claimed source code.” To do this, you and your developers need to track your programs in an SBOM using the Linux Foundation’s Software Package Data Exchange (SPDX) format. Then, to further safeguard that your code is really what it claims to be you need to notarize and verify your SBOM with services such as the Codenotary Community Attestation Service and Tidelift Catalogs. All this is easy to say. Doing it is hard. In 2022, open-source developers are going to be spending a lot of time checking their code for problems and then building SPDX-based SBOMs. Users, worried over Solarwind type disasters and log4j security problems, will be demanding this. At the same time, Linux developers are working on further securing the operating system by making Rust Linux’s second language. Why? Because, unlike C, Linux’s primary language, Rust is much more secure. Specifically, Rust is much safer than C at handling memory errors. Also: Rust takes a major step forward as Linux’s second official language As Ryan Levick, a Microsoft principal cloud developer advocate, explained, “Rust is completely memory safe.” That’s a huge deal, since, as Linux kernel developers Alex Gaynor and Geoffrey Thomas pointed out at the 2019 Linux Security Summit, almost two-thirds of Linux kernel security holes come from memory safety issues. And where do those come from? Inherent problems with C and C++. Linux isn’t going to be rewritten in Rust during this decade (check with me again in the 2030s). But a lot of Linux drivers and other code will be written in Rust going forward. As Linus Torvalds told me, while he’s “in no way ‘pushing’ for Rust,” he’s “open to it considering the promised advantages and avoiding some safety pitfalls.” “Still,” he concluded, “I also know that sometimes promises don’t pan out.” We’ll see how it all works out. One thing I know for certain is that securing code will become the top issue for Linux and open-source developers in 2022. They’ve both become too important for it to go any other way.
