When it comes to securing the software supply chain, engineering teams often assume that the choice between building their own hardened images or buying a solution is straightforward…until they try to build the images themselves. As the programmer’s credo goes: “We do these things not because they are easy, but because we thought they’d be easy.” 

The decision has only grown more important as build pipelines increasingly become prime targets for attackers. The risk was first articulated decades ago in Ken Thompson’s 1984 lecture “Reflections on Trusting Trust,” which showed how compilers and build systems themselves could be subverted. For years, it remained a theoretical concern until SolarWinds made it real in 2020. The breach, born from a compromised software build system, became one of the most widespread and damaging supply chain attacks in history. In its aftermath, securing the entire build and distribution process down to the container image level has become an urgent priority for organizations across every industry. 

At first glance, the DIY approach seems simple enough: Start with a base image, patch the vulnerabilities and set up automation to keep things up to date. The problem is that most upstream distributions aren’t fully doing this themselves, so even diligent teams are only applying last-mile fixes on top of already outdated images. What looks like a quick win often evolves into a superficial solution that misses critical upstream issues, while still creating engineering toil. From constantly chasing vulnerability disclosures to testing, distribution and access control, what’s manageable for one image quickly becomes unmanageable at scale. 

For teams considering whether to build or buy, it’s important to look beyond the initial effort and assess what it really takes to maintain secure, production-grade images over time. Below are four areas to be aware of where true cost and complexity often reveal themselves. 

The Hidden Costs of Maintaining Your Own Images 

You cannot take the “set it and forget it” approach with hardened images. The maintenance clock starts ticking the second you ship your first hardened container. Approximately 90% of codebases contain open–source components that are more than 10 versions behind the most recent release. CVEs don’t wait for convenient timing. Libraries and dependencies release updates on their own schedule and regulatory requirements evolve constantly. 

What begins as a single engineering sprint can become a persistent responsibility: Tracking vulnerabilities, responding to alerts, updating and validating packages and ensuring that the changes don’t break anything downstream. On average, developers spend just under six hours per week sourcing, selecting and updating open–source packages. In larger organizations, this becomes a central function, requiring dedicated owners, repeatable processes and support across multiple teams. 

Even with automation in place, someone on the engineering team needs to ensure that the updates are timely, correct and secure. Without this ongoing investment, even well-built images quickly get outdated and become a liability. 

Why Automation Alone Isn’t Enough 

Automation is essential, but it doesn’t eliminate the need for hands-on engineering oversight. Certain tools can help detect upstream changes, open pull requests and even patch common vulnerabilities, but not every update is clean or predictable. What happens when the upstream releases a new version with breaking API changes? 

Automation breaks when inputs change unexpectedly and someone has to step in to find out why. A good example is Kubernetes v1.18, when the project added a required context parameter to nearly all SDK calls in its client-go library. What looked like a minor upstream change broke thousands of downstream projects and forced teams to spend significant time refactoring just to stay current. That is why engineers must not only understand the automation itself, but also compilers, build flags, dependency managers and upstream open–source communities. Without that context, “automated” updates can quickly snowball into downstream disruption. 

Automation requires consistent upkeep. As projects grow and tools evolve, the pipelines and systems you’ve built need to evolve with them. Without that ongoing care, your automation risks becoming a fragile black box. 

Preventing Bottlenecks in Hardened Image Pipelines 

Successful image builds are only one part of the equation. Equally important is validating that those images work as expected and don’t introduce problems elsewhere in the stack. 

Basic unit testing isn’t enough — hardened images need thorough integration tests that mimic real-world environments. That might mean standing up a local Kubernetes cluster to test a suite of services or deploying to a real cloud environment to ensure compatibility with the underlying infrastructure. For some images, especially those that touch external services or use GPU resources, test setups can be resource-intensive and slow to run. 

Without proper testing, it’s easy to miss subtle issues that only appear under real-world conditions. That’s a risk most security-conscious organizations can’t afford to take. 

Delivering Hardened Images Without Introducing New Risks 

Even the most hardened images can become attack vectors if distribution isn’t secure. A striking example: in late 2024, attackers used a compromised DockerHub access token to push a malicious v3.4.0 image of the Kong Ingress Controller, injecting a cryptominer directly into users’ systems. Kong responded swiftly by revoking credentials, removing the malicious image, releasing a patched v3.4.1 and telling users to verify by digest and redeploy. 

This incident shows why access must be auditable and revocable and tooling must strike the right balance between usability and security. Otherwise, the efforts invested in building secure software are immediately undermined at the point of delivery. 

A Practice, Not a Feature 

Building your own hardened images can offer flexibility and control, but it comes with a steep and ongoing cost. The effort extends far beyond the initial build process into automation, testing, distribution and long-term maintenance. These are not simple side tasks; they become a permanent and fundamental part of your engineering workload. 

Before choosing to build, teams should take a hard look at what they can sustainably support over time. Hardened images are not just a feature; they’re a practice. And as software supply chain attacks grow in frequency and sophistication, the ability to maintain that practice at scale is what separates secure systems from exposed ones.