ALPS blog

After Log4Shell, how can we tackle a possible pandemic of open source exploits?

by Anthony Musk

If a week is a long time in politics, a month can sometimes feel like a lifetime in cybersecurity. Few of us working in cyber at the start of December could have predicted how the run up to Christmas would pan out. In the end, Log4Shelland the subsequent vulnerabilities found in Log4j made it several weeks of sleepless nights and anxious Zoom calls. The truth is that the logging utility is so ubiquitous, related threats will be with us for months or even years to come.

But that’s not the end of the story. Unfortunately for security professionals, their employers and customers, there’s a much wider concern. Trend Micro has been one of several authoritative voices warning of the impact of open source bugs on the security of the digital world. Unless we take action soon, Log4Shell could be the start of an extremely unwelcome trend: a cyber-pandemic fuelled by open source exploits.

The first of many? 

Log4jShell was widely regarded as one of the worst vulnerabilities in years—maybe of all time. Its CVSS score of 10.0 reflects a bug that’s relatively easy to exploit, is found in a near-ubiquitous Java-based logging tool that can also be difficult to locate due to dependencies, and that enables remote code execution. It was followed in quick succession by the discovery of four more vulnerabilities in the same package, of varying degrees of criticality.

The question is, what zero days could be lurking within other open source tools? Let’s take open source giant Apache, the steward of Log4j. A quick scan of live Apache Foundation Projects, of which there are over 200, reveals popular software such as Hadoop and OpenOffice. Just last week, a critical “Log4Shell-like” bug was discovered in a popular Java SQL database known as H2.

The number of vulnerabilities discovered in such offerings, and software in general, is soaring. In fact, 2021 was a record year for CVEs, the fifth year in a row this has happened. What’s more, if we use NIST’s analysis of CVSS severity distribution over time, we see a significant jump from 2016 onwards:

The DevOps challenge

The challenge with open source in particular is the way that its used. Software ate the world many years ago, and today every organisation runs on code. Without it, the global economy would collapse, and society with it. But that means an ever-greater pressure on developers to rush products to market, often without due care to vet them for security flaws. The post-pandemic push for digital transformation has only accelerated these trends.

A common way for them to do this is via pre-built open source packages, available from any number of repositories. It’s claimed that, in 2021, developers requested more than 2.2 trillion open source packages from the top four ecosystems: Java, JavaScript, Python and .NET. The problem is, what they download sometimes contains flawed code, unwittingly introducing cyber-risk by the back door. There’s also a case for saying that most open source toolsets are patched and updated less frequently than commercial software, giving hackers more time to find vulnerabilities in the code.

One vendor has even claimed that hackers are proactively inserting bugs into code in upstream repositories and then exploiting them before they’re discovered. Such attacks are said to have soared 650% year-on-year in 2021.

What needs to happen in 2022

Unfortunately, according to our research, 90% of IT decision makers claim their business would be willing to compromise in security in favour of digital transformation, productivity or other goals. This must change. The truth is that organisations don’t have to compromise on time-to-value versus security. With the right approach, they can have secure code and products delivered on time.

Here are some suggestions for getting there:

  • Know your software asset register, including all dependencies—what database software is running behind application X/Y?
  • Understand the data risk associated with each application—do you really know what your exposure of data per application could actually be, and the potential business fallout as a result?
  • What is the lateral threat based upon an application breach? Can you further segment your network in order to reduce the risk? Does a zero trust strategy make sense to reduce stopgap measures like reactive network remodelling?
  • Start left—proactively assess code repositories at the start of your build pipeline to ensure you’re not adding known vulnerabilities into your applications. And ensure your assessment tools can retrospectively check if newly discovered vulnerabilities are announced. One Trend Micro customer saved hundreds of hours in December by utilising this functionality
  • When shifting left, bake automated security into DevOps pipelines via APIs for minimum friction and maximum impact
  • Security teams are already overworked, and the huge global shortage of talent doesn’t bode well given soaring vulnerability disclosures, mounting cyber-risk and tool bloat. Trend Micro is offering a free vulnerability assessment tool to help businesses – as cited in a joint release by the NSA, FBI and NCSC

The coming 12 months are likely to be even busier than 2021, if that’s possible. As the threat landscape around open source continues to evolve, buckle up, and get ready for the ride.

Facebook
Twitter
LinkedIn

Featured News