By Biswajit De is Co-founder and CTO at CleanStart. CleanStart were Shortlisted in the ‘Best Cybersecurity Solution’ and the ‘Best Security Compliance in Enterprise’ awards at the 2026 Security Awards.

Most modern security strategies start with a simple assumption: if the container is secure, the application is secure.

It’s not an unreasonable place to focus, because containers are where software runs, and over time we’ve built a solid set of controls around them. We scan images, enforce policies in pipelines, and monitor behavior at runtime. And while that’s all important and certainly not wrong, there’s a deeper issue that tends to get overlooked. By the time a container exists, a significant part of its security posture is already locked in.

Security Today Starts After the Build

In most environments, security kicks in once the artifact is already assembled. We inspect it, compare it against known vulnerabilities, and decide whether it can move forward. While this process is necessary, it’s also reactive by design.

At that point, you’re no longer just deciding what goes into the system, and you start making tradeoffs on what you’re willing to accept.

Containers Aren’t Built in Isolation

A container image looks like a single unit, but it’s anything but that. It’s layered together from operating system components, runtimes, libraries, and a long chain of dependencies. Most of that chain isn’t built by the team shipping the application, but instead it’s pulled in.

I’ve seen numerous times how those upstream components can be well-maintained and widely used, but in practice, very few teams can say how they were built, what assumptions went into them, or whether that process can even be independently verified. In many cases, organizations are securing software they didn’t fully build. 

New advances have improved visibility into what’s inside an image, making scanners and SBOM tools now standard, and they do a good job of telling us what’s inside an image. Unfortunately, though, they operate within a boundary.

These tools can tell you what’s there and whether it’s associated with a known issue, but what they don’t tell you is how that component came to be, whether it was modified along the way, or whether the process that produced it can be trusted.

There are efforts to address this, with provenance frameworks and attestations moving things forward, but adoption is uneven and coverage is still incomplete. So we end up in a familiar place: We know more than we used to. But we still don’t know enough to establish trust.

Smaller Images Don’t Change the Equation

Minimal and hardened images are a step in the right direction. Fewer packages mean less noise and a smaller surface area to deal with.

But the underlying assumption doesn’t really change.

A smaller image can still include components that were built elsewhere, under conditions you can’t verify. It may be easier to manage, but it doesn’t automatically become more trustworthy.

The Real Gap Shows Up Earlier

Most security models focus on the output and validate what comes out of the build process, but what’s even less common is controlling how that output is created in the first place.

If the inputs and the build process aren’t something you can trust, then everything downstream is operating with some level of uncertainty. You can reduce risk, but you can’t fully explain it, and most tools aren’t designed to solve this problem.

To be clear, this isn’t about eliminating vulnerabilities. Those will always exist. The difference is whether you understand where they came from and how they got there.

Why This Is Getting Harder to Ignore

Software delivery has become faster and more abstracted. Teams rely on pre-built images, shared repositories, and automated pipelines just to keep up. At the same time, attacks have shifted in that direction. We’re seeing more cases where attackers are using system components to gain entry.

Sometimes the compromise happens before the container is even built. It’s entirely possible for a base image to pass a vulnerability scan and still include something that was built in a way you wouldn’t trust if you had full visibility into it.

Rethinking Where Security Begins

If security starts only at the container, it will always be reacting to what already exists.

A more reliable approach is to move that starting point earlier, to the stage where components are actually built and assembled.

That changes the nature of the problem and Instead of asking, “Is this artifact acceptable?” You start asking, “Do we trust how this artifact was created?”

In practice, that means things like:

• Knowing where your components come from and what you trust
• Reducing non-determinism in how builds are executed
• Limiting uncontrolled inputs during the build process
• Being able to verify artifacts through reproducibility or provenance, not just inspection

None of this is free. It adds complexity, and it may slow down parts of the pipeline, but it also gives you something most current approaches don’t: confidence in what you’re running.

Closing Thought

We’ve spent years improving how we secure containers and runtime environments, and that progress matters. These controls are necessary and will continue to play an important role. But they are largely focused on the layer where software runs instead of where it is created.

Security extends beyond what teams can observe and control at runtime. Build integrity, dependency provenance, and the ability to verify how a system was assembled all shape the level of trust an organization can place in what reaches production. Gaps in that process leave uncertainty behind, even when downstream protections are in place.

Starting earlier in the lifecycle does not replace scanning, policy enforcement, or runtime protection. Earlier verification strengthens the foundation those controls rely on and gives teams a more reliable way to reduce exposure before software reaches production.

This is also the direction we’ve taken at CleanStart, focusing on building software from verifiable, trusted sources rather than trying to secure it after the fact.