5 Types of Software Supply Chain Attacks Developers Should Know

What do ambulances in the UK, the Norwegian government, and a major Russian bank have in common? They were all victims of successful supply chain attacks in July 2023. Could you be next? It’s more likely than you think.

Organizations entrust more sensitive data to vendors and third parties (like government agencies and critical infrastructure operators) than ever as part of their software development and operations. This trust enables threat actors to employ supply chain attacks as a sophisticated and long-term tactic in global cyber-warfare. So it’s no wonder that supply chain attacks have become a national concern and warranted an executive order on behalf of the Biden Administration.

But what does any of that have to do with your software development processes? And what can (and should) you do to ensure that your code and applications are not susceptible to this increasingly popular attack vector and code security threat? Let’s get to know our enemy.

What are Supply Chain Attacks?

Before we define these attacks, it’s worth looking under the hood to see exactly what a supply chain is in the context of software. The software supply chain is an umbrella term for all the tools and services that enable developers to transform their code into applications served to users in production. 

The growing list of such resources employed in the SDLC today includes (but is not limited to) 

• third-party code 
• components 
• binaries 
• external tools like package managers 
• CI/CD products 
• security scanning and testing modules 
• build and deployment automation scripts

A software supply chain attack (sometimes called a third-party attack) is a malicious attempt to gain access to a target business by exploiting a weakness in the systems or processes of a third-party vendor or partner. 

Supply chain attacks are a particularly lucrative attack vector for cybercriminals, as a single compromise of one vendor can open the door to breaching thousands of organizations before the attack is even discovered.

How Do Supply Chain Attacks Work?

Bad actors employ automated scanning tools to dig through public code repositories, cloud native applications, unprotected networks, and public package repositories. They don’t even have to sit in front of their PC to find vulnerabilities, common cloud misconfigurations, code secrets, and other opportunities to infiltrate software development and distribution systems. 

Once the attackers secure (pun intended) their access to the code and tools used to build and deploy it, they can plant malware and backdoors in the code the company delivers to its trusting users.

5 Types of Supply Chain Attacks

There are numerous ways to classify software supply chain attacks. From a DevSecOps perspective, the best way to group them is by attack vector and initial entry point.

1. Source code threats

Compromised source control systems and poorly secured code assets are two leading causes of successful supply chain attacks. Bad coding practices, human error, and insecure development environments can open the back door to malicious code injection or leak sensitive information.

Hackers need to gain high-privileged access to the repository by getting their hands on some user credentials with permissive privileges. Alternatively, they can exploit a vulnerability accidentally introduced into the code by developers and missed in code review, or code secrets erroneously pushed onto a public-facing repository.

SolarWinds is an example of such an attack, which abused exposed server passwords in code stored on a public GitHub repository.

2. Compromised software dependencies

Most software today depends on third-party resources to operate. These dependencies (both direct and transitive) include frameworks, application libraries, base images for containers, and packages that enable functionality while saving developers time writing code someone else already wrote.

When a popular public resource, such as an open source library, is compromised, the domino effect introduces a vulnerability in every piece of software that employs the library. Without effective software composition analysis tools, these vulnerabilities cannot be detected.

The best-known example of an attack exploiting a vulnerability in a popular open source tool is that of Log4j, where millions of computers were exposed to malefactors.

3. Dependency confusion / package typo squatting

Dependency confusion is a subset of dependency-based supply chain attacks that relies on developers misspelling the names of popular packages in repositories like NPM and PyPi. 

While there is no prominent example of this type of supply chain attack being successfully executed by cybercriminals, security researchers have proven that even developers at Apple and Microsoft can be tricked into installing malicious software packages masquerading as popular packages with misspelled names.

4. Build tooling

With more development teams and companies adopting ‘everything as code’ as a best practice, codified configurations can become a software supply chain risk. Configuration files (in YAML format or any other) that are not adequately secured create potential attack vectors and expose the build toolchain to tampering.

One of the issues with supply chain attacks on build tooling is that it can be challenging for development teams to identify and mitigate them. One such example is the CodeCov supply chain attack, where hackers successfully infected Codecov’s CI/CD pipeline and gained access to, potentially, thousands of customer networks.

Without effective and continuous CI/CD security, hackers can take over or infect the CI/CD pipeline used to deliver software, giving them nearly unlimited control over what the application contains and what it can do. Malicious changes pushed in software updates or a hidden crypto miner script in production applications can expose end users to a whole plethora of trouble, from identity theft to corporate espionage on demand, to name just a few.

A prominent example of a supply chain attack exploiting the delivery mechanisms of software updates is the case of ASUS, which delivered a software update with a malicious backdoor to (by some estimates) over a million computers in 2018.

How Can You Defend Against Supply Chain Attacks

What can you do to reduce supply chain risks? Here are the top ten actions you must take immediately to ensure supply chain integrity and reliability:

1. Identify and map the software components and dependencies.
2. Monitor software dependencies for vulnerabilities and automate security patching.
3. Use only trusted sources for software components and development tools.
4. Consider using SCA tools to detect and manage software dependencies.
5. Implement strong access controls, authentication, and authorization.
6. Conduct scheduled and unscheduled security testing and vulnerability assessments.
7. Enforce code signing and verification to ensure code authenticity.
8. Establish SSDLC processes that include security requirements, testing, and risk assessments.
9. Include SAST and DAST testing in the development process.
10. Establish an incident response team and document disaster recovery plans.

Protect Your SDLC From Supply Chain Attacks With Spectral

Protecting your code and applications from supply chain attacks requires, first and foremost, a cultural shift left at the core of your software and platform engineering strategy. That said, even with a deep understanding of code and application security, humans still make mistakes.

To protect your code, you must go beyond best practices and implement tools and processes that are seamless guardrails against human error. With turnkey integration with any popular CI/CD environment and the tools you already employ in your DevOps stack, Spectral protects your code and infrastructure from getting caught in the potentially devastating fallout of a supply chain attack.

Create a free account today and see how Spectral keeps vulnerabilities, secrets, and misconfigurations out of your code.