Software supply chain security is the practices, tools and controls protecting every component of building, testing, and deploying software. This includes open-source dependencies and build pipelines to container images and deployment artifacts.
The supply chain is every input that goes into a deployed application: open-source libraries, internal dependencies, build systems, CI/CD pipelines, container base images, and AI-generated code. Each input is a place where an attacker can insert malicious code or a vulnerability can hide. The code you did not write carries the most risk.
The scale explains the urgency. OWASP's 2025 Top 10 ranks software supply chain failures as the number three web application security risk, and 50% of surveyed security practitioners rank it as their top concern. Open-source package downloads exceed trillions per year across major ecosystems, and open-source software underpins 70 to 90% of modern applications (Linux Foundation Census II). A single compromised library can propagate through dependency trees to thousands of downstream projects.
Securing the supply chain comes down to three jobs:
- Know every component in your software
- Verify that no one has tampered with those components and that none carry known vulnerabilities or malicious code
- Enforce policy to block compromised packages before they cause harm
Software Bill of Materials (SBOMs) provide the visibility foundation. A software composition analysis (SCA) and malware scanning determine what an attacker can exploit. Policy gates control what reaches production.
Regulation is speeding up this shift. Executive Order 14028, PCI DSS 4.0, and the EU Cyber Resilience Act all mandate or encourage supply chain security controls and SBOM production.
Where the software supply chain breaks
Understanding where the software supply chain breaks begins with seeing how each series of inputs, processes, and artifacts running through it introduces risk.
Open source dependencies and transitive risk
Most teams point their scanning at direct dependencies: the packages they declared in a manifest file. Most of the risk lives somewhere else.
Every direct dependency pulls in its own dependencies, and those pull in more. An application with 50 direct dependencies can carry 500 or more transitive dependencies. This includes packages that developers did not choose, did not review, and in many cases did not know existed. According to research from Endor Labs, 95% of the vulnerabilities that affect applications exist in transitive dependencies. When a vulnerability surfaces in a nested transitive dependency, it reaches every project above it in the chain.
The XZ Utils backdoor in March 2024 showed the stakes. An attacker spent two years building trust as a maintainer of a compression library that ships across most Linux distributions. Then they inserted a backdoor that could enable remote code execution over SSH. A Microsoft engineer caught it after noticing a 500-millisecond latency increase, not through any scanning tool.
Scanning only direct dependencies misses most of the attack surface. Full transitive dependency mapping is the baseline for meaningful supply chain security.
Build systems, CI/CD, and artifacts
Build pipelines hold the keys to production: secrets, credentials, signing certificates, and deployment access. This makes them high-value targets. When attackers compromise the build, they compromise everything it produces.
The SolarWinds attack in 2020 remains the defining example. Attackers modified the Orion build process to inject the SUNBURST backdoor into a legitimate software update, then pushed it to about 18,000 customers, including US federal agencies. The malicious code shipped with a valid digital signature because the compromise lived inside the build system itself.
In March 2025, the tj-actions/changed-files GitHub Action compromise exposed CI/CD secrets across thousands of repositories. We exposed the blast radius of this supply chain attack after CISA issued an alert (CVE-2025-30066). The attack vector was straightforward: attackers compromised a GitHub Action used across thousands of workflows, and any workflow that referenced it without pinning to a specific commit hash exposed its secrets.
Unpinned third-party actions, hardcoded secrets in pipeline configurations, over-permissioned build service accounts, and insecure artifact storage are configuration gap weaknesses that show up across most CI/CD environments.
AI-generated code as a new supply-chain input
AI-generated code is now a supply chain input, whether security teams have accounted for it or not. It appears across commercial codebases, yet most security teams lack visibility into how AI shapes the code they ship.
The risks are concrete. Multiple studies have found that a meaningful share of AI-generated code introduces security weaknesses, from insecure defaults to vulnerable dependency choices. The supply chain risk runs past code quality.
Large language models hallucinate package names: they suggest dependencies that sound plausible but do not exist. Attackers watch for these hallucinations, register the suggested names, and fill them with malicious code. This is package hallucination, and it turns AI coding assistants into a supply chain attack vector.
The takeaway: AI-generated code and the dependencies it suggests need to flow through the same scanning pipeline as human-written code. Treating AI code as a separate category that skips existing controls opens a gap that attackers can use.
The main types of software supply chain attacks
Supply chain attacks take several forms, but they share one strategy: compromise something upstream so the malicious payload flows downstream to targets who trust it. For a deeper breakdown with named incidents, see Software supply chain attacks explained. For technique-level detail, see Dependency confusion, typosquatting, and package poisoning.
Dependency confusion. An attacker publishes a public package using the same name as a private internal package. When the build system resolves dependencies, it pulls the malicious public version instead of the internal one.
Typosquatting. Attackers publish packages with names a single character away from popular libraries, such as lodahs in place of lodash. A developer who mistypes a name or copies a wrong reference installs the malicious version. Package registries hold thousands of known typosquatting attempts at any given time.
Malicious maintainer takeover. An attacker gains commit access to a legitimate project that many teams rely on, often through social engineering, and inserts a backdoor. XZ Utils in 2024 is the defining case: two years of trust-building contributions before the payload went in.
Build-system compromise. Inject malicious code into the build process so every artifact it produces carries the taint. SolarWinds is the canonical case. An attacker owns the build environment, the output turns malicious, and the artifacts still carry legitimate signatures because the signing step sits downstream of the injection point.
CI/CD pipeline attacks. Exploit automation tools such as GitHub Actions, Jenkins, and GitLab CI to steal secrets, modify code, or inject malicious steps into the pipeline. The tj-actions compromise showed how one compromised action can cascade across thousands of repositories.
These categories are not mutually exclusive. A sophisticated campaign can pair social engineering for maintainer access with a build-system compromise to widen impact and stay hidden.
The Shai-Hulud npm worm, a self-propagating attack on a package registry, how effective this can be, spreading across 500 or more package versions without a human in the loop.
How to secure the software supply chain
No single software supply chain security tool secures the entire chain. The control stack needs visibility, analysis, and enforcement across several layers. Here is what matters, and where most organizations fall short.
Software composition analysis (SCA) with function-level reachability context. SCA tools scan dependencies against vulnerability databases, but the volume of results, thousands of alerts in a large codebase, makes raw SCA output hard to act on.
Reachability analysis adds the missing context: it determines whether the application calls the vulnerable function in its execution path. If the application does not run that code path, the vulnerability poses no practical risk. It is the difference between checking every door and checking the doors that sit unlocked.
This approach can cut actionable alerts by up to 95%, which separates a triage backlog from a workload a team can clear. Endor Labs applies full stack reachability across code, dependencies, and containers, mapping the complete call graph to find which findings an attacker can reach and exploit.
SBOM generation and management. A software bill of materials (SBOM) is a machine-readable inventory of every component in an application: libraries, versions, transitive dependencies, and licenses.
SBOMs provide the visibility layer that every other control depends on. Regulation is making them non-optional. Executive Order 14028 requires them for federal software suppliers.
PCI DSS 4.0 Requirement 6.3.2 mandates component inventories. The EU Cyber Resilience Act requires SBOM production for digital products sold in the EU.
Standard formats include SPDX and CycloneDX. An SBOM on its own does not secure your supply chain. It tells you what you need to secure.
Real-time malware detection and blcoking. Vulnerability scanning catches known CVEs. Malware detection catches code that is malicious by design: dependency confusion packages, typosquatted libraries, and compromised maintainer uploads.
Timing is the point. Software security supply chain solutions need to catch malicious packages before they enter the build pipeline - not after deployment. Endor Labs detects malicious packages before they reach the build by continously scanning every newly uploaded package to open source ecosystems like npm and PyPI, and then blocking malicious packages using a package firewall before they land on a developer's laptop or in CI.
AI-code governance. With AI-generated code landing in every codebase, organizations need to route AI-suggested dependencies and AI-written code through the same scanning pipeline as human-produced code. No separate toolchain, no exceptions. Endor Labs scans AI-suggested dependencies with the same reachability and malware analysis it applies to all other cod, and also governs AI coding agent behavior to block them from installing unsafe dependencies.
Software supply chain security checklist
A practical starting point for teams building or improving their posture:
- Inventory every dependency, direct and transitive, with an automated SBOM tool for observability.
- Scan for known vulnerabilities in every build, and use reachability analysis to prioritize what an attacker can exploit, not just what is present.
- Detect malicious packages before they enter the build pipeline. Vulnerability scanning on its own does not catch code that is malicious by design.
- Pin dependency versions and verify checksums. Unpinned dependencies open the door to dependency confusion and version substitution.
- Harden CI/CD pipelines. Pin third-party actions to specific commit hashes, rotate secrets on a schedule, and enforce least-privilege access for build service accounts.
- Require code review and commit signing for every change, human and automated alike.
- Monitor for maintainer changes in critical dependencies. A sudden shift in ownership or commit patterns can signal a takeover.
- Generate and maintain SBOMs in standard formats (SPDX, CycloneDX) to meet requirements under EO 14028, PCI DSS 4.0, and the EU Cyber Resilience Act.
- Scan AI-generated code through the same pipeline as human-written code. AI-suggested dependencies carry the same risks, plus package hallucination.
- Build an incident response plan for supply chain compromises. A compromised dependency touches every application that uses it, and response speed sets the blast radius.
- Enforce policy gates. Block builds that fail vulnerability, malware, or compliance checks. Manual review does not scale.
FAQ
What is a software supply chain attack? A software supply chain attack targets the components, tools, or processes used to build and deliver software rather than the application itself. Attackers compromise upstream elements such as open-source packages, build systems, or CI/CD pipelines to inject malicious code that flows to every downstream consumer. Recent examples include the SolarWinds build compromise (2020), the XZ Utils maintainer takeover (2024), and the tj-actions GitHub Action hijack (2025).
What is an SBOM and why does it matter? A software bill of materials (SBOM) is a machine-readable inventory of every component in an application, including open-source libraries, their versions, and their transitive dependencies. It matters because it provides the visibility teams need to identify vulnerabilities, track licenses, and respond to incidents. Regulations including Executive Order 14028, PCI DSS 4.0, and the EU Cyber Resilience Act now require or encourage SBOM production for software suppliers.
How is software supply chain security different from application security? Application security focuses on vulnerabilities in the code an organization writes. Software supply chain security widens that scope to everything the code depends on: open-source libraries, build tools, CI/CD infrastructure, container base images, and artifacts. If you build a secure application on a compromised dependency, you still compromise the application, and supply chain security closes that gap.
What regulations require software supply chain security controls? Key regulations include US Executive Order 14028 (federal software suppliers must secure their supply chains and provide SBOMs), the NIST Secure Software Development Framework (SSDF) SP 800-218 (secure development practices), PCI DSS 4.0 Requirement 6.3.2 (component inventory for payment software), the EU Cyber Resilience Act (SBOM and vulnerability management for digital products), and FDA cybersecurity guidance (medical device SBOMs). Australia's Information Security Manual (ISM-1730) also requires SBOM production.
How does reachability analysis reduce alert noise? Traditional software composition analysis flags every known vulnerability in every dependency, which generates thousands of alerts, most of which carry no real risk. There are different types of reachability analysis, but function-level reachability is typically considered the gold standard. Function-level reachability analysis checks whether the application calls the vulnerable function in its execution path regardless if the vulnerability is in direct or transitive dependencies. If the application does not run that code path, the vulnerability poses no practical risk in that context. This approach can reduce actionable alerts by up to 95%, which lets security and engineering teams focus on vulnerabilities that an attacker can exploit.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: