Some of the biggest building blocks in modern software development are open source: think OAuth, React, OpenSSL, Kubernetes and even Chromium, the technology behind Google Chrome and Microsoft Edge. Linux, which powers everything from Android phones to The Large Hadron Collider, is also famously open source.
Open-source tools are free, modifiable and redistributable. Communities of developers work together, on a global scale, for the continued development of the software. Some high-quality open-source solutions such as WordPress have become ubiquitous and well-known. Others provide valuable functionality while lurking in the codebase of commercial products and proprietary apps.
The widespread use of open-source code makes it a magnet for malicious actors looking to exploit vulnerabilities to access user data and critical business information. While still reasonably rare, open-source attacks can be devastating.
Businesses that rely on open-source software must understand their risk exposure in order to mitigate it. A proactive, well-informed understanding of vulnerabilities and dependencies is the first step of defense.
The good, the bad and the ugly of open-source software
Open-source software can be incredibly high quality. Most open-source developers have training in information technology or computer science and average nearly 12 years of programming experience. In addition, most of the larger and more successful open-source software projects incorporate a high level of process and governance.
However, there is also a long tail of open-source software that is not contained, controlled or subject to rigorous scrutiny. It simply exists in the public realm, where almost anyone can contribute to its development. In these cases, it’s impossible to know who the developers are or where the code originated.
When an open-source vulnerability is discovered, affected businesses are in a dangerous situation. Since they didn’t write the code, they won’t be able to fix it until a patch is released. Notable instances include Shellshock, Heartbleed and EternalBlue.
In the case of critical open-source infrastructure, fixes may be swift. With Heartbleed, for example, a patch to fix a vulnerability with the OpenSSL cryptographic software library was written, tested and shipped within a week. The same scale of use that made OpenSSL attractive to attackers also meant there was a sizable community to quickly create and publish a fix.
Yet, even when a patch is published promptly, it only solves part of the problem. Businesses need to understand where their vulnerabilities exist, and they must correctly deploy the patch within a reasonable timeframe in order to avoid becoming a target.
The cautionary tale of Log4j
Log4j is an open-source library software developers use to create logs — a form of digital record used for development, operational and security purposes. In December 2021, security researchers discovered a vulnerability in Log4j that enabled malicious actors to deliver remote code execution (RCE) attacks very simply. Vulnerability CVE-2021-44228 was classified at the highest risk level of 10 in the National Vulnerability Database of the National Institute of Standards and Technology (NIST), and the Center for Internet Security (CIS) categorized it as a zero-day vulnerability. It’s been described as “the worst security problem in a generation.”
RCE-enabling vulnerabilities are especially concerning because they enable attackers to control affected systems. With this control, the attacker can obtain passwords and logins, extract data and more. Discovering that this vulnerability existed in software used by millions of applications was cause for widespread panic. Software developers scrambled to understand their exposure.
High-profile victims of the vulnerability included AWS, iCloud, Steam and the video game Minecraft. In Minecraft’s case, the attackers could run remote code on the Minecraft servers by merely pasting a short message into the game’s chat box.
A two-step approach to identifying and mitigating open-source threats
The software supply chain refers to all of the code elements involved in an application’s development. Libraries, frameworks and tools — including software components — are considered part of the software supply chain. Any of these elements may rely on open-source software.
The threat of critical vulnerabilities might seem like a good argument for avoiding open-source solutions altogether, but this is impractical for many businesses. Fortunately, businesses can reap the benefits of open source, while mitigating risk, with a two-part strategy.
Step one: Take inventory of your code
Perform a comprehensive audit of your software supply chain to produce a bill of materials. A clear and contemporary inventory of code elements and dependencies is the only way to fully understand your exposure to supply chain attacks. (Not only is this a crucial step for all businesses in order to maintain security — it’s also a legal requirement when selling software to the US government.) Continually re-audit and update your inventory with every major release to keep your software bill of materials up to date.
While it’s possible to perform this audit manually, a manual audit would likely only highlight the most obvious dependencies. To identify all dependencies, including transient dependencies (dependencies of dependencies), leverage a code-scanning tool. You can also enable security scanning functionality in cloud-hosted container registries.
Along with your software bill of materials, document your audit policies to demonstrate how you’ll maintain compliance.
Step two: Automate auditing as part of the CI/CD process
Use a code scanning tool to automate auditing within the CI/CD process. This will reveal open-source vulnerabilities and licensing issues and allow you to address them before they are published to production.
Today, almost all tech solutions rely on open-source software in some way. With the advantages of open-source, businesses can’t avoid it — and they shouldn’t. What they do need to do is understand, monitor and mitigate its risks.
Thanks to Crosslake contributors, Callum Binner, David Bamber, David Horton, Fiona Fairbairn, Mark Hastry and Rachel Ng.
Need help assessing and mitigating your open-source software risk, developing OSS policies or integrating OSS scanning into your software development lifecycle? Connect with our team to learn more about our Insight Accelerators.
