Software Supply Chain Security: Why 99% of Your Container is Mystery Code
During a recent presentation for Cloud Native London, I asked the audience a simple question: “How many lines of code do you think I wrote for an application that came back with 1,004 vulnerabilities?”
The guesses ranged from 50 to five. The real answer? One line.
FROM node:latest
That single line pulled in 19,000 files, 700 binaries, and a complete Linux operating system. The actual business logic in a typical container represents 1% of what ends up in production. The other 99%? Mystery meat.
And guess how many lines it took me to fix all these problems? Yes, you might have guessed it right. One line.
The truth is, your code usually isn’t the source of your Software Supply Chain Security problems. Let’s take a look at how to take back control of your code, without any mystery in it.
The Developer vs. Platform Engineer Problem
The software supply chain is a living process involving different teams at various stages, calling for not only communication but also trust in the content one team (Developer) provides to the other (Platform).
And here’s what I notice in many conversations about container security: We’ve created an antagonistic relationship between developers and platform engineers that doesn’t need to exist.
The developer perspective: “I need to ship features in two-week sprints. My backlog is full. The business depends on the value I deliver. That base image? It’s just packaging. It’s the box around the pizza. I care about the pizza.”
The platform engineer perspective: “That box contains a whole operating system. There are compilers in there. Shells. Unknown binaries. Attack vectors I can’t even count. And when something breaks at 2 AM, I’m the one who gets blamed.”
Both are right. And that’s the challenge.
You can’t scan yourself to safety. Adding a vulnerability scanner at the end of your pipeline only highlights the problem. By the time the developer has spent two weeks patching 500 vulnerabilities, a new set has appeared. Next to that, the image itself is a moving target. Pull node:latest this week, get a different container than last week.
The Anatomy of Trust
So how do you break this cycle? You need three things working together:
- Provenance: Who built this? Where was it built? Which tools were used? Which commit SHA?
- Attestation: Who signed off on this? Who audited it and added their signature to prevent tampering?
- Introspection: What’s actually in there? The full Software Bill of Materials (SBOM).
These three concepts form what’s called SLSA (Supply Chain Levels for Software Artifacts). Get to SLSA level three and you’ve got cryptographic proof that your image was built from a specific commit, contains known code, and hasn’t been tampered with.
But here’s the thing: you need all three.
I could give you a full SBOM (Software Bill of Materials), but without attestation, can you trust it? Someone could have removed packages you didn’t want to see.
I could sign off on the most secure build process, but if I don’t tell you what’s in there, you’ve still got mystery meat. You just know it came from me.
Why “Do It Yourself” Doesn’t Work
At this point, you might be thinking: “Right, I’ll go back to the office and build all of this.”
Of course you can, but beyond having the know-how to put all the steps together, do you have the time to not only create the entire solution, but also maintain and support it when issues inevitably arise?
It’s not just about that base container image. You need to build the Linux libraries underneath. The kernel. The entire dependency chain. You need a continuous rebuild pipeline that scans for upstream updates, isolates builds so they don’t influence each other, and outputs signed artifacts.
Who will patch glibc when a vulnerability appears? Who maintains that pipeline?
You want to run the kitchen. You don’t want to manage the farm.
Establishing a secure software supply chain is no longer about blind trust; it is about attestation. Security-conscious organizations are increasingly moving toward container environments that prioritize transparency through SLSA Level 3 compliance—ensuring that every layer, from the OS to the runtime (like Node or Python), includes verifiable provenance and a comprehensive Software Bill of Materials (SBOM).
When these foundations are built on open-source principles and made freely accessible, it elevates the security posture of the entire ecosystem.
Trust Beyond the Container
Modern applications don’t live in isolation. That application you delivered depends on a Helm chart that installs Redis:latest, Postgres or cert-manager for instance. Dependencies you won’t build or own.
True supply chain integrity requires treating external dependencies with the same rigor as internal code, meaning taking open source applications and securing them at the source, and rebuilding them to meet SLSA Level 3 Standards.
Securing the Platform, Not Just the App
Now let’s say you go back to your team next week. You start building safe applications. You know what trust looks like.
What prevents your colleague who wasn’t at that talk from shipping unsafe code into production?
You need a gatekeeper. Someone who says: “Sorry, you can’t serve mystery meat in this restaurant.”
That’s where Kubewarden comes in. It’s an open-source admission controller that acts as a universal policy engine. Write any policy you want. Block non-signed images. Mutate deployments. It’s CRD-based, easy to extend, and you can write policies in any WebAssembly-compiled language.
[Admonition]
Did you know: KubeWarden is an open source CNCF sandbox project, built and maintained by SUSE and it forms the base for SUSE Security Admission Controller making it 100% compatible
[/Admonition]
Using KubeWarden, it becomes easy to ensure that your production cluster stays safe no matter what a developer tries. Watch the talk to see me demo how KubeWarden ensures that you cannot deploy an nginx:latest container from Docker Hub, but it does allow deployment from a trusted source.
The Only Secret Ingredient is Trust
Here’s what I want you to take away from this:
Trust is not a scan. It’s a process. A continuous one.
It starts with a secure base (SLSA compliance, provenance, attestation, SBOM). You use trusted ingredients for your dependencies. You secure your platform with admission control.
You can’t patch your way out of this problem. You can’t audit 19,000 files per deployment and still ship features every two weeks. You need to change the ingredients, not inspect the finished dish.
The developer gets to focus on business logic. The platform engineer sleeps at night. The antagonistic relationship disappears because you’ve removed the source of tension.
This is key, and the value for the overall company is the increased speed to market, allowing ideas (from Developers) to flow to production deployments (by Platform Engineers) in a fine-tuned, high-speed process.
That’s what supply chain security actually means. Not another checklist. Not another scanner at the end of the pipeline. A fundamental shift in how you think about what goes into production.
And if you want to see me explain all of this with actual meat metaphors, the full talk from Cloud Native London is worth watching. When it comes to the ingredients we put into our containers, you can rest assured they’re fresh and you know where they came from.
Starting in Trusted Mode
So after all the theory, I promised you that the fix was also just one line:
FROM dp.apps.rancher.io/containers/nodejs:24.13.0T
Congratulations, you just went from 1,004 CVE to 0 CVE! Same code, and still a world’s difference for your Secure Supply Chain.
Resources
Want to learn more? Check out SUSE Base Container Images and SUSE Application Collection. Both are open source and available now. Please stop by booth #710 at KubeCon to learn more.
- Kubewarden [Docs]
- SUSE Security Admission Controller [Docs]
- SUSE Application Collection [Docs]
- SUSE Base Container Images [Docs]
- SUSE Rancher Prime [Docs]
