Key takeaways:
• It’s a reality that almost all software relies, in some way, on open source software
• Sonatype’s State of Software Supply Chain Report 2021 found that in 2021 there was a 650% YoY increase in software supply chain attacks. With supply chain attacks rising from 929 to more than 12,000 across the course of 2021
• Open source software shouldn’t be avoided, but businesses need to monitor and mitigate the risks that come with it
• Supply chain attacks are not exclusively a concern of open-source software, but due to the interdependency of open-source packages, vigilance is important
At its heart, open source software is free, modifiable and redistributable. Communities of developers work together, on a global scale, for the continued development of the software.
Businesses gain many benefits when using open-source software. It can reduce overhead and accelerate product development. However, relying on open source software for critical parts of one’s technology can be a double edge sword…
In this post, we’ll examine some recent examples of software supply chain attacks and explore what you can do to mitigate them.
Open source software: high-quality elements of the software supply chain?
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.
So, where does open source software come into the software supply chain? The biggest building blocks in modern software development are open source: think OAuth, React, OpenSSL, Kubernetes and even the technology behind Google Chrome and Microsoft Edge. Linux, which powers everything from Android phones to The Large Hadron Collider, is famously open source.
Open-source software can be incredibly high quality. As highlighted in by the American department of defence:
According to a study conducted by the Boston Consulting Group, the average age of OSS developers is 30 years old. Most of these developers have received training in information technology and/or computer science and have an average of 11.8 years of computer programming experience.
American Department of Defence
Most of the larger and more successful open source software projects have a high level of process and governance in their development. However, there is a ‘long tail’ of open-source software not contained, controlled or subject to rigorous and frequent scrutiny. It simply exists in the public realm, where almost anyone can contribute to its development, and it is impossible to know who they are or where the code originated.
High-quality open source packages often become ubiquitous and find adoption in many products (as we will later discuss with Log4j). All of this makes open source software attractive to those looking to exploit or attack technology used by modern businesses.
Looking at Log4j
Some notable examples of open source vulnerabilities include Shellshock, Heartbleed and EternalBlue. In this post, we’re going to explore Log4j: described by some as “the worst security problem in a generation”.
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 November 2021, a vulnerability in Log4j was discovered that enabled malicious actors to deliver Remote Code Execution (RCE) attacks very simply.
RCE-enabling vulnerabilities are very severe because they often give access attackers control of affected systems and the ability to obtain passwords and logins, extract data, and more.
This vulnerability, in software used by millions of applications, caused panic within the industry and a scramble amongst software developers to understand their exposure to such a widespread and devastating exploit.
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 merely by pasting a short message into the game’s chat box.
Diagnosing and rectifying vulnerabilities introduced in the software supply chain
Log4j (and Shellshock, Heartbleed, EternalBlue and countless others before them) affected software teams that didn’t write and thus couldn’t fix.
When mission-critical issues are involved, this can put businesses in a dangerous situation: vulnerabilities are known, but fixes aren’t deployed.
With critical open source infrastructure, fixes can be very prompt. In the case of Heartbleed, a patch for OpenSSL (the vulnerable software) was written, tested and shipped within a week. Its widespread use made it attractive to attackers, but that same scale of use meant the community could quickly create and publish a fix.
However, this is only half of the problem. Patches may be published promptly, but businesses have two essential responsibilities:
- To understand where vulnerabilities exist in their software supply chain
- To quickly and correctly deploy patches to their software within a reasonable timeframe
What can be done to mitigate the risks present in the software supply chain?
The threat of public, critical vulnerabilities might suggest that avoiding open source would be best. However, we’d argue this isn’t the best approach to take towards software supply chain risk.
Instead, we’d encourage businesses to reap the benefits of open source, whilst still mitigating risk, with the following steps:
Step 1: Audit your software to produce a software bill of materials
A comprehensive audit of your system’s software supply chain is crucial to maintain security – and something that was recently made a legal requirement if you are selling your software to the USA federal government.
A clear and contemporary record of your software’s dependencies is the only way to know whether you’re exposed to supply chain attacks.
If you haven’t already audited your software dependencies, we urgently recommend you do so. We also suggest auditing your system again with every major release of your business’ software to keep your software bill of materials up to date. We’d also encourage you to create audit policies to help maintain compliance.
Whilst a manual audit can be completed, it would likely only highlight the most obvious dependencies and in order to successfully identify all dependencies in including transient dependencies (dependencies of dependencies) tooling is required.
Tools to consider are Snyk, Sonatype, Whitesource and OWASP Dependency-Check (Which can be integrated with Sonarqube). Security scanning functionality can also be enabled in cloud-hosted container registries.
Step 2: Automate auditing as part of the CI/CD process to continually monitor risks
In addition to manual and one off audits, automation should also play a key role. We suggest using a scanning tool to look for vulnerabilities and licensing issues as part of the software development workflow. Introducing scans in the CI/CD process reveals vulnerabilities and allows for them to be addressed before they are published to production is a good first step.
The use of open source software will continue to grow.
As its use becomes more commonplace within industry and commercial products, malicious actors will increasingly target open source codebases to exploit any vulnerabilities that can allow them to access user data or critical business information.
It’s vital for any business that relies on open source software to adjust its processes for these risks. While still reasonably rare, open source supply chain attacks can be devastating, and a proactive, well-informed understanding of one’s dependencies is the best form of defence.
With thanks to Callum Binner, David Bamber, David Horton, Fiona Fairbairn, Mark Hastry, and Rachel Ng.
