How do we secure massive, complex supply chains without slowing your developers down to a crawl? This talk provides a simple preview to Red Hat’s Trusted Software Supply Chain, based on three pillars: Transparency through the Trusted Profile Analyzer; Identity, thanks to the Trusted Artifact Signer; and Guardrails, with the Advanced Cluster Security for Kubernetes.
Talk presented at the 2026 Red Hat Summit Connect Switzerland event on January 14th, 2026.
Introduction
Welcome to this presentation titled “What’s in your Container? Securing the Supply Chain without Slowing Down”. This talk was first presented at the 2026 Red Hat Summit Connect Switzerland event in January 14th, 2026.
My name is Adrian Kosmaczewski, and I am a Senior Architect at Red Hat Switzerland.
The “Black Box” Problem
Let us talk about the “Black Box” problem.
Imagine, for a moment, that you walk into a grocery store to buy a frozen lasagna for your family dinner. You pick up the box from the freezer aisle. You toss it in your cart. You trust it. You assume the meat isn’t spoiled. You assume the factory where it was made followed strict health codes.
You assume that the list of ingredients printed on the back (flour, tomatoes, beef, etc.) is actually what is inside the box. You trust the supply chain implicitly because there are regulations and checks in place to keep you safe.
Now, let’s pivot and look at how we build software today.
Modern software development has fundamentally changed. We don’t really “write” code from scratch anymore; we assemble it. We are manufacturing applications on an industrial scale. We take a database from here, a web framework from there, an authentication library from somewhere else, and we glue it all together with a thin layer of our own business logic.
The data backs this up. According to the latest “Open Source Security and Risk Analysis Report” by Synopsys, 96% of all commercial codebases contain open source components. Furthermore, 84% of those codebases contain at least one known vulnerability. We aren’t just using a little bit of open source; our applications are essentially composed of it.
This is fantastic for speed. It allows us to innovate at a pace that was impossible ten years ago. It’s why startups can disrupt giants. But it is absolutely terrifying for security.
Because right now, for most companies, that “frozen lasagna” of software has no ingredients list. It has no seal of authenticity. We are effectively taking binary blobs from the internet (from strangers we have never met, using handles we don’t recognize) and running them in the heart of our sovereign infrastructure. We are downloading packages from NPM, or PyPi, or Docker Hub, often without a second thought.
Consider the phenomenon of “Typosquatting.” An attacker notices that your developers use a popular python library called requests. So, the attacker uploads a malicious library called requessts (with an extra “s”) containing malware. One tired developer makes one typo in a configuration file, and suddenly, you have just invited a trojan horse into your production environment.
We have seen exactly what happens when this goes wrong. We all remember the absolute chaos of Log4j. It wasn’t just a bug; it was a systemic failure. It was a tiny logging library, maintained by volunteers, buried five layers deep in the dependency tree of almost every enterprise Java application in the world. When the vulnerability broke, Chief Security Officers didn’t even know if they were affected or not! They had to scan thousands of servers manually because they didn’t have an inventory.
And let’s not forget SolarWinds. That was a pivotal moment. The attackers realized they don’t need to spend months trying to break into your firewall if they can just poison the water supply. They didn’t attack the customers directly; they injected malicious code into the build system of the vendor. They compromised the factory so that every product leaving the assembly line was pre-infected.
The question we need to answer today is simple, but it is deeply uncomfortable for most IT leaders: Do you actually know what is running in your cluster right now?
Not what you think is running. Not what the architecture diagram says should be running. But what is actually there? And if you don’t know the answer to that question, how can you claim your infrastructure is sovereign? How can you claim you are compliant with upcoming regulations like the EU Cyber Resilience Act, NIS2, or DORA? These regulations are no longer suggestions; they are mandates that will hold boards of directors personally accountable for the hygiene of their digital supply chain.
We need a better way. We need the digital equivalent of a nutrition label, and we need a tamper-proof seal for every single digital artifact we deploy.
The Three Pillars
So, how do we fix this? How do we secure this massive, complex supply chain without slowing our developers down to a crawl? We cannot ask them to manually audit every line of code in every library they use. That is humanly impossible. If we add too much friction, they will just find ways around it, and we end up with Shadow IT, which is even worse.
The solution lies in automation, built on three pillars that are redefining the industry, well known since the times of the Roman Empire: Transparentia, Identitas, et Claustra.
Or in English, Transparency, Identity, and Guardrails.
Transparency
The first pillar is Transparency. In the physical manufacturing world, every part has a serial number. If a specific airbag in a car is found to be defective, the manufacturer knows exactly which cars have it and where they are.
In software, we call this an SBOM…
…also known as a Software Bill of Materials.
This is your ingredients list. It is a machine-readable inventory (usually in formats like SPDX or CycloneDX) that lists every single library, every dependency, and every version number inside your application.
Using open source tools like Syft,…
…or enterprise platforms like Red Hat Trusted Profile Analyzer, we can generate this list automatically every time we build an app. It digs deep (not just listing the top-level libraries you installed, but the transitive dependencies, that is, the libraries that those libraries installed).
What does a SBOM look like? Here’s a fragment of one, showing a dependency on a library available via Maven.
Why does this matter? Imagine the next “Log4j” hits tomorrow morning at 9:00 AM. In the old world, you would spend weeks scanning networks, waking up developers, and panicking. In the new world, you simply query your database of SBOMs. You ask: “Show me every container running Log4j version 2.14.” You get the answer in seconds. You know exactly where the risk is, and you can surgically remove it. That is the power of transparency.
Identity
The second pillar is Identity.
Because knowing the ingredients is good, but knowing who cooked the meal is better. We need to cryptographically sign our code to prove its origin.
Now, I see some of you wincing. I know the history here. Traditionally, code signing has been a nightmare. It usually involves managing private GPG keys that sit on developer laptops.
This approach has two fatal flaws:
First, the “Bus Factor”: If the developer leaves the company, does the key go with them?
Second, Key Hygiene: People lose keys, they leak keys to GitHub by accident, or they just turn the verification off because it breaks their workflow.
You can see the issue here. There’s even an engineer with a third leg in there and another with a third arm holding a diskette. Clearly, not very DevSecOps.
This is where the future is changing. We are seeing a revolution with a project called Sigstore…
…which powers the Red Hat Trusted Artifact Signer.
Sigstore does for code signing what “Let’s Encrypt” did for HTTPS. It makes it free, easy, and automated. It uses a concept called keyless signing.
Think of it like a hotel key card. When you check into a hotel, you don’t get a metal key that you keep forever. You get a plastic card that works for your room, for exactly three days. If you lose it after three days, it doesn’t matter. It’s useless.
Here is how Sigstore works: Your developers don’t generate permanent private keys anymore. Instead, they sign their code using their corporate identity (their Google, Microsoft, or Red Hat login) via OpenID Connect. They prove who they are, and the system issues a short-lived, ephemeral certificate that exists just long enough to sign the code (maybe just ten minutes) and then disappears.
This event is recorded in a tamper-proof transparency log called Rekor. It provides a public, verifiable record that says, “Yes, this specific developer signed this specific piece of code at this specific time.” It removes the burden of key management. It turns signing from a chore into an invisible automated step.
Guardrails
The third pillar is Guardrails.
This is the “Bouncer” at the door. It doesn’t matter if you have a perfect SBOM and a valid signature if nobody checks them before the application goes live. If the bouncer is asleep, the club isn’t safe.
We need an admission controller in our Kubernetes clusters. We use tools like Red Hat Advanced Cluster Security (or ACS) which integrates deeply with Kubernetes admission contexts.
ACS acts as a policy engine. It sits at the API gate of your OpenShift cluster. When a deployment tries to enter, ACS stops it and asks for ID. It checks the signature. It parses the attestation.
It runs a logic check against your specific rules. For example:
Rule 1: “Was this image built on a developer’s laptop?”
Deployment Denied.
Rule 2: “Container signed with the key of another department?”
Deployment Denied.
Rule 3: “Was this image built and signed by our Trusted Pipeline?”
Yes. Access Granted.
This is the fundamental shift in our security posture. We stop relying on hope. We stop relying on manual spreadsheets or quarterly audits. We start relying on cryptographic proof and automated policy enforcement.
We move from “Trust but Verify” to “Verify, then Trust.” We make the cluster itself smart enough to reject the bad stuff.
So, as a recap, remember the three pillars: Transparency, Identity, and Guardrails.
The Architecture of the Factory Floor
So how does this look like in real life?
Let’s visualize how this looks in a real production environment. I want you to think of this as a high-security, automated factory floor.
It starts with the Developer. They are writing code, perhaps using an IDE plugin, and they push their changes to Git. That is the last human interaction in the process. From this moment on, the robots take over to ensure consistency and security.
This git push triggers our factory engine: Red Hat OpenShift Pipelines, based on Tekton.
Tekton spins up a pod to handle the build. But it doesn’t just compile the code. It acts as an observer, a notary, and a security guard all wrapped in one.
Verification: It runs unit tests to ensure functionality.
Scanning: It scans the code for known vulnerabilities using scanners like Clair or Roxctl. If it finds a “Critical” CVE, the line stops right there. The build fails. The developer gets feedback immediately, not three weeks later.
Documentation: It generates that SBOM, creating the “Nutrition Label” for the software.
Sealing: Finally, it uses the Trusted Artifact Signer to cryptographically sign the container image. It stamps the software with a digital seal that says: “This software was built by this sanctioned pipeline, at this time, and it has not been altered since.”
Once the image is signed and sealed, it moves to the warehouse. In our case, this is Red Hat Quay, an enterprise registry.
Quay isn’t just a dumb storage bucket; it understands these signatures and attachments. It keeps the image and its “paperwork” (the SBOM and signatures) together.
Quay also performs “Time Machine” scanning. Just because an image was safe yesterday doesn’t mean it’s safe today. New vulnerabilities are discovered every hour. If Quay detects that a stored image has become vulnerable overnight, it can tag it as unsafe and prevent it from being pulled.
Now, we have a signed, sealed package sitting in the warehouse. How do we get it to the customers? We use GitOps.
We use OpenShift GitOps, based on the Argo CD project. Argo is the delivery truck. It monitors the warehouse. When it sees a new, valid image is available, or when the git configuration changes, it reaches out to pull that image into the production cluster.
Crucially, Argo CD also handles Drift Detection. If a cowboy administrator SSHs into a server and manually changes a configuration, Argo notices the difference between the “desired state” (Git) and the “actual state” (Cluster). It will automatically overwrite the manual change, healing the system back to its trusted state.
But remember the bouncer we talked about?
As Argo tries to apply this update to the cluster, the OpenShift API pauses. The admission controller steps in. It verifies the signature against the public transparency log. It confirms the “Chain of Custody.”
It asks: “Did this come from our factory? Does the signature match the public key we trust?”
Because the signature matches your organization’s trust policy, the gate opens, and the workload starts.
Conversely, if a developer tries to bypass this process (if they try to manually use kubectl or oc to deploy an unsigned container from their laptop, or if a hacker compromises a credential and tries to inject a rogue container) the cluster will reject it immediately. The admission controller will see there is no signature, or the wrong signature, and it will block the request before the container even pulls.
This entire process happens in minutes. The developer didn’t have to run a security scan manually. They didn’t have to manage a private key. They didn’t have to open a ticket for a security review. They just pushed code. The platform (the Golden Path) handled the sovereignty, the compliance, and the security automatically.
Conclusion
We have talked a lot about technology today: Tekton, Sigstore, Argo CD, OpenShift. We’ve looked at diagrams and command lines. But I want to leave you with a thought about Trust.
For a long time, we treated security as a gate. It was a hurdle that developers had to jump over.
It was the “Department of No.” And because it was hard, and because it slowed people down, smart people found ways around it. That is how supply chains get broken. That is how vulnerabilities slip in. When security fights against velocity, velocity usually wins, and security suffers.
The approach we discussed today, this “Trusted Software Supply Chain”, flips the script entirely. It makes the secure way the easiest way.
Through the Trusted Software Supply Chain, Red Hat provides a tool for each of the three pillars: Transparency through the Trusted Profile Analyzer; Identity, thanks to the Trusted Artifact Signer; and Guardrails, with the Advanced Cluster Security for Kubernetes.
By embedding these checks into the platform itself, by using Red Hat OpenShift and these open source standards to automate the “boring” parts of compliance, we grant our developers the freedom to move fast. We give them the confidence to innovate, because we know the guardrails are solid. We stop asking them to be security experts and start giving them tools that are secure by default.
Sovereignty isn’t just about where your servers are physically located or which cloud provider you pay. Sovereignty is knowing, with mathematical certainty, exactly what software is running on those servers and exactly who put it there. It is about having total visibility and control over your digital assets.
So my challenge to you is this: Don’t leave your infrastructure to chance. Don’t rely on implicit trust. Build the factory. Sign your code. And take back control of your supply chain.
Thank you very much for your attention.