ActiveState and Docker Combine Hardened Images With Patched Open Source Libraries

Hardened container images address only part of the software supply chain. Applications also depend on libraries layered above the base image, and those components need updates, provenance and ongoing vulnerability checks. ActiveState and Docker are combining those parts of the stack for enterprise teams, with each company reselling artifacts curated by the other.

The arrangement pairs Docker Hardened Images with ActiveState’s remediated open source libraries. The companies say the artifacts are built using Supply-chain Levels for Software Artifacts (SLSA) Level 3 practices. The stated aim is to make it easier for development teams to source both container images and application dependencies through the same commercial channel.

Details of the arrangement describe reciprocal resale. That could simplify procurement for teams that currently assess image and library suppliers separately, although it doesn’t remove the work of deciding which artifacts fit an application or tracking what changes between versions.

Coverage across the software stack

Docker has curated more than 4,000 hardened images, according to ActiveState CEO Abby Kearns. ActiveState offers libraries across 10 programming languages and says it can make a hardened library available within five days after an upstream open source project fixes a vulnerability. That service level agreement gives buyers a specific patch turnaround to consider, though the source doesn’t spell out how the clock is measured or what happens when a fix requires more work.

The distinction between an image and its dependencies matters in practice. A container image supplies a starting environment; application teams then add software their code needs. Hardening the base can reduce exposure in that layer, but it doesn’t automatically update every package added later. Teams still need a reliable view of what’s inside their builds and a process for replacing vulnerable components.

SLSA practices address how artifacts are built and how their origin can be checked. Docker provides SLSA Build Level 3 provenance, while ActiveState builds components in SLSA Level 3 infrastructure, according to the article’s source material. Provenance can help a team verify a build’s history and detect tampering. It doesn’t, on its own, establish that every component is free of known vulnerabilities or that downstream applications have adopted a fix.

The adoption gap

ActiveState’s survey points to a gap between security priorities and current practice. It found that 91% of application development teams had limited visibility into container components, while 90% used lightly modified public images with little or no hardening. At the same time, 98% of respondents said adopting hardened images was a high priority.

Those figures suggest that awareness isn’t the only obstacle. Hardening software takes recurring engineering effort: teams must inventory dependencies, assess upstream fixes, rebuild artifacts and confirm what was shipped. Many application groups have limited capacity for that work while also maintaining products and delivering new features. A supplier that takes on some of the rebuilding and remediation could reduce that burden, provided its update pace meets the needs of customers.

That timing is central to the offer. Futurum Group software lifecycle engineering practice lead Mitch Ashley said teams must track dependencies, rebuild after upstream fixes and prove provenance. He also warned that the value of supplier-maintained artifacts depends on ActiveState and Docker keeping their patch and rebuild work ahead of the time it takes attackers to exploit a vulnerability. The five-day library target is therefore a useful starting point for evaluation, not a complete measure of protection: teams will want to understand coverage, exceptions and how quickly updated artifacts reach their build pipelines.

AI increases dependency pressure

The article also cites a separate ActiveState survey on AI coding tools. Among respondents whose organizations used those tools in production, 94% said their use of open source software had increased. The survey says 89% of respondents worked at organizations using AI coding tools in production.

More dependencies can mean more components to inventory and update. The practical effect depends on how teams manage those packages: automated code generation may speed development, but it doesn’t replace review of the libraries an application pulls in or the artifacts used to deploy it. For teams adopting AI coding tools, dependency visibility and repeatable builds become more consequential as the software supply chain grows.

What buyers should check

The combined catalog could make it easier to obtain hardened images and libraries, and a shared route to those artifacts may reduce supplier coordination. The source doesn’t provide pricing, compatibility details, migration steps or information about how the companies will handle support across products. Those details will shape the work required to adopt the offerings alongside existing registries, build systems and dependency controls.

Teams assessing the arrangement should look at which images and libraries are covered, how fixes are delivered, what evidence accompanies each build and whether artifact updates fit existing deployment workflows. Hardened inputs can reduce the amount of remediation an application team must perform itself, but the value rests on coverage and maintenance over time. The next signal to watch is whether the companies can keep their artifact updates timely and make their build evidence practical to verify.