In a world where more & more organizations are adopting open-source components as foundational blocks in their application’s infrastructure, it’s difficult to consider traditional SCAs as complete protection mechanisms against open-source threats.
Using open-source libraries saves tons of coding and debugging time, and by that – shortens the time to deliver our applications. But, as codebases become increasingly composed of open-source software, it’s time to respect the entire attack surface – including attacks on the supply chain itself – when choosing an SCA platform to depend upon.
The Impact of One Dependency
When a company adds an open-source library, they are probably adding not just the library they intended to, but also many other libraries as well. This is due to the way open-source libraries are built: just like every other application on the planet, they aim for a speed of delivery and development and, as such, rely on code other people built – i.e., other open-source libraries.
The actual terms are direct dependency – a package you add to your application, and a transitive dependency – which is a package added implicitly by your dependencies. If your application uses package A, and package A uses package B, then your application indirectly depends on package B.
And if package B is vulnerable, your project is vulnerable, too. This problem gave rise to the world of SCAs – Software Composition Analysis platforms – that can help with detecting vulnerabilities and suggesting fixes.
However, SCAs solve only the problem of vulnerabilities. What about supply chain attacks?
Supply Chain Security Best Practices Cheat Sheet
Software supply chain attacks are on the rise.
According to Gartner’s predictions, by 2025, 45% of organizations will be affected. The traditional Software Composition Analysis (SCA) tools are not enough, and the time to act is now.
Download our cheat sheet to discover the five types of critical supply chain attacks and better understand the risks. Implement the 14 best practices listed at the end of the cheat sheet to defend against them.
Attacks VS. Vulnerabilities
It might not be obvious what we mean by an “unknown” risk. Before we dive into the differentiation, let’s first consider the difference between vulnerabilities and attacks:
A vulnerability:
- A non-deliberate mistake (aside from very specific sophisticated attacks)
- Identified by a CVE
- Recorded in public databases
- Defense possible before exploitation
- Includes both regular vulns and zero-day ones
- Example: Log4Shell is a vulnerability
A supply chain attack:
- A deliberate malicious activity
- Lacks specific CVE identification
- Untracked by standard SCAs and public DBs
- Typically already attempted to be exploited or activated by default.
- Example: SolarWinds is a supply chain attack
An unknown risk is, almost by definition, an attack on the supply chain that is not easily detectable by your SCA platform.
SCA Tools Aren’t Enough!
SCA tools might seem to solve the issue of protecting you from supply chain risks, but they do not address any of the unknown risks – including all major supply chain attacks – and leave you exposed in one of the most critical pieces of your infrastructure.
Thus, a new approach is needed to mitigate the known and unknown risks in the ever-evolving supply chain landscape. This guide reviews all the known and unknown risks in your supply chain, suggests a new way to look at things, and provides a great reference (or introduction!) to the world of supply chain risks.