Why Software Supply Chain Security Matters
After reading this guide
In September 2025, CISA warned that a self-replicating worm called Shai-Hulud had compromised more than 500 npm packages. The malware searched the systems it landed on for credentials, including GitHub personal access tokens and AWS, Google Cloud, and Azure API keys, then used stolen access to publish compromised versions of more packages. The teams that pulled it in didn’t write the malicious code, and many never chose the infected package directly.
Software supply chain security protects the components, tools, and pipeline steps that turn source code into running software, so a compromise upstream doesn’t reach your production systems. This article shows where risk enters each stage of a containerized supply chain, why it matters now, and what you can do at each stage.
Why software supply chain security matters now
Most of your application is code your team didn’t write. The Linux Foundation estimates that free and open-source software makes up 70–90% of any given modern software solution. The Census III report from Harvard and the Linux Foundation’s OpenSSF cites an estimate that up to 96% of codebases include open source.
Each direct dependency brings its own transitive dependencies, maintainers, and release schedules. For a rough count of what your own Node.js project resolves, run:
npm ls --all | wc -lThat code runs with the same privileges as the code you wrote, and your team reviews little of it. Attackers target this gap directly. In March 2026, attackers published two versions of axios, a widely used JavaScript HTTP client, that pulled in a malicious dependency and delivered a remote access trojan.
Regulators and customers now ask for evidence that you manage this risk. For a CISO, supply chain controls decide whether you can sell to regulated buyers. For a VP of Engineering, each unvetted component adds scanner findings that engineers triage instead of shipping features.
How a software supply chain works, stage by stage
A software supply chain has the same structure as a physical one. Upstream, an automaker sources engines, electronics, and brakes from Tier 1 suppliers, who rely on Tier 2 and Tier 3 suppliers for smaller parts. Midstream, the factory assembles and inspects the vehicle. Downstream, dealers sell it and service centers maintain it for years.
The manufacturer tracks each part in a bill of materials, because one defective part from deep in the chain can force a recall of every vehicle that uses it.
Software follows the same pattern, with a digital equivalent for each stage.
Your raw materials are open-source libraries, operating system packages, and container base images. Most of your code, and most of your inherited risk, starts here.
Your engineers write the proprietary code that ties dependencies together. A CI/CD system builds it, pulls in third-party actions and tools, and assembles container images, with testing and scanning as quality control.
Images go to a registry and then to production. New CVEs are disclosed against components that were clean when you shipped them, which restarts the cycle.
The software equivalent of the automaker’s bill of materials is the software bill of materials (SBOM). The difference is visibility: an automaker inspects its Tier 1 parts, while most engineering teams never review the transitive dependencies inside their images.
Where attacks and vulnerabilities enter the chain
Each stage fails in its own way, and a control at one stage doesn’t cover the others.
Upstream risks include malicious packages published through hijacked maintainer accounts or typosquatted names, packages added on an AI coding assistant’s suggestion that no one on the team evaluated, and images on public registries that impersonate popular software. Legitimate public base images carry their own risk: they ship with known CVEs before you add a line of code.
Midstream risks include compromised CI/CD components, such as a poisoned GitHub Action, GitLab CI or build tool, and credentials exposed to build steps that run untrusted install scripts. Shai-Hulud spread this way: it harvested credentials from the environments where it was installed and used them to publish compromised versions of more packages.
Downstream risks include image drift, where a deployed image accumulates newly disclosed CVEs, and unused packages and binaries that ship in production images and widen the attack surface without serving the application.
Security engineers feel the downstream problem as alert volume. A signature-based scanner flags CVEs in installed packages whether or not the vulnerable code ever loads, so the backlog grows faster than a team can triage it.
How RapidFort secures each stage of the container supply chain
Upstream: start from near-zero CVE images and screened libraries
RapidFort Curated Images is a catalog of tens of thousands of near-zero CVE container images built on Ubuntu, Debian, Red Hat, and Alpine LTS releases, so you can stay on the distribution you already use. RapidFort engineers rebuild and patch the images every 24 hours, and the catalog includes CIS- and STIG-benchmarked variants and FIPS 140-3 validated images.
The images are pin-for-pin compatible with their upstream equivalents, so adoption is a one-line change in your Dockerfile:
# Before
FROM nginx:1.27
# After
FROM [INSERT verified RapidFort registry path]/nginx:[TAG]Curated Libraries applies the same model to application dependencies. It provides malware-scanned open-source packages for npm, PyPI, Maven, RubyGems, and NuGet, so packages are screened before they reach your build.
Midstream: inventory every component in the build
The RapidFort Analyzer scans images across your CI/CD pipelines and registries, tracks CVE drift over time, and generates SBOMs. You get an inventory of the transitive dependencies your team never reviewed directly, in a form you can hand to auditors and customers.
Downstream: eliminate what doesn’t run
Runtime profiling records which packages and files load in production, across environments such as EKS, AKS, and OpenShift. The Optimizer then removes the components that never execute, which reduces the software attack surface by up to 90%. Combined with Curated Images, this eliminates up to 99.9% of CVEs without code changes. Read how runtime profiling prioritizes the CVEs that matter.
How to start securing your container supply chain
Start with the components you inherit, since that’s where most of your code comes from. First, scan the base images behind your production services and generate an SBOM for each one. Next, swap the images with the highest CVE counts for their curated equivalents and rescan to confirm the change. Then point your package managers at Curated Libraries so new dependencies are screened before they reach a build.
Your path to near-zero CVE images
Our guide covers when to build from scratch versus starting from curated images, and how to keep images at near-zero CVEs as new vulnerabilities are disclosed.
