Software supply chain attacks are breaking news headlines with increasing frequency. Infamous attacks like SolarWinds experience visibility that extends well outside the world of cybersecurity. In fact, according to a recent report from Gartner, “By 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains, a three-fold increase from 2021.”
For such a prominent threat category, one would assume that the security community is generally aligned on the basics like what makes up a software supply chain. Unfortunately, that’s not the case. There seems to be a common misperception that the supply chain is synonymous with the third-party dependencies that we use within our codebases. This is not completely wrong, but it focuses on one specific part — third-party dependencies — while failing to include other important parts of the supply chain itself. To fix this situation, it can be helpful to revisit the definition.
What Is a Software Supply Chain?
The concept of a supply chain is fairly straightforward; it’s anything that’s needed to deliver your product—including all the raw materials or components, processes, equipment, people, delivery channels and mechanisms, etc. It can be helpful to think about the supply chain of a physical good, like a car. For something like a car, a supply chain includes things such as:
- Major in-house produced components like engines and transmissions
- Third-party components like door handles, brake lights, and wiper blades
- The manufacturing facilities, machinery, and tooling used to assemble the car
- The workers working in the production facility
Figure 1 – Example of key parts of an auto manufacturer’s supply chain.
If any of these components are bad or broken, the car that is produced may be of low quality or have defects.
For modern software companies, their supply chains are similar to that of the car manufacturer outlined above. A software supply chain includes:
- Custom code (in-house components)
- Open source dependencies and libraries (third-party components – software bill of materials sbom)
- The DevOps tools and infrastructure that make up the CI/CD process (the manufacturing infrastructure)
- Developers and DevOps teams (workers)
Figure 2 – A comparison of software and traditional supply chains.
Important Implications for Securing Software Supply Chains
Accurately understanding what goes into a software supply chain becomes increasingly important when it comes time to secure it. If your definition is narrowly scoped around one or two of these pieces (for example, dependencies), it becomes difficult to implement security controls that can adequately protect the entire supply chain from being breached.
There are different types of tools that are useful software supply chain security. Static application security testing (SAST) helps find security vulnerabilities in custom code. SCA helps find and remediate vulnerabilities in third-party dependencies. Both of these are useful tools and part of a well-rounded security program, but they do nothing to address the myriad of attack vectors present in DevOps tools and infrastructure, or prevent attackers from targeting the developers using those tools. In fact, most organizations are over-provisioned in tools that help provide “security IN the pipeline” like SAST and SCA, but have little to nothing that enables “security OF the pipeline,” or making sure that the tools themselves (and users of those tools) aren’t exploited as an attack vector. This is exactly what we saw with SolarWinds where their systems were breached by way of TeamCity, their CI/CD system.
Figure 3 – Various cyber security tool categories aligned with the part of the software supply chain they protect.
Conclusion
Building security practices that are capable of effectively defending software supply chain threats starts with an accurate definition of what that includes. It’s important not to be myopic regarding your software development program. Widening one’s definition can help organizations expose potential gaps in their defenses around their DevOps Tools and users, and prevent them from being exploited as part of an attack.
Stay tuned for a future post on how to implement effective security for your software delivery pipeline, its tooling, and users.
