All software supply chain attacks share a core trait: they allow a threat actor to break into an organization’s IT estate by exploiting software vulnerabilities created by entities other than the organization.
The types of vulnerabilities attackers exploit during supply chain incidents come in many forms, as do the exploitation methods attackers use. Because of this variability, protecting your business against supply chain threats requires you to understand the most common software supply chain attack paths and deploy a multipronged defense against 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.
First, though, let’s talk about software supply chains.
Software Supply Chain Explained
If you’ve followed news about the surge in supply chain attacks, you probably know that a software supply chain is the collection of third-party software components and the underlying pipelines required to deliver products to market.
Although every business’s software supply chain is unique, their components typically include:
- Open-source libraries or packages and infrastructure as code (IaC) modules that developers incorporate into their own applications
- Version control systems (VCSs), which are third-party applications where proprietary code is stored, version controlled, and managed
- CI/CD pipelines, commonly 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 hosted on third-party infrastructure but with access to the business’s data and resources
You’d be pressed to find a business today that doesn’t rely on third-party software resources like those described above. Every business, in other words, has a software supply chain. What’s more, 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 in third-party code, as opposed to an application or resource your business created. But regardless of the weakness’ origins, your business can take measures to prevent supply chain attacks. Your business can detect and isolate vulnerable resources before they’re exploited.
Related: Anatomy of a Cloud Supply Pipeline Attack
Imagine one of the applications you’ve developed contains a vulnerable open-source library. You’re now at risk of a supply chain attack. The root cause of the threat is the vulnerability in the open-source library, which you inadvertently built into your application. But you can prevent a supply chain attack by identifying the vulnerability and mitigating it.
By updating to a newer version of the vulnerable open-source library before an attack occurs, you remove the vulnerability and its risk. If an exploit occurs before identifying the vulnerability, you can lock down infrastructure, maintain least-privilege access and have checks along the way to minimize the blast radius of the supply chain attack.
By taking action to detect and contain threats, you can prevent supply chain risks from impacting your business. But you need a thorough understanding of issues that result in supply chain attacks.
5 Common Supply Chain Security Issues
Because supply chain threats differ greatly, you need to defend a broad attack surface. Consider the potential weaknesses that can lead to a supply chain attack and ensure you’re equipped to prevent them.
1. Insecure Application Components
In cases like the Log4j vulnerability, vulnerable open-source software components are baked into applications. While open-source components provide plug-and-play functionality to get to market faster, they can bring inherited risk. This challenge 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. By embedding an SCA tool into your VCS, you can easily remove or patch affected components before application deployment.
2. Insecure Container Images
Another means by which supply chain vulnerabilities propagate across your environment is via insecure container images.
Most application containers are created using base images. Base images are typically operating systems, like Alpine or Ubuntu Linux, that potentially 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 they can take action before insecure third-party code becomes an attack vector.
3. Insecure IaC Templates
Infrastructure-as-code is a great way to automate the provisioning of infrastructure resources at scale. But IaC can also propagate a preventable misconfiguration in one template, opening several possible entry points or opportunities for supply chain attacks.
For instance, if you create an IaC template that provisions all your servers with an operating system containing an insecure library, the risk will exist on every server configured using the template. This is what happened with the version of OpenSSL that triggered the Heartbleed bug. And because infrastructure-as-code configurations are applied automatically, the likelihood of a developer noticing the vulnerability during the provisioning process is low.
Existing cloud controls can mitigate or amplify the effect insecure application components or containers have on your supply chain security. A vulnerable library hosted on a virtual machine with port 22, for example, 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, you have a much larger security issue than if that container had no host capabilities.
The best way to get ahead of misconfigurations is to automatically scan your IaC templates 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, enforcing 2FA and SSO and branch protection rules are 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 reduce the risk that threat actors could exploit security gaps in your workflow configurations.
Protecting Your Software Supply Chain
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. But adopting many different tools to achieve these goals can get complicated. 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.
Getting Started with CI/CD Security
If you want a deeper dive into CI/CD security, download the Top 10 CI/CD Security Risks technical guide. It covers key issues to prioritize at the start of your CI/CD security journey and gives practical tips to help you adopt CI/CD security best practices.