Software supply chain security is all the rage these days, and for good reason. A steady increase in attacks over the past decade culminated in the “big one” (so far) in which the Russian SVR penetrated U.S. government networks, a cybersecurity company, and thousands of other targets via the IT company SolarWinds.

Some estimates suggest this breach will eventually cost $100 billion.

Thus, it makes sense that people talk about the topic a lot. With that said, though, I have recently heard some commentators refer an ever-increasing number of incidents as “software supply chain attacks” in a way that didn’t sit right with me.

For example, some have referred to the log4shell (CVE-2021-44228) incident as such an event.

After thinking about it for a while, I don’t agree with some of these characterizations and thought a post on the topic could help to guide the discourse.

Proposed definition

A software supply chain attack is any malicious event that impacts the target’s intended data confidentiality, integrity, or availability and where at least one step of the exploitation path involves the target’s intentional introduction of attacker-generated or -modified 3rd party (from the target’s perspective) code into its network through existing and otherwise non-malicious means.

This is a pretty weighty sentence, but I have thought through it carefully and think that it covers all the bases. So let’s break it down the key pieces:

• “malicious event that impacts the target’s intended data confidentiality, integrity, or availability**”** (CIA).

  • This section alone would be my general definition of a “cyberattack.” For it to qualify as such it must:

    • Be malicious (e.g. not an accidental configuration change or buggy software update that breaks something).

    • Change the target’s data CIA in a way that the target did not intend. Different businesses and applications have vastly different security requirements, so the target’s goals are important here.

• “target’s intentional introduction of malicious 3rd party (from the target’s perspective) code into its network.”

  • This is what distinguishes a software supply chain attack from others. The target must intentionally (although without knowing the consequences of doing so) incorporate the attacker’s code into its stack.

  • This would exclude a disgruntled programmer at a company building his own backdoor into the organization’s first-party code, which would “just” be an insider attack.

• “through existing and otherwise non-malicious processes.”

  • I will probably get some pushback here, but I think it’s important to make this distinction. Without this phrase, an organization whose employee gets an email with a malicious payload and executes it without knowing it to be dangerous, leading to a loss of data CIA, would count as suffering a software supply chain attack. This is not what most people think of.

  • The “existing” part implies that the introduction of the attacker-modified code was part of an existing business process, e.g. software update, which was the case in the SolarWinds and Kaseya attacks, both of which meet my definition.

  • The “otherwise non-malicious” requirement means that a rogue employee downloading ransomware into the network or a malicious third-party package into an application - who breaks the organization’s security policy by doing so - would not count as part of my definition. Basically, this means that a software supply chain attack must be a “trojan horse” type event where a bona fide actor is deceived into introduced the malicious code.

Examples

My definition excludes many things, including but not limited to:

• A nation-state actor exploiting an accidentally-created vulnerability in a piece of third-party software used by an organization, e.g. Chinese military-backed hackers breaching Equifax via CVE-2017-5638 in Apache Struts.

  • While this is an attack against part of the software supply chain (the open source Apache Struts component), it would not qualify as a software supply chain attack by my definition (I admit this is some delicate wordsmithing). This is because CVE-2017-5638 was not the result of attacker-generated or -modified code. This distinction can get tricky, for sure, and I would recommend referring to such events as “attacks against 3rd party software” to avoid confusion.

• An attacker typosquatting on commonly-used software packages, hoping that a developer mistakenly types in the wrong name of the package.

  • In this case, the “original sin,” so to speak, is the result of a new, manual step taken by an employee, rather than an existing business process.

  • I would describe this as a social engineering attack, as it tricks a developer into doing something, similar to a phishing email.

• A social engineering breach of one organization leading to a breach of one (or more) of its business partners not involving the introduction of attacker-modified code into the latter, e.g. the “Oktapus” attack against Twilio

  • In this case, attackers socially engineered employees at Twilio using fake Okta password reset prompts, and then proceeded to use Twilio’s phone verification services to compromise other organizations.

  • While the attackers were able to move “downstream” the software supply chain, the lack of incorporation of attacker-generated or -modified code into the exploitation path excludes this from my definition.

Additional examples meeting my definition include:

• Dependency confusion

  • This attack takes advantage of existing automated processes in software build pipelines to substitute in higher version-numbered (and malicious) packages that take precedence over lower version number ones. Since the process is automatic and the result of logic built into package managers, it meets my definition.

• Committing malicious code to an open-source project and breaching users of such code

  • Because the vast majority of open source software uses open source libraries, these represent an excellent vector for supply chain attacks. In addition to concealing malicious code in a pull request to an open source project and convincing the maintainer to approve it, ethical hackers have also shown it to be relatively trivial to gain commit access to such projects directly through technical means.

  • Malicious actors have also gained otherwise legitimate control over open source projects through social engineering. Assuming their code is used to infiltrate other organizations, the attack would meet my definition.

Conclusion

The goal of this exercise is to provide a common framing for an especially insidious type of cyber risk and facilitate more precise communication about it. My definition of a software supply chain attack is necessarily quite restrictive, and reasonable people might disagree with my framing. I invite proposed refinements to my model, and may update this page if I get any good ones.