The Invisible Attack Surface: Transitive Dependencies and the Supply Chain Vulnerabilities Container Scanners Cannot Reach

The container security workflow that most organizations have settled on follows a recognizable pattern. A developer commits code. A CI pipeline builds an image. A scanner evaluates that image against a database of known vulnerabilities. If the scan passes, the image advances toward production. If it does not, the pipeline halts and a developer addresses the flagged package.

This workflow is not without value. It catches real vulnerabilities. It creates accountability checkpoints. It produces audit artifacts that satisfy compliance requirements. But it encodes a fundamentally incomplete security model—one that treats the first layer of a dependency graph as if it were the whole graph, and conflates the absence of known CVEs with the absence of exploitable risk.

The attack surface that modern supply chain adversaries are actively exploiting lives deeper than any scanner is looking.

What Scanners Actually Examine

To understand the gap, it is necessary to be precise about what container image scanning does. Most commercial and open-source scanners—Trivy, Snyk, Grype, Anchore, and their peers—operate by inventorying the packages present in an image and comparing those packages against vulnerability databases such as the National Vulnerability Database (NVD), vendor-specific advisories, and curated community feeds.

This process is effective at identifying direct dependencies with documented CVEs. It is largely ineffective at three categories of risk that are increasingly central to supply chain attack campaigns:

Transitive dependencies without published CVEs. A package your application directly imports may itself import a package that imports another package. The vulnerability may exist in that third or fourth tier dependency—perhaps as a logic flaw, a malicious code injection, or a typosquatted package that was substituted somewhere in the chain. If no CVE has been published against it, no scanner will flag it.

Dependency confusion and substitution attacks. These attacks do not exploit known vulnerabilities. They exploit the resolution logic of package managers. By publishing a malicious package to a public registry with the same name as a private internal package—but a higher version number—an attacker can cause the package manager to prefer the malicious public package during build. The scanner examines the resulting image and finds no CVEs, because the malicious package has none.

Post-scan runtime mutations. Container scanners evaluate images at a point in time. They cannot account for dependencies that are fetched, executed, or modified at runtime—scripts that pull external resources during initialization, plugins that are downloaded on first start, or update mechanisms that replace signed binaries with unsigned ones after the image has passed its security gate.

The Depth Problem in Modern Dependency Graphs

The scale of transitive exposure in contemporary software is not a theoretical concern. A typical Node.js application may have 30 to 50 direct dependencies. The transitive dependency graph for those same packages can exceed 1,000 unique packages. A Python data pipeline may import a handful of libraries; its full dependency tree can include hundreds of packages from dozens of maintainers, many of whom are individual contributors with no organizational security posture to speak of.

Each node in that graph represents a potential injection point. Each maintainer account represents a credential that, if compromised, allows an attacker to publish a malicious update to a package that your build system will fetch and incorporate without additional review.

The 2021 compromise of the [ua-parser-js](https://en.wikipedia.org/wiki/Google_Search) npm package illustrates this dynamic precisely. The package had tens of millions of weekly downloads. It was not a direct dependency for most of those downloads—it was a transitive dependency, pulled in by other packages that developers had explicitly chosen. When the maintainer's account was compromised and a malicious version was published, the attack propagated through thousands of pipelines automatically, reaching production environments that had never explicitly chosen to depend on it.

No scanner flagged the malicious version in the window before it was identified and pulled. There was no CVE. The package passed every automated gate.

Runtime Exploitation of Scanner Blind Spots

The post-deployment phase introduces a different category of exposure. Container scanners evaluate static images. Running containers are dynamic environments, and the gap between the two is where sophisticated attackers have learned to operate.

Consider a containerized application that loads plugins from a configured external source at startup. The base image scans clean. The application code passes static analysis. But the plugin loading mechanism—perhaps a feature that predates modern supply chain awareness—fetches code from an endpoint that an attacker has compromised. The container starts, loads the malicious plugin, and establishes persistence. The scanner never had visibility into this execution path because it does not exist in the image layer.

Similarly, applications that use package managers at runtime—fetching dependencies during initialization rather than at build time—present a surface that image scanning cannot cover. The image contains a package manager and a requirements file. What gets installed when the container starts is determined at runtime, after the security gate has already been passed.

Building Visibility Beyond the First Layer

Addressing transitive supply chain risk requires expanding the security model beyond image scanning without abandoning it. Several complementary approaches provide meaningful coverage of the gaps:

Software Bill of Materials (SBOM) generation and analysis. Generating a full SBOM at build time—including transitive dependencies—and storing it alongside the image provides a complete inventory that can be queried against vulnerability intelligence as new CVEs are published, rather than only at the moment of the original scan. Tools such as Syft and CycloneDX support SBOM generation with transitive depth.

Dependency pinning with hash verification. Pinning dependencies to specific versions is table stakes; pinning them to specific content hashes eliminates the substitution attack vector. A package manager that verifies the SHA-256 hash of every downloaded package against a lockfile cannot be redirected to a malicious substitute, regardless of version number.

Private package mirrors with admission control. Routing all package fetches through an internal mirror that applies organizational policy before serving packages eliminates the public registry as a direct attack vector. Packages must be explicitly approved before they become available to build pipelines.

Runtime security monitoring with behavioral baselines. Tools such as Falco and similar eBPF-based runtime monitors can detect anomalous behavior—unexpected outbound connections, unusual file system writes, process executions that deviate from established baselines—that indicates post-deployment compromise regardless of whether the initial image scanned clean.

Provenance verification via SLSA frameworks. The Supply-chain Levels for Software Artifacts (SLSA) framework provides a structured approach to verifying that build artifacts were produced by expected processes from expected sources, reducing the opportunity for substitution at any point in the build chain.

Reframing the Security Perimeter

The container scanner is not the problem. The problem is the organizational tendency to treat it as a perimeter rather than a checkpoint. Passing a scan does not mean a container is secure; it means a container does not contain packages with documented CVEs at the moment the scan ran.

Supply chain adversaries are sophisticated enough to know where that definition ends. Building a security posture that matches their actual attack surface requires extending visibility into the full dependency graph, the runtime environment, and the build process itself—not just the image that results from it.