This post was written by Chris Romeo during his tenure at Security Journey. This article was originally appeared on TechBeacon.com on August 16, 2021. You can access it here.
Face it. Your software supply chain is under attack. You'd have to be hiding under a rock or in a bunker under the sea not to realize it. From SolarWinds-style attacks to language-specific repositories, supply chain compromises aren't going away—they're rising.
Do you understand why software supply chain attacks are increasing? Have you internalized the attacker's motivation to pollute your software supply chain and embedded this knowledge within your security culture? Ending supply chain attacks requires awareness of why attackers pay attention to these types of attacks.
To understand attacker motivations, stop and ponder the threat actors and their motivations. Due to the complexity of the software supply chain, threat actors will play differently in each scenario. Here are three case studies to illustrate, so that you can mitigate.
The basic exposure in this case arises from a known issue in an open-source package or library that is reported via CVE. A tool such as npm audit or OWASP Dependency Check throws an alert that there's a problem. This issue likely appears somewhere on the OWASP Top 10 and should have been easy to avoid. The exploit is possible when developers don't update the package for some period of time, which could be weeks, months, or, in a worst-case scenario, years.
The attacker's motivation in exploiting a plain vulnerability is to gain access to a web application and then complete a data breach in order to exfiltrate data to some attacker-controlled location on the Internet. Attackers breach data to sell it on the underground market for a profit, and such attackers are most likely cyber criminals.
In the second case, an attacker profiles and discovers a weakness in your software build pipeline. The flaw could be because your pipeline is exposed to the public Internet (gasp!) or because the attacker was already inside your internal network and pivoted to focus on the pipeline.
The attacker's motivation is to plant a weakness in your software build. After it is downloaded and installed at a large number of organizations, the attacker connects to each of them using the planted vulnerability. The level of coordination and preparation for this class of attack usually suggests a nation-state attacker—funded and resourced sufficiently to gain access to a software producer's internal network and orchestrate a pipeline compromise.
In the third case, an attacker sneaks a malicious package into a language-specific repository. The attacker's primary purpose is to get that version of the package downloaded and embedded into many production applications in order to do crypto-mining attacks: A malicious package contains extra code that connects to a central service and receives a workload for processing. The attacker uses the compromised systems as a cluster to mine cryptocurrency.
We've been lucky that malicious package attacks have not been more destructive or damaging. However, nothing prevents an attacker from using a malicious package to establish a back door (case study 2) or perform a data breach (case study 1). It's only a matter of time.
The software supply chain carries with it a certain amount of danger. You're essentially relying on software created by people who don't work for you, many of whom are working for free. If you simply trust these people and projects, you may escape unscathed, but that's not going to last forever.
If you've avoided software supply chain attacks so far, you've been lucky. The mitigating factors discussed here will help, but the best mitigating factor is awareness of the inherent risk in the software supply chain. Make sure everyone within your organization has that awareness. The package you patch or pipeline you harden may be the one that blocks a crippling supply chain attack.