In a world where more and more organizations are adopting open source components as fundamental blocks in their application infrastructure, it is difficult to view traditional SCA as a complete protection mechanism against open source threats.
Using open source libraries saves a lot of coding and debugging time, thus shortening the time it takes to deliver your application. But as code bases increasingly consist of open source software, it’s time to respect the entire attack surface when choosing attack options, including attacks on the supply chain itself. SCA platform rely.
a dependency effect
When companies add open source libraries, they may not only add the library they want, but many others. This is due to the way open source libraries are built: like every other application on the planet, they target delivery and development speed, and therefore rely on code built by others – i.e. other open source libraries.
The actual terms are direct dependencies (which are packages that are added to the application) and transitive dependencies (which are packages that are added implicitly by dependencies).If your application uses package A, and package A uses package B, then your application indirectly rely on On package B.
If Suite B is vulnerable, then your project is also vulnerable. This problem gave rise to the field of SCA (Software Composition Analysis), which can help detect vulnerabilities and recommend fixes.
However, SCA can only address vulnerability issues. What about supply chain attacks?
Supply Chain Security Best Practices Cheat Sheet
Software supply chain attacks are on the rise.
According to Gartner forecast, by 2025, 45% of organizations will be affected. Traditional software composition analysis (SCA) tools are not enough, now is the time to take action.
Download our cheat sheet to spot five types of critical supply chain attacks and better understand the risks. Defend against them by implementing the 14 best practices listed at the end of the cheat sheet.
🔗 Download the cheat sheet now
Attack VS.loopholes
It may not be obvious what we mean “Unknown” risks. Before we dive into the differences, let’s consider the difference between a vulnerability and an attack:
A loophole:
- Unintentional errors (except for very specific complex attacks)
- Identified by CVE
- Recorded in a public repository
- Can defend before exploiting
- Includes regular vulnerabilities and zero-day vulnerabilities
- Example: Log4Shell is a vulnerability
Supply chain attacks:
- deliberate malicious activity
- Lack of specific CVE identification
- Not subject to standard SCA and public DB tracking
- Usually an attempt has been made to preset being exploited or activated.
- Example: SolarWinds is a supply chain attack
Almost by definition, unknown risks are: an attack Located in the supply chain that is not easily detected by the SCA platform.
SCA tools are not enough!
SCA tools may seem like they solve the problem of protecting you from supply chain risks, but they fail to solve any unknown risks (including all major supply chain attacks) and leave you exposed to one of the most critical parts of your infrastructure.
Therefore, a new approach is needed to mitigate known and unknown risks in the changing supply chain environment. this guide Reviews all known and unknown risks in supply chains, suggests new ways of looking at things, and provides a great reference (or introduction!) to the area of supply chain risk.
