Hardening the Pipeline: Container Security Beyond Zero Trust
- Travis Knoche
- 37 minutes ago
- 5 min read
Modern security has to verify the software ingredients flowing through the build process
In my last post, I argued that Zero Trust architectures often miss the developer-facing package manager entirely. You can verify identity, harden devices and segment networks, but none of that stops a malicious PyPI package from running on an analyst's machine. The responses I got made something clear: package managers are just one piece of a larger supply chain problem. Container base images and CI/CD pipelines carry similar risks and receive similarly little scrutiny.
The Base Image Problem
Every container image inherits the vulnerabilities of the images it builds on. That FROM python:3.12 line in your Dockerfile pulls in an operating system, system libraries, a package manager and hundreds of packages you never really asked for. Research from NetRise found that the average container image had 604 known vulnerabilities in its underlying software components, with over 45% being 2 to 10-plus years old.
Here's what this looks like in practice:
# Standard approach: inherits 600+ vulnerabilities
FROM python:3.12
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]
A hardened approach changes the starting point. The point is not just swapping one image name for another. The point is starting from a smaller, actively maintained base image and pinning what you deploy so the build can be verified and reproduced later.
# Hardened approach: 97% fewer vulnerabilities
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]
A recent analysis by Wiz explains why this matters at fleet scale. A single vulnerable base image can propagate across many services, and security teams need to identify which vulnerabilities were introduced at the base layer and where those images are running. Most organizations scan their final images for vulnerabilities, but the scanner just tells you what's wrong. It doesn't always give you a clean path to fix it when the vulnerabilities live in upstream packages you don't control.
Your Zero Trust gateway validates the developer's identity, but the vulnerable or malicious code in the base image still runs.
The pattern here mirrors what happens with package managers. You trust a well-known source (Docker Hub, PyPI, CRAN), pull code into your environment, and assume someone upstream is handling security. But Docker Hub doesn't guarantee CVE-free images. Neither does PyPI. The supply chain is your responsibility, even when you didn't write the code.
Chainguard's Approach
Chainguard is one example of a broader shift in how teams are trying to handle this problem. Their container images are built on Wolfi, a minimal Linux distribution designed for secure, update-friendly container environments. The images are distroless where possible, meaning no shell, no package manager, nothing beyond the application and its runtime dependencies. According to Chainguard's public materials, their images show roughly 97% fewer vulnerabilities than typical alternatives.
The approach has scaled significantly. Chainguard now reports over 500 million container build manifests delivered and has expanded their catalog to 2,000+ projects.
A key component is that Chainguard rebuilds images from source whenever upstream changes. Their Factory 2.0 system automates over 10,000 open source project rebuilds daily. When a CVE is published, patches flow into images within hours rather than weeks. Every image ships with a signed SBOM (software bill of materials) generated at build time, plus SLSA Build Level 2 provenance attestations through Sigstore. You can verify what went into the image and that it hasn't been tampered with since.
For teams running containerized data science infrastructure, this solves a real operational problem. A Shiny app, Python API, scheduled model job or internal analytics service may look like normal data work, but it still depends on a base image, package registry and build workflow. If those pieces are pulling from public sources without pinning or provenance, the risk is part of the deployment path.
Hardened images do not remove the need for scanning, patching or review. They do reduce the amount of inherited risk that developers have to carry around before they even get to their own application code.
CI/CD as Another Attack Surface
Container images are only part of the story. Your CI/CD pipeline is also a supply chain, and attackers have noticed.
The threat landscape has evolved rapidly. In March 2025, the tj-actions/changed-files GitHub Action was compromised in an attack that impacted over 23,000 repositories. Attackers modified version tags to reference malicious code that dumped CI runner memory and exposed secrets like API keys, GitHub tokens and private keys in workflow logs.
But that was just one example. In September 2025, the Shai-Hulud worm compromised the npm ecosystem through a self-propagating malware variant that spread by stealing credentials and automatically publishing malicious package versions. CERT/CC reported that more than 500 packages were affected, and CISA released an advisory on the compromise. A second wave followed in November 2025, with Unit 42 reporting more than 25,000 malicious repositories across about 350 unique users.
The statistics are sobering: supply chain attacks nearly doubled from 154 incidents in 2024 to 297 in 2025, with projected costs of $60 billion globally.
The pattern is consistent. Attackers target CI/CD automation because that's where secrets live and where code gets built and deployed. A compromised action can exfiltrate credentials, inject malicious code into builds or pivot to other repositories.
This is what makes CI/CD different from ordinary application code. The pipeline often has permissions the application itself does not have. It can read secrets, publish artifacts, push images, update infrastructure and deploy to production. If you trust everything the pipeline pulls in by default, you have created a very powerful execution path with very little scrutiny.
Connecting the Pieces
Package managers, container images and CI/CD pipelines are all software supply chains. Each pulls external code into your environment. Each operates with implicit trust that rarely gets validated. Zero Trust addresses network and identity, but it doesn't touch the code flowing through these channels.
This gap is widening as attackers shift tactics. Instead of trying to break out of containers, they can compromise the containers before they're built. Instead of attacking CI/CD infrastructure, they can poison the actions and dependencies that infrastructure consumes. Zero Trust assumes the perimeter is gone, but it often rebuilds that perimeter around users and devices, not around code.
The remediation pattern is similar across all three: use a trusted source (governed mirrors, hardened images, pinned dependencies), verify provenance (SBOMs, signatures, attestations) and maintain reproducibility (lockfiles, frozen snapshots, commit SHAs). The tools exist. Posit Package Manager for R and Python packages. Chainguard or Docker's hardened images for containers. SHA pinning and artifact verification for GitHub Actions. What's often missing is the organizational will to adopt them.
The business case is getting easier to make. Gartner’s latest software supply chain security research points in the same direction: by 2028, 80% of organizations worldwide are expected to have experienced attacks on their software supply chains, a 48% increase from 2024. IBM’s 2025 Cost of a Data Breach report puts the global average cost of a data breach at $4.4 million. You do not need to treat those numbers as perfect forecasts to see the direction of travel. The pipeline is now part of the risk conversation.
Start by inventorying what's actually flowing through your pipelines. Which base images do you use? Where do they come from? Which GitHub Actions run in your workflows, and are they pinned? Which dependencies are pulled from public registries? Which artifacts are signed? Which builds can you reproduce?
The answers might reveal supply chain exposure that Zero Trust was never designed to address.
Travis Knoche
Senior Data Scientist
Lander Analytics
Subscribe to our Substack and below to our monthly emails for practical AI strategies for your organization: what to build, what to avoid, and how to make systems reliable in the real world.
Work with us: If you want help identifying the right first workflow, building a permissioned knowledge base, or training your team to ship responsibly, reach out at info@landeranalytics.com.
About the author: Travis Knoche is a Senior Data Scientist at Lander Analytics, where he designs, deploys, and maintains data science infrastructure in a wide variety of environments and constraints, and bridges the gap between backend infrastructure and frontend data science development work.
