Building secured software is essential to preventing software supply chain attacks

• The weakest link in the software supply chain today is around dependency integrity
• The number of supply chain attacks has increased by 300% in 2021

Supply chain attacks are a new type of threat that targets suppliers and software developers. The intention is to spread malware by infecting trustworthy programs in order to gain access to source codes, development procedures, or update mechanisms.

The number and sophistication of supply chain attacks have been quickly rising since the SolarWinds and CodeCov incidents. According to Aqua Security, the numbers have increased by a staggering 300% in 2021 compared to 2020. Given that not every attack is reported or discovered, the actual number is probably far higher.

Due to the fact that the number of attacks has more than tripled in the last year, one of the most important demands is to secure the software delivery process.

“We need to make sure that the way that we build our software is actually secure because we are seeing more and more attackers, targeting the way we actually build our own software. [This is important for developers because] when you build software, there are multiple steps along the way. And any of those steps can be a stepping stone for an attacker to try to compromise our software,” said Tzachi (Zack) Zornstain, Head of Software Supply Chain, Checkmarx.

That’s where Supply Chain Levels for Software Artifacts (SLSA) come in place.

SLSA is a security framework, a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure in projects, businesses or enterprises. It’s where “safe enough” can be translated to as “resilient as possible”, at any link in the chain.

Zornstain asserts that in order to deploy SLSA effectively, “we need to understand that every step within this process can be compromised; and we have seen such kinds of attacks.”

According to him, the weakest link in the software supply chain today is around dependency integrity. Dependencies are basically open-source code, which is the code made publicly for people to take from strangers.

“A lot of times, you take [codes] automatically and you don’t have the right mechanism to validate that. This is where we are seeing more and more attackers based today,” he added.

No chain is stronger than its weakest link, and the software supply chain is no exception to this fact. Dependency acts as the weakest link for a number of reasons:

• Lack of standards for external code: Standards for code uploaded to repositories are not enforced by open-source communities. Therefore, there can’t be expectations that open-source contributors adhere to standards or certify their code because there are no standards for external code packages.
• Difficult-to-spot techniques: Attacks that confuse users with dependencies use sneaky tactics like vulnerabilities in package manager setups and actions that enable repository jacking.
• Transitive dependencies: Transitive dependencies, in which one package calls another, which calls another, and so forth, may pose a hidden risk. For instance, a piece of software may have hundreds of layers, with dependencies between each component. An attacker will have completed the crucial stage of first access if they are able to breach a downstream dependent.

When an open-source dependency incorporated into an application is found to have a known vulnerability, utilize vulnerability databases and alert matching to try and mitigate the risk. But avoiding compromised dependencies from the start is a better course of action.

Furthermore, don’t take code from strangers when choosing open-source code packages. Developers are unable to manually review everything. By employing an automated, multi-phase analysis to obtain visibility into the health of a code package, developers may select open-source packages more wisely and write code more quickly.

---

---

---