Third-party breaches now account for 30% of all data breaches, double what they were just a year ago, according to Verizon.
With today’s applications depending on open-source libraries, APIs, and third-party tools and services, this expanded attack surface is driving one of the fastest-growing threats: the software supply chain attack.
In fact, OWASP recently updated its Top 10 for 2025, adding A03: Software Supply Chain Failures, showing just how serious the threat is.
What Is a Software Supply Chain Attack?
A software supply chain attack happens when threat actors target the code or dependencies used to develop and deliver software, rather than attacking the application itself.
Attackers infiltrate components that developers trust, such as vendor updates and third-party packages, and then reach production systems through legitimate means.
As these vulnerabilities often go undetected, the same compromised component can be exploited across numerous applications and organizations, vastly multiplying the impact.
An infamous example of this is the SolarWinds Orion software breach. Hackers used a supply chain attack to insert malicious code into a trusted software update. More than 18,000 SolarWinds customers installed the updates, allowing the malware to spread across organizations.
How Software Supply Chain Attacks Work
Attackers now have multiple ways to exploit trusted software components. The tactics vary, but they all abuse the trust that developers have in the components they’re working with. Here are a few:
-
Compromised software updates: Hackers inject malicious code into legitimate updates from trusted vendors. Since developers and automated systems expect these updates, the malicious code gets through.
-
Dependency poisoning: Attackers publish malicious packages with names almost identical to legitimate ones, tricking developers into installing the wrong dependency. Typosquatting and dependency confusion attacks also exploit human error in package names.
-
Credential theft: Developer credentials or access tokens are stolen by attackers who push malicious code directly to trusted repositories, making it look completely legitimate.
-
Targeting pipelines: Automated workflows, such as CI/CD pipelines, can be exploited to distribute compromised code across production environments.
-
Vendor compromise: Partner systems can be leveraged as backdoors to reach larger, more valuable organizations.
Software Supply Chain Attack Examples
The past couple of years have shown just how sophisticated these attacks have become and how easily they can bypass defenses.
-
XZ Utils Backdoor: A hidden backdoor in a Linux compression library went unnoticed for months. The attackers created trust with maintainers through seemingly helpful contributions before injecting malicious code.
-
Polyfill.io Hijack: After taking over this well-known JavaScript CDN, attackers injected malicious code that was then served to thousands of websites. Sites that relied on Polyfill.io were unknowingly serving malware to users. This shows the risk of unmonitored third-party scripts.
-
Shai-Hulud Campaign: This large-scale operation targeted multiple open-source projects and developer accounts at the same time, implanting backdoors into popular packages.
These software supply chain attack examples reveal a worrying trend where even known software can become a risk when the supply chain is compromised.
The Impact of Software Supply Chain Attacks
Once attackers infiltrate a single dependency, they gain access to countless organizations through channels everyone trusts. Security tools aren’t looking for threats in npm packages that have been used for years, which is precisely what makes detection so difficult.
Developers tend to assume, by default, that open-source components and vendor updates are safe. After all, thousands of other developers use them. That trust is what attackers exploit.
Then there are the complex dependency chains. An application might directly use 20 packages, but those packages depend on others, and so forth. Before you know it, there are thousands of transitive dependencies that are nearly impossible to track manually.
Delayed detection is also a problem, as malicious changes can hide within trusted processes for months, and by then, attackers have remained embedded and exfiltrated data.
When a popular package is compromised, the attack automatically scales across every application that uses it, resulting in widespread impact and turning a single successful breach into an industry-wide crisis.
Preventing a Software Supply Chain Attack
There’s no single way to prevent software supply chain attacks, so a layered approach to security can greatly reduce risk:
-
Adopt a zero-trust approach: Never assume third-party code or updates are safe; always verify sources.
-
Use SBOMs (Software Bill of Materials): Maintain visibility into all dependencies, including transitive ones.
-
Enforce code signing and integrity checks: Ensure software components haven’t been tampered with, and protect sensitive files from unauthorized access or modification.
-
Perform regular dependency audits: Identify outdated or vulnerable packages before attackers do, and give special attention to critical vulnerabilities that could be exploited in supply-chain attacks.
-
Secure the development pipeline: Protect build environments with strong authentication and least-privilege access, and safeguard sensitive files throughout the process.
-
Train developers continuously: Raise awareness of how dependencies and open-source tools can become attack vectors through secure coding training.
The Role of Developers in Software Supply Chain Security
Developers play an integral part in software supply chain protection because every decision can either reduce or introduce risk, from adding a new library to pushing a release.
Organizations need more than one-off training sessions for developers, as they need to continuously practice identifying, mitigating, and preventing threats in realistic environments.
What Developers Should Practice
Developers need hands-on experience with the threats they could face in production, which includes:
-
Identifying malicious dependencies: Evaluate maintainers, review commits, and watch for suspicious behavior.
-
Responding to compromised dependencies: Quickly assess impact and remediate safely to stop threat actors from executing malicious activities.
-
Detecting typosquatting attacks: Find subtle differences in package names.
-
Validating integrity and signatures: Verify packages and know how to act if checks fail.
-
Securing build processes: Identify and fix vulnerabilities introduced during automated builds or deployments.
-
Analyzing transitive dependencies: Trace hidden vulnerabilities and their ripple effects.
Embedding Supply Chain Security in DevSecOps
Training works best when it’s integrated into existing development processes, promoting a security-first mindset.
-
During onboarding, new developers should understand what the supply chain risks are and make security a default part of their thinking.
-
Before adding dependencies, teams can establish checkpoints where developers review relevant training before introducing unfamiliar libraries or frameworks to projects.
-
After major incidents, targeted training helps teams understand what happened and how to prevent similar compromises.
-
As part of continuous learning, regular, focused training keeps developers ahead of emerging attack patterns and helps protect unsuspecting users from supply chain attacks.
Also, training should complement existing security tools, such as those that analyze code for known vulnerabilities or embed relevant training directly into developer workflows.
AI and New Supply Chain Risks
AI and LLM-based tools introduce yet another new layer of supply chain risk. Many LLM applications rely on third-party models, plug-ins, datasets, and integrations, and if any of those components are compromised, the entire system could be at risk.
Supply chain vulnerabilities are also listed in OWASP’s LLM Top 10, as they can lead to biased outcomes and security breaches.
For example, fine-tuning a chatbot with a manipulated public dataset or using a model from an untrusted source could introduce hidden vulnerabilities. Even libraries and APIs used to run the model can become entry points for attackers.
A growing concern is package hallucination, also known as “slopsquatting”, where an LLM recommends or references a fictitious package that developers mistakenly install. This makes it easier for attackers to publish malicious packages under those names.
Every external dependency needs to be verified and isolated if it cannot be fully controlled, the same as with traditional software supply chains.
Building a Robust Software Supply Chain with SecureFlag
SecureFlag empowers teams to build secure software from the earliest stages of the software development life cycle (SDLC).
Through interactive, lab-based training, including agentic AI labs, teams learn how to identify risks in dependencies, validate open-source components, and secure build pipelines before attackers can exploit them.
Our platform provides teams with hands-on experience with the vulnerabilities that affect today’s software processes. This includes data security and protecting sensitive information, such as credit card data, from compromise in supply chain attacks.
SecureFlag training covers traditional vulnerabilities and AI-driven threats, ensuring teams can deliver secure software from the first keystroke to the final release.
