For years, open-source software held the edge when it came to security compared to its commercial, closed-source counterpart offerings. After all, open source has the distinct advantage of being accessible to developers who can modify the code, as well as a vibrant and dedicated community that can draw attention to possible flaws and bugs.

That secure reputation, however, has been challenged. In 2017, for example, the massive Equifax breach was traced to an open-source vulnerability in Apache Struts that the company failed to patch in a timely manner. (Eventually, the U.S. Department of Justice accused a Chinese-based group of carrying out this attack.)

And in December 2021, several critical vulnerabilities were discovered in Log4J, a popular open-source logging framework used by thousands of websites and maintained by the Apache Foundation. These vulnerabilities raised concerns about how flawed code and libraries make their way into applications used by private businesses and government agencies, which then opens up networks to attacks.

“The transparency of the open-source software model is a double-edged sword. On one side, everyone can look at the code and audit it to identify and patch vulnerabilities. On the other side, threat actors can look at the code and find subtle issues that everyone else has missed,” explained Mike Parkin, an engineer at security firm Vulcan Cyber. “The advantages of this model have historically outweighed the disadvantages, with many eyes on the code and patches frequently appearing very rapidly after a vulnerability comes to light.”

The Log4J vulnerability, coupled with several other ongoing cybersecurity concerns such as the 2020 cyberespionage campaign that targeted SolarWinds customers, as well as the 2021 attacks against vulnerable on-premises Microsoft Exchange email servers, prompted the Biden administration to hold another cyber-focused conference in mid-January to bring more attention to the issue of open source and the global software supply chain.

“We are taking a prioritized approach, recognizing the ubiquity of these components and that they are now so broadly utilized across technology environments. This vulnerability will catalyze further attention, focus and investment, which will manifest in better security," Eric Goldstein, the executive assistant director for cybersecurity at the U.S. Cybersecurity and Infrastructure Security Agency, noted in the lead-up to the Jan. 13 event.

The summit included a Who’s Who of major tech and software firms, including Microsoft, Oracle, Google and IBM, as well as representatives from the Apache Foundation, the Linux Foundation, and the Open Source Security Foundation. 

The focus of the meeting was to look at ways that developers could not only write better and more secure code, but also ensure that software used by businesses and government agencies adheres to basic cybersecurity hygiene.

“The discussion focused on three topics: Preventing security defects and vulnerabilities in code and open source packages, improving the process for finding defects and fixing them, and shortening the response time for distributing and implementing fixes,” according to a White House readout of the summit.

Securing Open Source

For some cybersecurity observers, the sheer number of open-source projects available on platforms such as GitHub means that keeping up with flaws and vulnerabilities is a nearly impossible task, especially as the rate of application development speeds up. The Apache Software Foundation alone oversees some 227 million lines of code along with 630,000 contributors. 

With so much code to oversee, and the reliance on contributors to spot potential flaws, it’s increasingly likely that vulnerabilities make their way into applications used by hundreds and sometimes thousands of organizations, said Michael Isbitski, technical evangelist at Salt Security.

“While Apache receives some funding for supporting projects like Log4j and Struts, the funding and contributing labor is insufficient to support each codebase,” Isbitski told Dice. “Some open-source libraries have a long history of development and contributions, leading to legacy or old code that can be difficult to maintain. Some functionalities within those libraries may only exist for a small yet vocal percentage of users. When codebases age out or have fewer developer eyes on them, there’s often an increased likelihood that quality issues or vulnerabilities will be discovered in that code.”

Zach Jones, senior director of detection research at NTT Application Security, noted that some large open-source projects benefit from large tech firms and other users who then contribute back to these projects and help point out flaws. In many cases, however, smaller projects are missed.

“Many modern application platforms and frameworks are open source but benefit from the active participation of many companies, developers and security professionals,” Jones told Dice. “In these cases, somewhat paradoxically, a large number of discovered and fixed security flaws is a positive indicator of robust efforts to harden the project. In contrast, projects with lower levels of community participation are likely to contain flaws at the same or higher rates, but they go undiscovered providing real footholds for malicious attackers.”

Bolstering the software supply chain, however, is more complicated than simply checking code libraries for flaws, Isbitski noted. It also means putting more responsibility on those organizations with the resources to help contribute back to these projects and test code before it moves to production—helping the whole community by noting where the bugs might hide.

“Organizations can also help by testing code and reporting found issues to projects as part of responsible disclosure and coordinated vulnerability disclosure. Unfortunately, many organizations beyond large enterprises still lack adequate application security testing expertise or tooling to accomplish this,” Isbitski added.

SBOM

The White House summit that followed the Log4j disclosures also created additional interest in creating a software bill of materials (SBOM) standard. The administration first launched the notion when President Joe Biden signed his cybersecurity executive order in May 2021.

While definitions of SBOM vary, the Biden executive order defined it as a “formal record containing the details and supply chain relationships of various components used in building software.”

By creating an SBOM standard, businesses and government agencies can better understand what code or libraries were used to develop a particular application. In the case of a vulnerability, it then becomes easier to trace the flaw and alert those organizations using an application that contains the bug.

Rick Holland, CISO and vice president for strategy at security firm Digital Shadows, said without an SBOM, companies that purchase applications are essentially buying a black box that lacks specific details of how it was developed. If the U.S. government can develop rules for how federal agencies buy and evaluate software, these new standards can help private industries, as well.

“The Log4j vulnerability has increased the calls for technology vendors to be transparent and provide SBOMs, so their customers better understand the risks of deploying software and services,” Holland told Dice. “Like privacy and breach disclosure requirements, SBOMs won't gain market traction until there is a federal mandate… The risks can be even higher with smaller technology companies trying to get a product out the door. They may not have the same maturity or capabilities as larger software development shops with the resources to document all the software, libraries, functions, and dependencies code.”

Greater action by the federal government to recognize the flaws in open source and push for an SBOM is a step in the right direction to help organizations mitigate the vulnerabilities found in Log4j and other projects, noted Casey Ellis, founder and CTO at Bugcrowd.

“It’s an inconvenient truth of the internet that events like Log4Shell highlight every so often: Much of the software we use today is built on top of the work of part-time, unpaid volunteers,” Ellis told Dice. “The supply chain risk this creates isn’t broadly mitigated, and given that supply-chain resilience has been a theme, driven home to the White House by the pandemic, hopefully, these conversations will get this point across and spur on actionable changes at a policy level.”