How Businesses Can Handle the Pandemic of Open Source Bugs

In mid-January, representatives from some of the world’s biggest tech companies and open source foundations were summoned to the White House. On the agenda: how to better manage the risks associated with open source software use. The already-notorious Log4j vulnerabilities at the end of 2021 raised awareness of such risks at the highest levels of government. Now a broad public-private consensus is being forged on how to move forward more securely. 

But it will take time to make any kind of impact. What can IT and security teams do right now to tap the undoubted benefits of open source software without driving up cyber risk? Fortunately, quite a lot.

What’s the challenge with open source software?

In theory, open source software should be more secure than proprietary code developed in-house by technology vendors like Microsoft, Oracle et al. That’s because, as the name suggests, it’s open for all contributors to review. With many eyes on, there are more opportunities to spot and correct coding errors than in commercial software development. Users of the software can also access the code base to assess how secure it is. This makes many well-maintained open source software implementations a pretty safe bet.

However, as Google President of Global Affairs, Kent Walker, said after the White House meeting, not all open source projects can boast “many eyes” on code. That’s because much of the work to fix known vulnerabilities is done on an ad hoc, voluntary basis by contributors.

The challenge with software reuse

This is a significant challenge, when you consider that open source software has become “the connective tissue for much of the online world,” as Walker says.

Another issue is the way open source is often used by developers. No company today can operate without software at its center. Whether it’s a retailer relying on an e-commerce site or a financial institution whose customers demand mobile banking—code is the fuel which powers modern business. But such is the pressure on stretched DevOps teams to produce a continuous stream of new features for customers, that the only way to meet sky-high consumer expectations is to use pre-built open source code from third-party libraries. A pandemic-era digital transformation drive has only exacerbated these pressures.

These pre-built packages are available from various sources and are used in huge quantities. One estimate suggests that developers requested over 2.2 trillion of them in 2021 from the top four open source projects. There’s just one problem: this third-party code sometimes contains vulnerabilities which subsequently find their way into home-grown applications. Such is the ubiquity of this code, that it can pose a covert threat to the organizations that use it. What’s more, as the Log4j story showed, open source dependencies can often be complex, making it difficult to find vulnerable code even if there is a patch available.

The bad guys are also doing their best to capitalize. Some are actively finding and inserting vulnerabilities into open source repositories so they can exploit them in downstream organizations. One vendor claims such attacks surged 650% from 2020 to 2021.

What is the government doing about it?

Fortunately, the current administration is doing something about it. The White House meeting focused on three key areas: 

• Preventing vulnerabilities in code and open source packages in the first place.
• Improving the process for finding defects and fixing them.
• Shortening the response time for distributing and implementing fixes.

Possible solutions for each of the above were suggested, including:

• Making it easier for developers to write secure code by integrating security features into development tools and securing the infrastructure used to build, warehouse and distribute code (ie using code signing and stronger digital identities).
• Prioritizing the most important open source projects, like Apache, and deploying sustainable mechanisms to maintain them.
• Accelerating the use of Software Bills of Material, which will make it easier to know what is in the software itself.

What can businesses do to minimize open source risk?

Many business leaders still don’t “get” the strategic importance of security. One recent study found that 90% of IT leaders believe their business would be willing to compromise on cybersecurity in favor of digital transformation, productivity, or other goals.

This mindset is the first thing that needs to change. Hopefully incidents like Log4j will begin to turn the tide in favor of greater cyber risk awareness at senior levels. But then what? Here are some suggestions for reducing open source risk in the organization:

• Gain visibility into your software assets and, crucially, any and all dependencies lurking within.
• Calculate the business risks associated with each piece of software, in terms of possible data exposure/theft or outages.
• Consider a zero trust strategy including micro-segmentation, so that even if a network is breached, the blast radius will be contained and your corporate crown jewels kept safe.

• Move towards DevSecOps practices, which require security to be baked seamlessly into the development pipeline, right from the start. This is known as “shifting left” and will make your risk mitigation more proactive.
• Use vulnerability assessment tools to scan for any known bugs as soon as they are announced.

Organizations operating in a post-pandemic world need to innovate just to stay competitive. That means DevOps teams under greater pressure than ever to rush new products and features to market. Proactively mitigating open source risk is the only way to maintain this level of innovation without exposing the organization to serious security breaches.