All software supply chain attacks share a core trait in common: they allow threat actors to break into organizations’ IT estate by exploiting vulnerabilities in software created by other entities, not the business itself.
However, the types of vulnerabilities that attackers may exploit during supply chain incidents come in many forms. The exploitation methods that attackers use to execute supply chain incidents also vary. For these reasons, protecting your business against supply chain threats requires understanding the most common software supply chain attack paths and deploying a multi-pronged defense against all of them.
With that in mind, let’s walk through common supply chain attack paths, compare and contrast the severity of each type of attack, and discuss best practices for mitigating supply chain vulnerabilities.
But first, let’s talk about software supply chains.
What is a software supply chain?
If you’ve followed news about the recent surge in supply chain attacks, you probably know by now that a software supply chain is the collection of third-party software components and their underlying pipelines that are required to deliver products to market.
Although every business’s software supply chain is unique, software supply chain components include:
- Open source libraries or packages and infrastructure as code (IaC) modules that developers incorporate into their own applications
- Version control systems (VCSs) that are third-party applications in which proprietary code is stored, version controlled, and managed
- CI/CD pipelines which are often built on top of third-party commercial or open source foundations to integrate, deploy, and deliver software
- Infrastructure services, such as a cloud provider’s IaaS platform, that the business relies on to host its applications
- SaaS applications that are hosted on third-party infrastructure, but that have access to the business’s data and resources
Virtually every business today depends on third-party software resources like these. Thus, every business has a software supply chain, and every business is vulnerable to software supply chain attacks.
How supply chain attacks happen
When a software supply chain attack occurs, the root cause of the issue lies in a weakness within a pipeline, service, application, or software component. Supply chain attacks are unique in that they typically start with weaknesses within someone else’s code, as opposed to an application or resource that your business created. Despite the fact that it may seem as if that makes it out of your control, your business can still take several measures to prevent supply chain attacks by detecting and isolating vulnerable resources before they are exploited and by employing defense in depth.
For example, imagine that one of the applications you’ve developed internally contains a vulnerable open source library. You are now at risk of a supply chain attack, and the root cause of the threat is the vulnerability in the open source library—which is now a part of your application. Even though the open source library was developed externally, you are still at risk. Your ability to prevent that risk from being exploited in a way that makes your own application vulnerable or data accessible hinges on identifying the risk and mitigating it. Updating to a newer version of the vulnerable open source library before an attack occurs is the most obvious fix, but if an exploit were to occur before the vulnerability was identified, locking down infrastructure, maintaining least-privilege access, and having checks and balances along the way can minimize the blast radius of a supply chain attack.
The takeaway from this example is that, even though you can’t prevent the risks that trigger supply chain vulnerabilities, you can prevent supply chain risks from impacting your business by taking proactive action to detect and contain threats. And to effectively identify and manage supply chain security threats, you need to have a thorough understanding of common issues that result in supply chain attacks.
5 common supply chain security issues
Because supply chain threats come in multiple forms and can be exploited through a variety of techniques, there is no one simple solution to address all potential threats. Instead, you must deploy defenses that can protect you from multiple types of software supply chain risks.
The following are the most common types of weaknesses that can lead to a supply chain attack, along with guidance to help you stop each one.
1. Insecure application components
In cases like the Log4j vulnerability, vulnerable open source software components are baked into applications. By many estimates, open source software accounts for up to 90% of modern codebases. Open source components provide plug-and-play functionality to get to market faster but introduce inherited risk. This challenge is by no means a new one, and has been answered by the giant (and growing) AppSec space.
Developers should use AppSec tools like Software Composition Analysis (SCA) to detect vulnerable third-party components within their source code and then remove or patch those components prior to application deployment. It’s a best practice to embed these SCA tools into your VCS so developers can easily fix these issues.
2. Insecure container images
Another means by which supply chain vulnerabilities can be easily propagated across your environment is via insecure container images.
Most application containers are created using base images. Those base images are typically operating systems, like Alpine or Ubuntu Linux, which can contain a variety of vulnerabilities. If you create a container using a vulnerable base image and deploy the container to production, the vulnerabilities inside the base image will leak into your production environment.
Container image scanning is the best way to mitigate this threat. Image scanners automatically detect vulnerabilities in the base image or other layers of a container, then alert developers so that they can take action before insecure third-party code becomes a vector for a supply chain attack.
3. Insecure IaC templates
IaC is a great way to automate the provisioning of infrastructure resources at scale. However, IaC can also turn an easily preventable misconfiguration in one template into a widely propagated risk that can be used as a supply chain attack entry point or pivot to sensitive data or mission-critical IT assets.
For instance, if you create an IaC template that provisions all of your servers with an operating system that contains an insecure library—such as the version of OpenSSL that triggered the Heartbleed bug—that risk will exist on every server that is configured using the template. And because the IaC configurations are applied automatically, the chances that a developer would notice the vulnerability during the provisioning process are low. Existing cloud controls can either mitigate or amplify the effect that insecure application components or containers have on your supply chain security. As an example, a vulnerable library that is hosted on a virtual machine with port 22 open to the world could be susceptible to exploit and having a reverse shell opened up. And if you have a vulnerable container in a Pod with privileged access, that introduces a much larger security issue than if that container had no host capabilities.
The best way to get ahead of misconfigurations is to scan your IaC templates automatically early and throughout the development lifecycle. By automatically validating IaC configurations via IDE plugins, CLI tools, VCS integrations, or as CI/CD build steps, you can detect misconfigurations before they become supply chain risks.
4. Insufficient access controls
In some cases, supply chain vulnerabilities that might otherwise be minor turn into major incidents because of insecure access controls.
For example, consider the “Cr8escape” bug, which allows anyone with permission to deploy a Kubernetes Pod to escape the Pod and execute code as the root user on the Pod’s host node. The flaw results from a bug in the CRI-O container runtime. Any organization using an insecure version of CRI-O as part of its supply chain is subject to the bug.
In this case, strong access controls wouldn’t fix the root cause of the risk—that would require updating CRI-O to a secure version—but they would significantly reduce the chances that attackers could exploit the bug. By ensuring that only those users who strictly need permission to create Pods have that permissions, organizations would minimize the risk that a malicious user could exploit the CRI-O bug to launch a privilege escalation attack.
5. CI/CD and version control weaknesses
Version Control Systems (VCSs) and CI/CD pipelines are the lifeblood of software supply chains in that they provide the foundation in which code—including third-party libraries or IaC modules—is stored, compiled, and deployed.
In addition to vulnerabilities and misconfigurations, weaknesses in underlying supply chain pipelines can be used as entry points for attackers. To combat VCS weaknesses, best practices such as enforcing 2FA and SSO and branch protection rules is a must. CI/CD pipelines present a stiffer challenge in that they require some exposure to the outside world. Use of unsanitized metadata and overly privileged contributors can lead to malicious injections and data leakage.
Scanning VCS organization and repository settings, as well as CI/CD configuration files, is a great way to enforce many of these software supply chain best practices and reduce the risk that threat actors could exploit security gaps in your workflow configurations.
The days of software supply chain security are still early, but it’s already clear that the best way to mitigate supply chain risks is by adopting an approach to security that embeds automated security processes into your existing systems to make security as seamless as possible. Protecting your software supply chain requires visibility and coverage across all risks using IaC scanners, SCA software, container image scanners, CI/CD and VCS security, and beyond. But adopting many different tools to achieve these goals can get complicated and overwhelming quickly. That’s why an integrated and cohesive approach can help you adopt frictionless code security, which will enable you to detect and mitigate threats across all parts of your supply chain.
To see how Bridgecrew can help you improve your supply chain security, check out our recent blog about our newest supply chain security capabilities.