Don’t leave open source open to vulnerabilities

Open-source software has become the foundation of the digital economy: Estimates are that it constitutes 70 to 90% of any given piece of modern software. 

But while it has many advantages — it is collaborative, evolving, flexible, cost-effective — it is also rife with vulnerabilities and other security issues both known and yet to be discovered. Given the explosion in its adoption, this poses significant risk to organizations across the board. 

Emerging issues are compounding longstanding, traditional vulnerabilities and licensing risks — underscoring the urgency and importance of securing open-source software (OSS) code made publicly and freely available for anyone to distribute, modify, review and share. 

“Recently, the open-source ecosystem has been under siege,” said David Wheeler, director of open-source supply chain security at the Linux Foundation. 

He stressed that attacks aren’t unique to open source — just look at the devastating siege on SolarWinds’ Orion supply chain, which is a closed system. Ultimately, “we need to secure all software, including the open-source ecosystem.”

Situation critical for open source

According to a report by the Linux Foundation, technology leaders are well aware of this fact, but have been slow to adopt security measures for open source. 

Among the findings: 

• Just 49% of organizations have a security policy that covers (OSS) development or use. 
• 59% of organizations report that their OSS is either somewhat secure or highly secure. 
• Only 24% of organizations are confident in the security of their direct dependencies. 

Furthermore, on average, applications have at least five outstanding critical vulnerabilities, according to the report. 

Case in point: The systemic issues that led to the Log4Shell incident. The software vulnerability in Apache Log4j — a popular Java library for logging error messages in applications — was both complex and widespread, impacting an estimated 44% of corporate networks worldwide. And it’s still affecting businesses today. 

As a result, a recent Cyber Safety Review Board report declared that Log4j has become an “endemic vulnerability” that will be exploited for years to come. 

Meanwhile, the Cybersecurity and Infrastructure Security Agency (CISA) recently announced that versions of a popular NPM package, “ua-parser-js,” were found to contain malicious code. The package is used in apps and websites to discover the type of device or browser being used. Compromised computers or devices can allow remote attackers to obtain sensitive information or take control of the system. 

Ultimately, when a vulnerability is publicly disclosed in OSS, attackers will use that information to probe systems looking for vulnerable applications, said Janet Worthington, Forrester senior analyst. 

“All it takes is for one application out of the thousands probed to be vulnerable to give an attacker the means to breach an organization,” she said. 

And just consider the dramatic implications: “From baby monitors to the New York Stock Exchange, open-source software powers our digital world.” 

Security building blocks

Issues with code itself are of growing concern: Traditional checks focus on known vulnerabilities and don’t actually analyze code, so such attacks can be missed before it’s too late, explained Dale Gardner, Gartner senior director analyst. 

Vulnerabilities contained in code allow malicious individuals a means of attacking software (Log4shell being a perfect example). That “highly impactful and pervasive” exploit resulted from a flaw in the widely-used Log4j open-source logging library, explained Gardner. 

The exploit enables attackers to manipulate variables used in naming and directory services, such as Lightweight Directory Access Protocol (LDAP) and Domain Name System (DNS). This allows threat actors to cause a program to load malicious Java code from a server, he explained. 

This issue dovetails with a growing focus on supply chain risks, particularly the introduction of malware — cryptominers, back doors, keyloggers — into OSS code. 

Ensuring the security of OSS in a supply chain requires that all applications be analyzed for open-source and third-party libraries and known vulnerabilities, advised Worthington. “This will allow you to fix and patch high-impact issues as soon as possible,” she said. 

Gardner agreed, saying that it is critical to leverage existing tools — including the software bill of materials (SBOM) — to help users understand what code is contained in a piece of software so they can make more informed decisions around risk, said Gardner. 

While SBOMs “aren’t magic,” Wheeler noted, they do simplify tasks — such as evaluating software risks before and after acquisition, and determining which products are potentially susceptible to known vulnerabilities. The latter was difficult to determine with Log4Shell, he pointed out, because few SBOMs are available. 

Also, he emphasized: “People will have to use SBOM data for it to help — not just receive it.” 

Not just one solution

It’s important, though, to look at other tools beyond SBOMs, experts caution. 

For instance, Wheeler said, more developers must use multifactor authentication (MFA) approaches to make accounts harder to take over. They must also leverage tools in development to detect and fix potential vulnerabilities before software is released. 

Known approaches must be easier to apply, as well. Sigstore, for instance, is a new open-source project that makes it much easier to digitally sign and verify that a particular software component was signed (approved) by a particular party, Wheeler said. 

Gardner pointed out that organizations should also ask themselves: 

• Does a particular project have a good track record for adopting security measures? 
• Do contributors respond quickly in the event of a security incident? 

Simply put, “ensuring the integrity and safety of open source has become a vital task for organizations of all kinds, since open source has become ubiquitous in modern software development,” said Gardner. 

Evolving risk landscapes

Another important security risk to address: Rapidly updating internal software components with known vulnerabilities, said Wheeler. 

There’s been a dramatic increase in reused components — as opposed to rewriting everything from scratch — making vulnerabilities more likely to have an impact, said Wheeler. Secondly, reused components are often invisible, embedded many tiers deep, with users typically having no way to see them.

But, developers can integrate various tools into their development and build processes to warn them when a vulnerability has been found in a component they use, and often they can propose changes to fix it. 

And, they can — and should — respond to such reports by using automated tools to manage reused components, having automated test suites to verify that updates don’t harm functionality, and supporting automated update systems to deliver their fixes, said Wheeler. 

Education is essential

But there’s a deeper underlying issue, Wheeler said: Relatively few software developers know how to develop secure software or how to secure their software supply chains. Simply put, this is because developers don’t receive adequate education — and again, it isn’t just an open-source problem. 

Without fundamental knowledge, various practices and tools won’t be much help, he said. For example, tool reports are sometimes wrong in context – they can miss things – and developers don’t know how to fix them. 

While there will always be a need to find vulnerabilities in existing deployed software and release fixes for them, proper security in OSS will come by “shifting left,” said Wheeler. That is: Preventing vulnerabilities from being released in the first place through education, proper tooling, and overall tool improvement. 

“Attackers will attack; what matters is if we’re ready,” he said. 

Collaboration is essential

Experts across the industry agree that they must work together in this fight. 

One example of this is the Linux Foundation’s Open Source Security Foundation (OpenSSF), a cross-industry initiative that works to identify solutions for greater open-source security via compliance, governance, standardization, automation, collaboration and more. 

The project has 89 members from some of the world’s largest software companies — AWS, Google, IBM — security companies and educational and research institutions. This week, the project inducted 13 new members, including Capital One, Akamai, Indeed and Purdue University. 

Notably, OpenSSF will team with Google and Microsoft on an Alpha-Omega project announced in February that aims to improve the software supply chain for critical open-source projects.

“The software industry is slowly starting to wake up to the fact that it is now reaping what it has sown,” said Wheeler. “For too long, the software industry has assumed that the existing infrastructure would be enough security as-is. Too many software development organizations didn’t focus on developing and distributing secure software.”

Federal oversight

The U.S. federal government is also leading the charge with regulatory activity around software security — much of this prompted by the Cybersecurity Executive Order issued by President Joe Biden in 2021. The order is prescriptive in what actions producers and consumers of software must take to help avoid software supply chain risks. 

The Biden administration also held White House Open Source Security Summits in January and May of this year. This brought experts from the government and private sectors together to collaborate on developing secure open-source software for everyone. 

One result: A 10-point open-source and software supply security mobilization plan aimed at securing open-source production, improving vulnerability disclosures and remediating and shortening patching response time. This will be funded by both the government and private sector donations to the tune of $150 million. 

Worthington, for one, called the results “monumental, even for D.C.”

“We anticipate more collaboration with the government, the open-source community and the private sector focused on securing open source in the future,” she said. 

And, Gardner pointed out, the very nature of the open-source development model — that is, multiple contributors working in collaboration — is “extremely powerful,” in helping establish more security measures across the board. 

Still, he cautioned, this is reliant on trust, which history has shown can be easily abused. 
“Happily, the open-source community has a strong grasp of the issues and is moving quickly to introduce processes and technologies designed to counter these abuses,” said Gardner. All told, he added, “I’m optimistic we’re on a path to mitigate and eliminate these threats.”