Supply Chain Attacks: Software Dependencies, Update Risks and Defense

Quick answer: A supply chain attack is an attacker hitting you not directly but by compromising a third party you trust (a software library, an update server, a supplier or a service provider). This is one of the most devastating forms of attack, because a single successful compromise can affect thousands of organizations at once that use that third party. Modern software is built on dozens or even hundreds of external dependencies, and every dependency, update channel and supplier is a point of trust. Instead of getting past your firewall, the attacker poisons a component you already trust, and you bring that poisoned component in with your own hands. Defense is provided by knowing every component you use with a software bill of materials (SBOM), scanning dependencies and pinning versions, verifying the source and signature of components, hardening the build pipeline (CI/CD) and regularly assessing suppliers.

No matter how well an organization protects its own code, it is only as secure as the external components it uses. When an open source library, a software update or a cloud service is compromised, everyone who trusts that component is at risk. We covered the holistic security of source code in source code security audit, SAST, DAST, SCA and the risks of leaked secrets in leaked API keys and secrets. This article addresses the most indirect but most devastating threat, supply chain attacks.

Why it is so devastating

In a traditional attack, the attacker tries to get past a single target one by one. In a supply chain attack, the attacker compromises a single point that many targets commonly trust. If a software library is used in millions of projects, poisoning that library means reaching millions of projects at once. If an update server is compromised, every organization that receives that update brings in the malicious code safely, because the update looks legitimate and signed.

This makes the attack both efficient and insidious. Efficient, because many victims are reached with a single effort. Insidious, because the victim does not run the malicious component through their own security controls, that component is already considered trusted. This is the power of a supply chain attack, using trust as a weapon.

Attack forms

Supply chain attacks come in several main forms, and each targets a different point of trust.

  • Dependency (library) attack. The attacker adds malicious code to a popular open source package or publishes a fake package with a similar name. It has two common techniques. Typosquatting is publishing a fake package with a name very similar to a popular package, so the developer downloads the malicious package when they mistype. Dependency confusion is uploading a package with the same name as an organization's internal package to a public repository, making the system mistakenly download the external one.
  • Update and build compromise. The attacker compromises a legitimate software's update server or build pipeline and places malicious code inside an official, signed update. Organizations install this update safely, because its source is legitimate.
  • Signing key theft. If the attacker steals a software's signing key, they can sign their own malicious code in that software's name, and verification systems trust it.
  • Malicious contribution into a dependency. An attacker can act as a trusted contributor for a long time and place a hidden backdoor into an open source project. This is the most patient and insidious form.
  • Supplier and service provider compromise. If a supplier or service provider with access to your systems is compromised, the attacker uses that access to pivot into your network.

Why traditional defenses miss it

What makes a supply chain attack dangerous is precisely that it comes from outside your security controls. A firewall stops an attack coming from outside, but an update you trust is brought in because it looks legitimate. A vulnerability scanner scans your code, but may not notice a backdoor hidden in a third party library. The problem is, a supply chain attack comes through a channel you already trust, and trust disables control. So defense requires giving trust not blindly but by verifying.

Attack form Target point of trust Example technique
Dependency attack Open source package Typosquatting, dependency confusion
Update compromise Update server Malicious code in a signed update
Signing key theft Code signing Signing malicious code legitimately
Malicious contribution Open source project Placing a hidden backdoor
Supplier compromise Third party access Pivoting into the network with access

Defense, visibility and SBOM

The first defense is knowing what you use. Most organizations do not know exactly which components their software is made of, because dependencies bring other dependencies and the chain deepens quickly. A software bill of materials (SBOM) lists all the components and versions inside a software. Without this list, when a vulnerability appears in a component you cannot even know whether you use it. SBOM is the foundation of supply chain security, because the one thing you cannot protect is what you do not know exists. We covered the general of external attack surface and asset visibility in external attack surface and OSINT.

Defense, dependency scanning and version pinning

Knowing the components is not enough, their security must be continuously monitored. Software composition analysis (SCA) automatically scans the dependencies you use against known vulnerabilities and malicious packages. Adding this to your build pipeline prevents a risky component from entering unnoticed. Another important practice is version pinning, fixing which version of dependencies you use and verifying the integrity of each version makes it harder for the attacker to quietly slip in a malicious version. We covered the general of SCA and secure code auditing in source code security audit.

Defense, source and signature verification

Before bringing a component in, you need to verify that it really comes from the source it claims and has not been altered. Code signing and integrity verification prove that a component was not poisoned in transit. In modern supply chain security, provenance records that prove where a software came from and how it was built stand out. Accepting an update or package not blindly but by verifying its source and signature is the basic defense against update compromise attacks.

Defense, build pipeline and least privilege

One of the attacker's most valuable targets is your build pipeline (CI/CD), because whoever compromises it can add malicious code to every software you produce. The build pipeline must be hardened, its access limited by the principle of least privilege, and the secrets inside it protected. The leak of keys and tokens used during the build endangers the entire supply chain, we covered the risks of leaked secrets in leaked API keys and secrets. Giving every component and every process only the narrowest privilege it needs limits the impact of a compromise.

Defense, vendor risk management

The supply chain is not only software dependencies, every supplier and service provider with access to your systems is also a link in the chain. If a supplier is compromised, their access becomes your risk. So suppliers must be assessed regularly, the access given to them limited and their security obligations clarified with contracts. If personal data leaks through a supplier, this is also a breach under KVKK, we covered the process in KVKK data breach notification, 72 hours.

The AI supply chain, a new frontier

Supply chain risk is no longer specific to software, it now covers AI models too. A ready downloaded model or a training dataset may be poisoned at its source. Using a model blindly is as risky as blindly trusting a software dependency. We covered AI model supply chain attacks and data poisoning in detail in AI data poisoning and model security.

Real world attack patterns

Supply chain attacks are not theoretical, the industry has repeatedly seen several devastating patterns in recent years. It is important to understand them not as specific events but as recurring patterns.

  • Update server compromise. The update infrastructure of a widely used enterprise software is compromised and malicious code is placed inside an official, signed update. Thousands of organizations install the update safely and all are affected at once. This pattern shows why compromising a single point creates such wide destruction.
  • Popular package takeover. The maintenance of an open source package used in millions of projects is handed to an attacker through social engineering, or a contributor account is compromised, then malicious code is added to the package. Every project that downloads the package gets the malicious code.
  • Patiently planted backdoor. An attacker acts as a trusted contributor for a long time and places a hidden backdoor into a critical component. This pattern shows that the attack can be a matter of patience lasting months or even years.
  • Dependency confusion. A package with the same name as an organization's internal package is uploaded to a public repository, and a misconfigured system downloads the external malicious package.

The common lesson of these patterns is this, the attacker targets not your weakest point but the point you trust the most.

Supply chain security frameworks

Supply chain security is now supported by mature frameworks, and an organization can build a systematic defense based on them.

  • NIST SSDF (Secure Software Development Framework, SP 800-218). Defines end to end practices of secure software development, from component verification to build security.
  • SLSA (Supply chain Levels for Software Artifacts). Defines trust levels for how a software is produced, focusing especially on provenance and build integrity.
  • SBOM standards (SPDX, CycloneDX). Ways to produce a software bill of materials in a standard format, so components become machine readable and scannable.

These frameworks turn supply chain security from an ad hoc effort into a systematic discipline. We covered its counterpart on the AI side, that is model supply chain security, in AI data poisoning and model security.

Supply chain security checklist

An organization can bring supply chain risk under control by verifying these items.

  • Is there a current SBOM listing all the components and versions of your software?
  • Are dependencies automatically scanned against known vulnerabilities and malicious packages (SCA)?
  • Are dependency versions pinned and their integrity verified?
  • Are the source and signature of downloaded packages and updates verified?
  • Is the build pipeline (CI/CD) hardened, its access limited with least privilege?
  • Are the secrets used during the build protected?
  • Are suppliers with access to your systems regularly assessed?
  • Is the source of the ready AI models and datasets you use verified?

An organization that completes this list is much more resilient against supply chain attacks. At DSET we audit the software and supplier chain with this framework.

Frequently Asked Questions

Does a supply chain attack concern only large software companies? No. Every organization that uses an external library, an update or a supplier is at risk, which is almost every organization. On the contrary, small teams that do not track their dependencies are more vulnerable.

Is using open source insecure? No. Open source, when managed correctly, is secure and offers the advantage of transparency. The risk is in using open source unaudited and unverified, not tracking its source. With SBOM and SCA it is used safely.

What is an SBOM and why is it needed? An SBOM is a software bill of materials that lists all the components and versions inside a software. It is needed because when a vulnerability appears in a component, only with an SBOM can you know whether you use it.

How do I notice a supply chain attack? It is usually not noticed directly, because it comes through a legitimate channel. So the defense is not detection but prevention, verifying components, scanning and auditing their source. Anomalous behavior monitoring can catch a compromise after the fact.

Sources

To audit your software and supplier chain and set up SBOM and dependency security, contact DSET.