Managing third-party images at scale
Third-party container images are foundational to modern cloud infrastructure. They support everything from base runtimes to critical application dependencies. They also introduce one of the most complex and least understood sources of operational risk.
At Chainguard Assemble 2026, I shared how we approached third-party image management at scale within Appian and how that journey reshaped our security, compliance, and developer productivity.
This post reflects that session. You can watch the full recording embedded below.
The hidden complexity of third-party images
Most organizations rely heavily on third-party images. That reliance grows quickly as platforms scale. At first, the model seems straightforward. Pull a base image, build on top of it, scan for vulnerabilities, and ship. At scale, that model breaks down.
Every image introduces its own set of dependencies, vulnerabilities, and maintenance requirements. As the number of services grows, so does the number of images, and with it the number of issues that need to be triaged and remediated. This creates a compounding effect. A single vulnerable base image can impact dozens or hundreds of downstream services. Each one requires investigation, patching, and validation.
The operational burden grows faster than most teams expect.
When scale meets compliance
For organizations operating in regulated environments, the challenge becomes even more pronounced.
At Appian, we support customers across sectors with strict compliance requirements, including FedRAMP and other high-assurance environments. That means every image must meet strict standards for patching, hardening, and traceability. Compliance is not a one-time effort. It is continuous.
Every rebuild, every dependency update, and every newly disclosed vulnerability creates additional work. Teams are required to prove not only that systems are secure, but that they remain secure over time. Without the right approach, this becomes a constant cycle of firefighting.
The cost of managing it yourself
One of the most important realizations for us was the true cost of managing third-party images internally. On paper, building and maintaining hardened images in-house can seem like a reasonable approach. In practice, it requires significant and sustained investment.
At Appian, we estimated that building a complete internal program would require a dedicated team of 15 to 20 engineers, with ongoing maintenance as a permanent cost. Even then, keeping up with vulnerability disclosures, patch cycles, and compliance requirements would remain a challenge. More importantly, every hour spent maintaining images is an hour not spent building product features.
As I put it during the session, the overhead of patching and maintaining third-party components directly impacts the speed of innovation.
Why traditional approaches do not scale
The traditional approach to image management mirrors legacy vulnerability management practices. Teams pull images from public registries, scan them, triage findings, apply patches, and repeat. This approach assumes that teams can keep up with the volume of vulnerabilities and the pace of change.
That assumption does not hold in modern environments.
Images are rebuilt frequently. Dependencies change continuously. New vulnerabilities are disclosed daily. Static scanning provides only a point-in-time view, while the underlying risk continues to evolve. As a result, teams spend more time reacting than improving.
Shifting the model
To address this, we needed to change the model rather than optimize the existing one.
The key shift was moving away from directly consuming and maintaining third-party images, and toward relying on curated, continuously maintained sources. This changes where the work happens. Instead of every team independently managing vulnerabilities, that responsibility is centralized and handled upstream. Images are patched, hardened, and maintained throughout their lifecycle before they are consumed.
For engineering teams, the experience becomes simpler. Pull an image, verify it, and deploy. For security teams, the focus shifts from constant triage to validating controls and monitoring outcomes.
Reducing operational friction
One of the most immediate impacts of this shift is a reduction in operational friction. Developers no longer need to spend cycles evaluating base images or repeatedly addressing the same classes of vulnerabilities. Security teams are no longer overwhelmed by large volumes of repetitive findings.
This has a direct impact on productivity. At Appian, reducing the overhead of managing third-party components allowed engineers to refocus on building new features and delivering value to customers. That shift is measurable. More time spent on innovation translates directly into better products and faster delivery.
From security burden to business advantage
There is also a broader impact on how security is perceived within the organization. When managing third-party images becomes a constant source of friction, security is seen as a blocker. It slows down delivery and creates tension between teams. When that burden is reduced, the dynamic changes. Security becomes an enabler. It provides a stable, trusted foundation that allows teams to move faster with confidence.
This also has implications for the business. Improved security posture supports faster compliance, easier audits, and access to regulated markets. At Appian, this shift helped accelerate timelines for meeting strict accreditation requirements and enabled expansion into new markets.
Lessons learned
Managing third-party images at scale is both a technical and organizational challenge. It requires rethinking ownership, shifting where work is done, and aligning security practices with how modern systems are built.
The most important lesson is that scale changes everything. What works for a small number of services does not work for hundreds or thousands. The second is that trying to solve the problem independently within each team leads to duplication, inconsistency, and unnecessary costs. The third is that reducing friction is just as important as reducing risk. When the secure path is also the easiest, adoption follows naturally.
Moving forward
Third-party images will remain a core part of cloud native development. The question is not whether to use them, but how to manage them effectively. Organizations that treat image management as a strategic capability will be better positioned to scale securely, meet compliance requirements, and maintain developer velocity.
The goal is not to eliminate risk entirely. It is to bring it under control in a way that supports the business. When done well, managing third-party images becomes less about constant remediation and more about building a foundation that teams can trust.
Catch all the sessions from Assemble on-demand here.
Share this article
Related articles
- engineering
Ship and patch doesn't cut it in the AI era
Dan Lorenc, Co-founder and CEO
- engineering
Removing supply chain friction: How PeopleTec improved developer productivity with Chainguard
Brandon Heard, Technical Leader, Cloud and Infrastructure, PeopleTec
- engineering
Breaking the release monolith: How OutSystems platform engineering restored trust in delivery
Maria Chec, Technical Program Manager, OutSystems, and João Brandão, Release Engineering Director, OutSystems
- engineering
Owning the boundary: Introducing the Chainguard FIPS Provider for OpenSSL 3.4.0
Dimitri John Ledkov, Senior Principal Software Engineer, and Mandy Hubbard, Senior Technical Product Marketing Manager
- engineering
FIPS-ing the Un-FIPS-able: Apache Kafka
Jamon Camisso, Senior Manager, Software Engineering
- engineering
This Shit is Hard: The complexities of fixing Python library security issues at scale
Wesley Wiedenmeier, Senior Software Engineer