In 2024, the average enterprise attack surface spanned over 165 internet-facing assets per domain, and 30% of them were unknown to security teams before discovery scans ran, according to attack surface management research cited across the industry. Software supply chains have made this problem worse: a single Python microservice can pull in 200+ transitive dependencies, each one a potential entry point. Chainguard has built a business around one slice of this problem — minimal, hardened base images that strip out shells, package managers, and CVEs by default. That's a real contribution to attack surface reduction, but base images are one layer in a much taller stack that includes build pipelines, SBOMs, runtime configuration, identity, and third-party CI actions.
This post breaks down what attack surface reduction actually means in a software supply chain context, walks through concrete strategies teams are using in 2025 and 2026, and shows where a distroless image stops mattering if the pipeline that produced it is compromised.
What Counts as Your Software Supply Chain Attack Surface?
Your software supply chain attack surface is every component, credential, and process an attacker could exploit between source code and running production workload — not just the container image. That includes your Git provider and its OAuth app permissions, CI/CD runners and their secrets, package registries (npm, PyPI, Maven Central), build caches, third-party GitHub Actions, base images, and the artifact signing and provenance chain. The 2021 Codecov breach is the canonical example: attackers modified a bash uploader script hosted outside the main repo, and it silently exfiltrated CI secrets from thousands of customer pipelines for two months before detection. No base image would have stopped that. Similarly, the 2024 XZ Utils backdoor (CVE-2024-3094) was inserted through a multi-year social engineering campaign against a maintainer, hidden in build scripts and test artifacts rather than in application code that a hardened runtime image would even touch. Reducing attack surface means treating the entire path from commit to deploy as in-scope, not just the final container.
Why Do Minimal Base Images Only Solve Part of the Problem?
Minimal base images reduce runtime attack surface but do nothing for the build-time and pipeline attack surface where most real-world supply chain compromises originate. Chainguard's distroless and "Wolfi"-based images are genuinely good at what they target: a typical Chainguard Python image reports zero known CVEs at publish time versus dozens on a standard Debian-based equivalent, because there's no shell, no package manager, and a far smaller set of installed libraries for a scanner to flag. That matters for runtime exploitation — an attacker who gets code execution in a container with no bash, curl, or apt has fewer built-in tools to pivot with. But Sonatype's 2024 State of the Software Supply Chain report found malicious package uploads to open source registries grew from roughly 245,000 in 2023 to over 512,847 in 2024 — a 156% year-over-year increase — and those packages get pulled in during pip install or npm install regardless of how minimal the eventual base image is. A hardened image built from a poisoned dependency is still a compromised image. Base image hardening is necessary but addresses maybe one link in a chain of eight or nine.
How Much Does Dependency Sprawl Actually Increase Risk?
Dependency sprawl increases risk roughly in proportion to the number of maintainers and update paths you're implicitly trusting, and for most organizations that number is in the thousands. A 2023 study of npm and PyPI ecosystems found that a median application with 100 direct dependencies pulls in over 900 transitive ones, each maintained independently, each capable of pushing an update that runs with your build or application's permissions. The event-stream incident in 2018 showed how this plays out: a popular npm package with 2 million weekly downloads was handed off to a new "maintainer" who added a malicious dependency four versions deep, targeting a specific cryptocurrency wallet application. It sat undetected for over two months. Attack surface reduction here means actively pruning: removing unused dependencies (studies suggest 60-80% of installed npm packages in a typical project are never actually called), pinning versions instead of using floating ranges, and generating SBOMs so you know, in minutes rather than weeks, whether a newly disclosed CVE like Log4Shell (CVE-2021-44228, disclosed December 2021) actually affects a build you shipped.
Do Signed Builds and Provenance Actually Stop Attacks, or Just Detect Them?
Signed builds and provenance attestations primarily enable fast, confident detection and blocking at deploy time — they don't prevent an initial compromise, but they shrink the window an attacker can operate in from months to minutes. The SolarWinds Orion attack in 2020 went undetected for an estimated 14 months because there was no cryptographic link between source commit, build environment, and shipped binary that anyone could verify. With SLSA (Supply-chain Levels for Software Artifacts) provenance and Sigstore-based signing now standard in projects like Kubernetes and reaching SLSA Build Level 3, a deployment pipeline can refuse to run an artifact unless its provenance matches an expected source repo, commit SHA, and builder identity. That doesn't stop someone from compromising a maintainer's laptop, but it does mean a tampered artifact fails a policy check at admission control rather than running silently in production for over a year. Enforcing signature and provenance verification at the Kubernetes admission controller or artifact registry level is one of the highest-leverage attack surface reduction strategies available today because it collapses detection time without requiring you to trust every upstream maintainer perfectly.
Which Attack Surface Reduction Strategies Give the Best Return for the Effort Involved?
The highest-return strategies are the ones that apply a control once at a chokepoint rather than requiring per-team discipline, and in practice that means SBOM generation, registry allowlisting, and admission-time policy enforcement outrank image hardening alone. Concretely, in order of typical implementation effort versus risk reduction:
- Generate and diff SBOMs on every build (low effort, high value) — turns "are we affected by CVE-2024-XXXX" from a multi-day fire drill into a query that returns in seconds.
- Enforce artifact signing and provenance verification at admission (medium effort, high value) — blocks unsigned or mismatched-provenance artifacts before they run, closing the gap that let SolarWinds run undetected for over a year.
- Allowlist registries and pin dependency versions (low effort, medium-high value) — directly counters the 512,847 malicious packages published to open registries in 2024.
- Adopt minimal/distroless base images (medium effort, medium value) — meaningfully reduces the runtime CVE count and shell-based pivot options, which is Chainguard's core offering.
- Continuously audit third-party CI actions and OAuth app scopes (low effort, medium value) — closes the Codecov-style blind spot where the compromise happens outside your own repo.
- Prune unused dependencies quarterly (medium effort, medium value) — shrinks the population of packages that could be silently taken over, given that most projects use only 20-40% of what they install.
Teams that only do #4 have hardened one node in the graph while leaving the other five open.
How Safeguard Helps
Safeguard is built around the premise that attack surface reduction has to cover the full path from source to running workload, not just the container that ends up in production. Where Chainguard's value proposition centers on shipping you a smaller, cleaner base image, Safeguard focuses on giving you visibility and enforcement across the build pipeline itself: continuous SBOM generation and diffing so a newly disclosed CVE is a lookup, not an investigation; provenance and signature verification enforced at deploy time so unsigned or tampered artifacts never reach production, regardless of which base image they were built on; dependency and registry monitoring that flags anomalous package behavior before it reaches a build; and audit trails across CI/CD, third-party Actions, and OAuth app permissions so a Codecov-style compromise outside your own repository doesn't stay invisible for months.
In practice, this means teams using Safeguard get a unified view of their software supply chain attack surface — dependencies, build infrastructure, signing keys, and runtime artifacts together — rather than having to stitch together a minimal-image strategy with a separate SBOM tool and a separate CI security product. Attack surface reduction works best as a system property, not a single hardened layer, and that's the problem Safeguard is built to solve.