When most organizations approach software supply chain security, too often they think only about securing the open source or third-party dependencies in their code. Unfortunately, this approach is too narrow in scope. Not enough organizations are thinking about securing the DevOps tools and infrastructure that make up the software development life cycle (SDLC) itself to prevent software supply chain attacks. By not securing these tools, the software supply chain attack surface is significantly larger than most organizations realize.
Why Secure the Software Supply Chain?
Headline-grabbing software supply chain attacks are on the rise. ENISA, the European Union cybersecurity agency, reported a 4x increase in the number of organized software supply chain attacks since early 2020. Gartner believes this trend will continue. Gartner predicts that 45% of all organizations will experience attacks on their software supply chains by 2025.
Hackers have shifted their focus away from production applications to attacking the DevOps tools and infrastructure that make up the software delivery pipeline. These tools – source control management systems (SCMs), build tools, deployment tools, Infrastructure-as-Code (IaC), registries, and more – are being targeted for several reasons. First, the number of entry points from which attackers can attempt to break-in is large, and covering them all is difficult. Second, DevOps tools are typically purchased by engineering teams and live outside the visibility and control of security. Finally, unlike protecting the production environment or detecting security vulnerabilities in source code, there are no widespread solutions to centrally secure and govern GitHub, Jenkins, JFrog, Kubernetes, and other tools that make up software supply chains. This vast attack surface combined with little to no security visibility or dedicated tooling are why software supply chains have become many organizations’ weakest links.
Attack Vectors Across the SDLC
The SDLC is an attractive target because of the abundance of attack vectors. Malicious actors have found it easier to gain access to the SDLC because of these numerous entry points – think about how many developer accounts, repositories, or misconfigured tools organizations have that could be compromised or leaked. Additionally, a successful exploit of one of these vectors could provide access to the production runtime environment and its data. Most organizations have a significant gap in their software supply chain coverage for these use cases, and traditional AppSec tools like SAST or WAF focus on other problems.
Figure 1 – Modern Software Delivery Pipeline Attack Vectors
Attack vectors in the SDLC include DevOps tools and infrastructure, developer accounts, insecure coding practices, code leaks, and more.
DevOps Tools and Infrastructure
As the tooling used to build modern software has grown increasingly complex, this lengthy list of components has become a broad attack surface. DevOps tools and infrastructure includes SCMs, build systems, package repositories, cloud providers, and more. Out of the box, these components are configured for release efficiency and velocity, not security. Complicating matters, these tools are often implemented outside the purview of security teams. Because of this, DevOps tooling could be compromised, as was the case with SolarWinds, especially if these tools are running default settings instead of being managed by consistent and rigorous security policies.
Code Tampering
Code tampering occurs when source code is altered or malicious code is injected, such as weaponizing an application against its users. Code tampering can occur at any point in the CI CD pipeline, and preventing it requires organizations to monitor all stages of the SDLC. Moreover, trends like everything as code and GitOps now store other things as code that can be tampered, including security policies, infrastructure templates, build rules, and more. This expands the potential attack surface for code tampering beyond feature code and enables attackers to compromise more of the SDLC.
Insecure Coding Practices
Beyond software vulnerabilities, coding can introduce a myriad of risks. Not following secure coding best practices exposes valuable resources and enables attackers to gain access to your systems. This includes such things as using hardcoded secrets, having infrastructure as code (IaC) misconfigurations, not standardizing on naming conventions, or storing sensitive information beyond secrets in code comments. Hardcoded secrets become dangerous when API keys, encryption keys, tokens, or passwords are exposed. Misconfigurations in IaC templates risk being replicated across many cloud environments and can expose application components or data to the public. Not following standardized naming conventions might be an early indicator of a compromised developer account.
Code Leaks
Code leaks – proprietary source code being exposed publicly either accidentally by a developer copying code to the wrong repo or intentionally by a malicious actor – present a serious risk to any organization. Not only is code an incredibly valuable asset in itself, but a code leak could expose secrets and often widens the attack surface so that unauthorized users are able to gain access to internal systems or data.
Software Supply Chain Security Frameworks
In response to the growing number of software supply chain attacks and to help shrink these attack vectors, several organizations have developed new frameworks designed specifically to address software supply chain security. This includes NIST’s Secure Software Development Framework (SSDF) and Google’s Supply Chain Levels for Software Artifacts (SLSA):
- NIST SSDF – In response to Executive Order 14028, “Improving the Nation’s Cybersecurity,” NIST developed a framework that identifies four best practice areas to promote secure software development practices. This includes preparing the organization, protecting the software, producing well-secured software, and responding to security vulnerabilities. Each category is documented to help organizations define secure development practices.
- Google SLSA – Designed in collaboration with the OpenSSF, Google SLSA is an end-to-end framework designed to ensure supply chain security, particularly for open source software. The goal of SLSA is to ensure the integrity of software artifacts throughout the supply chain so that organizations become better informed about the security posture of any software they consume.
Software Supply Chain Security Best Practices
When you look at the big picture, you quickly realize that the SDLC presents a significant risk to any organization not paying attention to these gaps. Organizations need to secure the tools that make up their pipelines to reduce risk and prevent a future breach, but how do you do that when so many potential attack vectors exist at every stage of the SDLC? And how do you put these new software supply chain security frameworks into practice?
The key is adopting a security tool that automatically identifies and helps remediate these pain points to reduce or eliminate attack vectors across the SDLC. To close these gaps, you need a tool that addresses the following use cases:
- Visibility and governance – Gaining visibility and enforcing consistent governance and security policies — such as least privilege, hardening authentication, and implementing branch protection rules — across all your teams, DevOps tools, and infrastructure.
- IaC security – Scanning IaC templates to ensure they are free from misconfiguration issues before they are deployed and mistakes are amplified across numerous cloud environments.
- Hardcoded secrets detection – Detecting and remediating any existing hardcoded secrets across many locations and using developer workflow integrations to prevent new hardcoded secrets from being introduced.
- Source code leakage – Identifying suspicious behavior to prevent leaks and detecting proprietary code exposure so any leaks are quickly contained.
- Code tampering prevention – Establishing safeguards in pipelines and the development process to ensure only authorized code and components are used in your applications.
When considering best practices for securing the SDLC, organizations need to verify not only the integrity of each component, but also how these components are interconnected in order to gain a full understanding of their risk.
Preventing Software Supply Chain Attacks
To prevent software supply chain attacks, organizations need to start thinking beyond just the lines of code in their applications. Looking only at source code fails to take in the bigger picture of securing the tools that your code moves through. Attackers have moved from targeting production applications to targeting the tools that make up the SDLC as a way to gain access to internal systems, valuable data, or even downstream customers.
Based on the recent rise in software supply chain attacks, malicious actors have been largely successful in compromising the SDLC, in part because there is such a wide range of attack surfaces. Surfacing and securing all these attack vectors manually is nearly impossible and prone to error. An automated solution that addresses these gaps is the answer.
The bottom line is that if the tools that make up your SDLC – SCMs, build systems, container registries, and more – aren’t secure, your applications aren’t secure either.
Want to Learn More?
A great place to start is with a free assessment of the security of your DevOps pipeline.
