The software supply chain is not an abstraction. It's the specific set of packages your application depends on, the maintainers who control those packages, the package registries that distribute them, and the build systems that install them into your deployments. Every one of those is a potential entry point for an attacker who wants to introduce malicious or vulnerable code into your software without directly compromising your systems.
Understanding how attackers think about your dependency graph is prerequisite knowledge for building a defense that actually matches the threat model.
Three attack categories in the dependency graph
Supply chain attacks against software dependencies fall into three broad categories, each requiring different defensive responses.
Known vulnerability exploitation: A CVE exists for a package in your dependency tree. An attacker scans your public-facing application (or your GitHub repo's lockfile, if it's public) to identify which vulnerable packages you're using, then crafts an attack targeting the specific vulnerability. This is the category that SCA tooling was originally designed for — track known CVEs, patch before exploitation.
Package compromise: An attacker gains control of a package maintainer's registry account (through credential theft, social engineering, or takeover of an abandoned package) and publishes a malicious version. Your next dependency update pulls in the malicious version. The installed code looks like the package you expected — it has the right name, version increment, and API surface — but contains exfiltration code, backdoors, or cryptomining payloads. The 2021 ua-parser-js compromise demonstrated this pattern at scale.
Dependency confusion: Attackers publish packages to public registries with the same name as your internal/private packages, relying on misconfigured package resolution to pull the public (malicious) version instead of your private one. This attack works specifically when package managers check public registries before private ones, or when scope disambiguation is misconfigured.
The lockfile as your attack surface map
Your lockfile — package-lock.json, yarn.lock, Pipfile.lock, go.sum, Cargo.lock — is the most detailed map of your supply chain attack surface that exists. It lists every package version that will be installed, including the full transitive closure of dependencies at pinned versions.
For known vulnerability exploitation, the lockfile is the primary data source: cross-reference every locked version against advisory databases. This is table-stakes SCA.
For package compromise, the lockfile's integrity field becomes critical. package-lock.json records the integrity hash (SHA-512 of the package tarball contents) for every installed package. If an attacker compromises a package account and publishes a new version with the same version number but different contents, the integrity hash changes. A strict integrity check at install time catches this. The defense is ensuring your CI/CD installs with npm ci (not npm install) or equivalent lockfile-strict commands that verify integrity hashes before installing.
For dependency confusion, the defense is explicit scoping and registry configuration: ensuring all internal packages are scoped (e.g., @yourcompany/package-name) and that your package manager configuration explicitly routes scoped packages to your private registry before checking public registries.
Attack surface that your lockfile doesn't capture
The lockfile tracks application-layer dependencies, but your full supply chain attack surface extends further:
Build toolchain: The tools that build your application — compilers, bundlers, test runners, code generators — are also supply chain components. A compromised Webpack plugin or a malicious Babel transform could modify your build output without touching your application source code. Build tool dependencies deserve the same SCA attention as application dependencies, but they're often in separate package.json devDependencies sections that get lighter scrutiny.
Container base images: If your application runs in a Docker container, the OS packages in your base image are supply chain components. A FROM ubuntu:22.04 layer includes hundreds of OS-level packages that have their own CVE history. Container image scanning is a distinct layer from application dependency SCA — different tooling, different package format (APT/RPM vs npm/pip), same conceptual threat model.
CI/CD infrastructure: Your build pipeline itself is a supply chain component. The GitHub Actions workflows that run your tests and deploy your application reference actions by version (uses: actions/checkout@v4). If a widely-used Action is compromised, every pipeline using it is affected. The 2025 tj-actions incident demonstrated exactly this pattern — a compromised CI action that exfiltrated secrets from build environments.
Attacker reconnaissance on public repos
If your repository is public, your lockfile is public. Automated scanners routinely crawl GitHub and other public code hosting for lockfiles containing known-vulnerable packages. This is essentially free reconnaissance for attackers: identify which popular repositories are running specific vulnerable versions of high-value targets (authentication libraries, cryptography packages, file parsing utilities), then craft targeted attacks against those applications.
For private repositories, lockfile exposure is narrower but not zero: job listings that describe your tech stack, conference talks where engineers mention specific library choices, npm package publications that reveal internal dependency patterns — all of these leak supply chain information that sophisticated attackers can leverage.
We're not saying this threat model should drive paranoia-level operational security in most development organizations. We're saying it should inform how you think about the urgency of CVEs in high-value package categories — authentication, cryptography, deserialization, network request handling — relative to CVEs in low-profile utility packages.
Transitive dependencies as the high-leverage attack surface
From an attacker's perspective, transitive dependencies are often more attractive targets than direct dependencies. Direct dependencies of popular frameworks and libraries receive significant security scrutiny — they're well-known, heavily downloaded, and actively monitored by security researchers. Transitive dependencies at depth 3-5 in the tree are frequently low-profile utility packages that receive far less external scrutiny.
The relative popularity of these transitive packages also matters for supply chain attack economics. A malicious actor who compromises a package installed by 10,000 projects reaches a much larger blast radius than one who compromises a package installed by 100 projects. But a package at depth 3 in popular frameworks may have 50,000 downstream dependents who've never consciously chosen to install it.
The defensive implication: reachability analysis for dependency vulnerabilities matters even more for deep transitive packages, because the vulnerability may be present in code that's very far from your application's conscious choices and very close to infrastructure-level functionality (HTTP parsing, certificate validation, query building) where exploitation has high impact.
What SBOM generation means for supply chain visibility
An SBOM (Software Bill of Materials) is the formal mechanism for capturing your supply chain attack surface in a structured, auditable format. Standards like SPDX and CycloneDX define machine-readable SBOM formats that can be consumed by vulnerability databases, compliance systems, and automated monitoring infrastructure.
The value of a continuously-maintained SBOM goes beyond compliance. When a new CVE drops against a package — as happens regularly — an up-to-date SBOM allows immediate cross-reference against your production inventory. Organizations with current SBOMs answered "are we affected by CVE-2021-44228?" in hours; organizations without them spent days manually inventorying their Java services.
Supply chain defense in depth requires knowing what you have, monitoring what you have for known vulnerabilities, analyzing which vulnerabilities are reachable in your running applications, and having a response plan for each category. Lockfile integrity checking, reachability-aware SCA, and continuous SBOM generation are the three layers of that defense. Each addresses a different attack category; none is complete without the others.
