Software supply chain attacks have been on the rise over the past several years. We see evidence of this daily with more and more headlines proclaiming SolarWinds-style attacks. In fact, Gartner predicts that by 2025, nearly half of all organizations will have experienced an attack on their software supply chain.
In response to this rapid increase in attacks, software composition analysis (SCA) vendors have done a deft job of positioning themselves as the answer to software supply chain security. Some of this makes sense. Organizations rely heavily on dependencies like open source and third-party software to develop solutions that meet the demands of today’s agile development environments. Knowing what’s in these dependencies that you didn’t build yourself and have no direct control over is part of understanding your own product. It also allows you to be more transparent with your customers.
But here’s the thing: While it’s important to know what’s in the dependencies in your application code, it’s not the only thing you need visibility into to prevent software supply chain attacks. If it were, we wouldn’t still be seeing a massive increase in this type of attack. After all, SCA is a relatively widely adopted technology. If it were the right solution to stop all software supply chain attacks, it would have done so by now.
Application Code Is Only a Piece of the Supply Chain Puzzle
Software supply chains consist of every person, process, or tool that touches your application across the SDLC. This includes everything from application code and developers to CI/CD pipelines and deployment environments. Securing vulnerable dependencies in your application code is only part of locking down your software supply chain. In fact, many of the attacks we see on the software supply chain don’t involve application code, but rather target other parts of the SDLC.
The National Telecommunications and Information Administration (NTIA) under the US Department of of Commerce, recently released a report titled The Minimum Elements of a Software Bill of Materials (SBOM) on behalf of the US federal government in which they acknowledged that identifying dependencies in application code is unlikely to prevent many of the software supply chain attacks we see today. The NTIA states, “Several recent high profile attacks in the supply chain did not target software components, but the tools and systems used to manage the software development and build process.”
To prevent attacks on your software supply chain, organizations need a complete view of their SDLC. Unfortunately, traditional SCA solutions provide either extremely limited or no visibility into development pipelines. This means even that though you may be diligent in scanning your open source components, you’re still at risk of a software supply chain attack.
Traditional SCA Shortcomings
One significant shortcoming for SCA is that it scans only application code. SCA offers no visibility into the tools and infrastructure that makes up the SDLC itself. And if it doesn’t provide visibility into your pipelines, how is it going to help you identify when something nefarious is happening?
If we’ve learned anything from the SolarWinds attack, it’s that threat actors are targeting the relatively unprotected pipelines that help transform your application from lines of code into something that is built and deployed into production. SolarWinds was infiltrated via a misconfigured TeamCity server. From there, threat actors were able to move laterally with ease and remained undetected for months. SCA scanning for vulnerable dependencies in your application does not protect you in any way, shape, or form from a similar attack.
Still think that SCA is enough to provide comprehensive supply chain security? You only need to look to Codecov as another high profile software supply chain breach. In this example, a malicious actor altered a Codecov bash uploader script so that downstream customers could be compromised and their credentials stolen. Scanning application code dependencies like open source libraries would not have prevented this software supply chain attack.
Attacks on development infrastructure are increasing. When the tools that help create and deploy your application are providing attackers access to your application, you need to be watching those tools and hardening your infrastructure to prevent attacks. Scanning only application code is not going to protect you.
The fact is that you need visibility, which is something that traditional SCA tools can not give you. To state it in even simpler terms: You can’t protect what you can not see.
Next-Generation SCA: Pipeline Composition Analysis
Next-Gen SCA, or Pipeline Composition Analysis (PCA), is designed to overcome many of the limitations of traditional SCA solutions, including its inherent lack of visibility into your SDLC. Because PCA connects with all the tools and infrastructure that makes up your SDLC, it is able to provide full visibility into your development pipelines. When you have full visibility, you are better able to lock down your software supply chain to stop attacks before they happen.
Furthermore, when you are able to see the full picture of your software supply chain, you can begin to make connections and correlations between all your security data. This gives you a better understanding of your environment and your risk. It also helps you prioritize your security activity so you can address your most critical needs first.
PCA Expands the Definition of a Dependency
In addition to full visibility, PCA also expands how dependencies are defined. In traditional SCA solutions, dependencies are only those in your application code, such as open source and third-party libraries. PCA, however, recognizes that many more dependencies impact your code and could be a potential way into your software supply chain. PCA scans for the following dependencies:
- Application code dependencies like open source and third-party components
- Development tools like SCMs, build tools, registries, and cloud providers, which could be vulnerable (for example, GitLab or JetBrains)
- Development tool plugins, used to enhance the functionality of various dev tools, are pieces of software that may contain vulnerabilities, like Jenkins Plugins or CircleCI Orbs
- Build modules like Github Actions or GitLab Runners created by other organizations and sourced from marketplaces
- Build module introduced dependencies which could contain vulnerable open source dependencies
- Infrastructure as Code (IaC) introduced dependencies include scripts or packages that may contain vulnerabilities
By expanding the definition of what constitutes a dependency, PCA casts a much wider net. This allows you to find and close the gaps on more potential vulnerabilities than traditional SCA solutions are able to.
Visibility and Context Are Key
Your code is who you are and what you’re selling to customers. You absolutely must protect it. At the same time, however, it is foolish to think that just scanning your application code is enough to secure your entire software supply chain when your software supply chain is extremely complex and made up of many tools, processes, and people.
Scanning your application code is only part of your overall application security program. Given how many headlines we’ve seen over the last 12-18 months about attackers gaining access to systems through dev tools, it is negligent not to secure your entire SDLC. To do this requires a new way of doing things. It requires full visibility and expanded definitions of what constitutes a dependency.
Pipeline Composition Analysis was created from the ground up to address the increased and complex demands of software supply chain security. PCA provides complete visibility and context across your entire pipeline so that events in your SDLC can be understood and ultimately remediated. This helps you reduce your overall risk.
Learn More
Want to learn more about how Cycode provides visibility, security, and integrity across all phases of the SDLC? Schedule a demo today!
