By Cyber Defense Technologies May 5, 2026 4 min read
Most security programs are designed to keep attackers out. Supply chain attacks bypass that effort by compromising something the organization already trusts: a software vendor, an open-source library, a development tool or an update mechanism. The victim installs the attack themselves, often with a valid digital signature.
These attacks are especially attractive to sophisticated actors because a single compromise upstream can reach thousands of organizations downstream.
Software supply chain incidents that shaped the field
-
2020
SolarWinds Orion
A compromised build process delivered a backdoor through signed software updates to thousands of customers.
-
2021
Codecov
A modified script in a widely used development tool exposed credentials in customers’ build environments.
-
2023
3CX
A trojanized desktop application reached customers through the vendor’s own update process.
-
2024
XZ Utils
A long-running effort to gain maintainer trust inserted a backdoor into an open-source compression library, caught before wide release.
How supply chain attacks work
Compromised build systems
Attackers breach a vendor's development or build environment and insert malicious code into legitimate software, which is then signed and distributed through normal channels. The SolarWinds Orion compromise, disclosed in December 2020, is the best-known example: a backdoor was delivered through signed software updates to thousands of customers, including government agencies.
Compromised development tools
Tools used by developers can be abused to steal secrets from build environments. In 2021, a modified script in the Codecov tool exposed credentials in customers' continuous integration environments.
Trojanized applications
In 2023, a trojanized version of the 3CX desktop application reached customers through the vendor's own distribution. Investigations linked the initial compromise to another, earlier supply chain compromise of software used by a 3CX employee, a chain of supply chain attacks.
Malicious or hijacked open-source packages
Attackers publish malicious packages with names similar to popular ones (typosquatting), take over abandoned packages, or compromise maintainer accounts. Developers who install them unknowingly bring malicious code into their applications.
Long-term social engineering of maintainers
In 2024, a backdoor was discovered in XZ Utils, a compression library included in many Linux distributions. The attacker had spent years building trust as a contributor before inserting the backdoor. It was caught by a developer who noticed a small performance anomaly, before it reached most stable releases.
Defenses for software builders
- Protect build systems as critical infrastructure: isolated environments, strong access control, multifactor authentication and monitoring.
- Verify dependencies: use trusted registries, pin versions, check integrity hashes, and scan for known vulnerabilities and malicious packages.
- Sign artifacts and verify signatures throughout the pipeline, so tampering is detectable.
- Generate SBOMs that record the components in each release.
- Follow secure development frameworks, such as the NIST Secure Software Development Framework (SSDF), and supply chain integrity frameworks such as SLSA.
- Review code carefully, including changes from trusted contributors and to build scripts.
Defenses for software buyers
- Assess suppliers: ask about secure development practices, build system protection, vulnerability disclosure and incident history. Federal agencies now ask many software producers to attest to secure development practices.
- Request SBOMs to understand what components you are running.
- Limit trust: run third-party software with the least privilege it needs, and segment systems that run it.
- Monitor behavior: unexpected network connections or processes from trusted software can be a sign of compromise.
- Plan for vendor compromise: know how you would identify affected systems and respond if a supplier announced a breach.
The special case of defense programs
For defense systems, supply chain risk extends to hardware, firmware and the development environments of contractors. Program protection planning, supply chain risk management and software assurance requirements address these risks, and contractors should expect scrutiny of their own suppliers.
Frequently asked questions
Does code signing protect us? Signing proves who produced software and that it was not altered after signing. It does not prove the software is safe if the attacker compromised the build process before signing, as SolarWinds showed.
Are open-source components riskier than commercial software? Not inherently. Both can be compromised. The difference is visibility: with open source, you can inspect and track components, provided you know which ones you use.
What is an SBOM, and is it enough? A software bill of materials lists the components in a piece of software. It does not stop attacks, but it lets organizations quickly determine whether they are affected when a component is found to be vulnerable or malicious.
What to do this week
- Identify your most privileged third-party software, such as management agents and security tools, and what it can reach.
- Ask your top software suppliers for their secure development attestation and an SBOM.
- For software you build, confirm who can change build pipelines and that changes are reviewed.
- Enable dependency scanning in your repositories and review open alerts.
- Check whether any code repositories contain secrets, and rotate what you find.
How CDT can help
CDT's source code analysis and secure development services review code and pipelines for weaknesses, our DevSecOps team secures build and deployment systems, and our vulnerability research team analyzes software and firmware for hidden threats.
