Software teams rarely question the building blocks they reuse every day. Once a component runs reliably, it tends to stay in place, even as teams lose track of how it was assembled or what it includes.
Nilesh Jain, cofounder and CEO of CleanStart, has spent more than two decades working in cybersecurity. Much of that time involved helping organizations understand risk introduced through software components they did not build themselves.
Those building blocks bundle things like system libraries and configuration decisions into a single artifact that follows software into production. Orchestration platforms treat that artifact as authoritative, which makes early assumptions difficult to change once reuse becomes routine.
When issues surface, investigations often circle back to those early choices, long after anyone even remembers making them.
Why security keeps arriving too late
Many teams still treat container security as a final checkpoint. Vulnerability scans tend to run once builds feel complete, after base images, dependencies and configurations have already settled into place.
“Scan-at-the-end is reactive,” Jain said. “It catches issues only after insecure components have already entered the build, which leads to rework and delays.”
Once insecure components move into a build, removing them rarely affects just one place. Images spread across environments, pipelines branch, and teams inherit work they did not start. Fixes compete with delivery pressure, and security conversations begin to feel disruptive rather than constructive.
“Starting with a verified baseline removes most inherited risks and the rework that slows teams down,” he said.
Starting clean changes when responsibility enters the picture. Instead of fixing decisions after the fact, teams make them deliberately at the beginning. Security input arrives when choices remain flexible, and accountability feels clearer across engineering and security.
What teams inherit without realizing it
Open source software shows up in almost every modern application, yet many teams have only a partial picture of what actually ends up inside their container images. Public images save time, but they also make it easy for dependencies to slip in unnoticed and stay there.
“The only reliable method is to rebuild the image from source,” Jain said. “Public images often hide nested packages and scripts that never appear in a basic bill of materials.”
Surface-level inventories rarely tell the whole story. Layers pull in other layers. Build scripts run without much scrutiny. Dependencies arrive indirectly, without anyone making a clear decision to include them. After enough reuse, teams struggle to separate what they chose from what they inherited.
Changing that requires forcing ambiguity into the open, making each dependency have to justify its place. Anything unnecessary becomes obvious, which pushes teams to be more deliberate about what they ship.
“Rebuilding from source replaces every dependency with a verified input and removes anything unnecessary,” Jain said. “It produces a smaller, predictable artifact with known provenance.”
Images become easier to update and less brittle to change. When questions come up later, teams can point to specific choices instead of trying to reconstruct how something ended up there.
Where container security is heading
Teams now spend more time trying to explain what software is built on than reacting after something breaks. As container images continue to define how applications move into production, assumptions that once felt harmless become harder to justify and difficult to reverse.
Regulated environments feel the pressure first, with audit questions now extending beyond application code and land at the image level, even when teams never intended to carry that responsibility. Jain sees those expectations tightening across industries as regulators and customers ask for clearer answers.
“The trust of the system now begins at the image boundary, and regulators are moving toward expectations of clear provenance, reproducible builds and accurate SBOMs. Public images cannot meet those standards at scale. Pre-verified images will become a default requirement because they reduce systemic risk and provide a dependable foundation for modern software delivery,” he said.
In that environment, trust becomes less about intent and more about evidence. Images either carry a record of how they were assembled, or they leave teams trying to reconstruct decisions long after they were made.
