Skip to content
Menu
menu
Illustration of a man striding through a door in the shape of a 0 along a red wall of binary code. What you need to know about Log4Shell.

Illustration by Security Technology; iStock

Key Learnings from Log4Shell: The Fragility of Open-Source Cybersecurity is Still the Internet’s Biggest Weakness

The emergence of the Log4Shell vulnerability in December 2021 shook the technology world. An open-source framework used by software developers to record user activity and app behavior, Log4j has been downloaded millions of times and is one of the most popular tools for collecting sensitive information across corporate networks, websites, and applications.

Despite the fact the vulnerability first plagued the Internet almost a year ago, the U.S. Government branded Log4Shell as “endemic” in a recent Cyber Safety Review Board Report (CSRB), warning the bug is likely to linger for at least a decade.

Above all else, Log4Shell has crudely exposed the fragility of open-source security—caused by our flawed implementation of open-source components within software supply chains. Because, ironically, the biggest draw of open source is exactly what makes it so vulnerable: the universal availability of open-source components. This draw means when a severe enough exploit is discovered, it can have wide-reaching consequences and requires an all-hands-on-deck effort to identify and remediate at scale.

Indeed, the CSRB wrote that the Log4Shell event has “called attention to security risks unique to the thinly-resourced, volunteer-based open-source community.”

So, how can companies go about securing open source and, in doing so, prevent one of the Internet’s biggest assets from becoming its biggest weakness?

Agility at the Expense of Security: The Double-Edged Sword of Open Source

Because Log4Shell is an open-source Remote Code Execution (RCE) vulnerability, one of the highest-level security exposures a business can face, with a Common Vulnerability Scoring System (CVSS) rating of 10.0—the highest possible base score.

According to our research, Log4Shell has impacted 227 HackerOne customers to date, with a total of 657 unique, valid vulnerabilities recorded through HackerOne programs.

Because open-source software serves as the foundation of every software supply chain and most modern digital infrastructures, Log4Shell has quickly become a widespread and far-reaching issue that will impact businesses of all shapes and sizes for years to come.

The average application uses more than 500 open-source components that are constantly updating as apps evolve to meet customer needs and improve the user experience. Yet, in the wake of all the exciting opportunities open-source yields, we’ve chronically overlooked its protection by assuming that the responsibility of security wholly lies on open source maintainers alone.

Supply chain software is particularly fragile as vendors and partners become more interconnected. Attacks on open-source aspects of the supply chain skyrocketed by 650 percent in 2021. More open-source-based vulnerabilities will likely emerge if businesses don't recognize their responsibility to help bolster protection.

Perhaps most worryingly, four in 10 businesses are not confident in their open-source software security, while the time taken to remediate open-source vulnerabilities has more than doubled from 49 days in 2018 to 110 days in 2021.

It’s a classic case of running before we can walk. Volunteer project maintainers do the best they can with the limited resources, training, and time they can give to secure open-source projects. Without the support of other organizations that benefit from but do not directly contribute to the protection of open-source components, however, attack surfaces are left unprotected, and vulnerabilities can remain deeply embedded in application code for years.

Ethical Hacking: Closing the Cybersecurity Protection Gap

In response to open-source vulnerabilities such as Log4Shell, many businesses are turning to ethical hackers to narrow the gap between which aspects of security organizations own and what they can actively protect.

Hackers are motivated by a myriad of reasons—from securing the Internet to gaining cybersecurity experience to earning cash rewards. Bug bounty programs specifically pay hackers to expose potential vulnerabilities in their cyber defenses. Offering bounties helps to incentivize and direct hackers to hack on specific assets; in other words, payment helps guarantee the force of the hacker community will dig deeper and expose defensive frailties that overburdened volunteers or in-house teams might miss.

Working with providers that possess vast networks of hackers, companies can combine this hacking expertise with asset discovery, continuous assessment, and process enhancement to find and close gaps in the ever-evolving digital attack surface.

As we’ve been tracking Log4Shell and its meteoric rise, we’ve noticed hacking forums and communications streams have been eerily quiet. The bits and pieces we have picked from hackers mirror the general sentiment: this bug is historic due to its ubiquity and the potentially devastating impact it can have on any organization.

Choose your Vendors Wisely: Strategies and Standards for Open-Source Protection

The right blend of strategies and standards is critical for ensuring a robust open-source security posture.

Firstly, organizations should meticulously analyze all their software vendors based on incident readiness and security accountability. The supply chain is only as strong as its weakest link, so a single vulnerability in one vendor’s security defenses will invariably impact every component of the supply chain.

Once existing vendors have been screened, it’s time to establish concise integrity frameworks for onboarding new vendors, including their full internal security stack and how each software license plays into your operations.

Proactivity is always better than reactivity in the cybersecurity world. By ensuring new vendors possess a high standard for security—including accountability for their open-source components—businesses can future-proof themselves against potential issues down the line.

Lastly, contributing to open-source projects can take many forms. A contribution strategy begins with understanding the open-source components your company depends on and either financially contributing directly to those projects or to third-party open-source organizations like the Open Source Security Foundation (OpenSSF). Contributions to a project can also take the form of “donating” the time of your development, engineering, and security talent where the need is greatest. 

Don’t Go it Alone: Cybersecurity is a Collective Responsibility

Critically, when it comes to developing strategies to enhance open-source components, organizations must not fall into the old habits of keeping their cards too close to their chest. Sharing best practices and contributing to open-source projects not only decreases the dangers to your own company but also helps protect the shared open-source components we all depend upon.

As the CSRB highlights: “To reduce the recurrence of the introduction of vulnerabilities like [Log4Shell], it is essential that public and private sector stakeholders create centralized resourcing and security assistance structures that can support the open-source community going forward.”

The more knowledge and expertise we share, the stronger the Internet becomes. This isn’t just about shoring up your own defenses. We have a collective responsibility to safeguard the Internet as a whole—you can’t be a lone wolf when trying to survive in the cybersecurity wild.

Kayla Underkoffler is a senior security technologist at HackerOne.

© Kayla Underkoffler

arrow_upward