Ongoing Container Maintenance for Security and Compliance
Jonny Rivera
December 30, 2025

Frequently Asked Questions
Why isn't building a secure base image enough for ongoing container security
A container that passes every check at build time begins accumulating new exposure the moment it's deployed. New CVEs are disclosed continuously against the open source components inside it. Compliance requirements evolve. Base images drift from their original state as the surrounding dependency landscape changes. Without a structured process for rebuilding, rescanning, and revalidating images on a regular cadence, the security posture established at build time degrades over time — often silently, without any alert to the team running the workload. Ongoing maintenance isn't a secondary concern. It's where the security guarantee either holds or breaks down.
What is a VEX advisory and how does it reduce scanner noise?
A Vulnerability Exploitability eXchange (VEX) document is a machine-readable statement that describes whether a specific CVE is actually exploitable in a given component or container, given its build configuration and minimization. When a CVE has no exploitability or impact in a hardened, distroless container — because the vulnerable code path, shell, or package manager it would require has been stripped out — a VEX advisory marks it as "not affected." This allows your scanner to filter out false positives automatically rather than routing them to your triage queue as genuine findings. For teams running hardened images, VEX advisories can eliminate a significant portion of scanner output that would otherwise consume engineering time to investigate and close.
What do ActiveState's container remediation SLAs actually commit to?
ActiveState's remediation SLAs are contractual commitments, not targets. Critical CVEs are remediated within 5 business days, high-severity CVEs within 10 business days, and all other CVEs within 30 business days. The SLA is backed by nightly rebuilds: every ActiveState container is automatically rebuilt from verified source components each night, incorporating the latest security patches without requiring manual intervention from your team. When a new vulnerability is disclosed, the affected component is identified, a patched version is sourced from upstream, the container is rebuilt, rescanned, and redistributed — all within the SLA window and without your team having to open a ticket, coordinate a patch, or validate a rebuild.
.png)
.png)
.png)