ActiveState and Docker Combine Hardened Images and Open Source Libraries
A joint route to hardened artifacts
Securing a container means tracking more than its base image. Application libraries layered on top can carry their own vulnerabilities, and keeping every component patched takes work many development teams struggle to staff. A clean base image doesn’t settle the security question if the application brings in dependencies with separate histories, maintainers and release schedules. ActiveState and Docker are joining their offerings to make hardened images and open source libraries easier for enterprises to source together.
Announced October 22, 2026, the arrangement lets each company resell the other’s curated software artifacts. Docker contributes its hardened container images; ActiveState supplies remediated open source libraries. The goal is to give development teams access to both types of components, built with Supply-chain Levels for Software Artifacts (SLSA) Level 3 practices. The arrangement addresses a procurement and integration problem: teams looking for maintained components across several layers may otherwise have to evaluate vendors and workflows separately.
Docker has curated more than 4,000 hardened images. ActiveState offers libraries across 10 programming languages and says its service-level agreement makes a hardened library available within five days after an upstream project issues a vulnerability fix. That commitment gives buyers a stated timeframe to assess, though it doesn’t by itself show how quickly a particular fix will reach a running application. Teams still need to identify affected dependencies and adopt updated artifacts in their own build processes.
ActiveState CEO Abby Kearns described the agreement as a way to build an ecosystem around hardened open source artifacts. The practical appeal is a shared purchasing route for software at different layers of a container. Docker’s FAQ says it provides SLSA Build Level 3 provenance, while ActiveState builds components within SLSA Level 3 infrastructure—practices intended to help customers verify how artifacts were produced. Provenance can make that history easier to inspect, but it doesn’t guarantee that an artifact has no vulnerabilities or that a customer has deployed the corrected version.
Security priorities outpace deployment
ActiveState’s survey points to a gap between what security teams say they want and what applications actually run. Some 98% of respondents ranked hardened images as a high priority, yet 90% said their teams still use public images that are only lightly modified or not hardened. Another 91% reported limited visibility into container components. Those results suggest that recognizing a security goal and changing routine engineering practice are separate tasks.
Survey responses describe reported priorities and practices, rather than proving why teams have struggled to change them. Still, the mismatch is familiar in software operations: security work competes with delivery schedules, existing tooling and the effort of tracking components across projects. A curated image or library can reduce some maintenance work, but teams have to understand what it replaces and how updates enter their builds.
That visibility problem extends beyond the image itself. Libraries and other dependencies added by an application need their own monitoring, patching and provenance checks. Teams must follow upstream changes, rebuild affected components and establish how each artifact was made. A container can therefore pass a check at one layer while still including an outdated dependency elsewhere in the stack.
Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group, said that work demands sustained engineering effort. Supplier-built hardened artifacts can shift some of the burden away from application teams, he said, but the suppliers must keep pace with fixes and rebuilds as the time between vulnerability disclosure and exploitation contracts. This is more significant than it looks: a maintained component helps only if the organization can tell that it needs an update and then get that update into production.
AI coding adds dependency pressure
More code is entering production as organizations adopt AI coding tools, and that code often brings additional open source dependencies. In a separate ActiveState survey, 89% of respondents said their organizations use AI coding tools in production. Of those, 94% said they use more open source software as a result, in part because it is readily available. The article also reports that AI models are surfacing more open source vulnerabilities. These findings point to a growing management task: teams may need to account for a wider set of components while maintaining a clear record of what their applications contain.
The survey figures don’t establish that AI tools alone caused the increase in dependencies, or that every additional library carries a known flaw. They do describe a pressure that software teams already face: readily available components can speed development, while each dependency adds another item to track and update. If you’re working in this space, the useful question is whether your build process can identify a dependency and its version before a security issue forces an urgent review.
Meanwhile, the time available to respond to a disclosed flaw may be shrinking: the article says cybercriminals can reverse engineer vulnerabilities into exploits within hours, while attackers are using AI to operate at machine speed. In that environment, waiting for a production incident to expose a vulnerable component leaves teams with little room to react. Faster fixes matter, but so does the ability to locate affected software, assess exposure and ship a corrected build.
Kearns argued that organizations may need a serious breach involving a known vulnerability before engineering teams devote more time to securing existing applications instead of building features. That observation highlights a hard organizational tradeoff: preventive maintenance can be difficult to prioritize when its success is an incident that never happens. Ashley’s assessment puts the operational test on suppliers: can they maintain patch and rebuild speed ahead of the exploit window?
What the partnership will need to prove
The partnership gives enterprises another way to source hardened software across the container stack. Its value will depend on how quickly the companies can deliver corrected artifacts and whether development teams can make those artifacts part of their regular build process. Broader use of maintained images and libraries could reduce the number of vulnerable components reaching production. But buying access is only one step; engineering teams still need to adopt updates and verify that deployed applications use them.
And yet, the shared route may be useful if it makes it easier for teams to procure components with documented build practices and a defined update process. The arrangement’s claims are about supply and provenance; the practical measure is whether customers can keep their software current without adding a new bottleneck. For organizations already struggling to track dependencies, that’s a meaningful test. The fragment that matters: delivery, adoption, and follow-through.
