While container usage has exploded, the status quo of container development remains risky. Public registries are full of outdated base images, dependency bloat, and unclear provenance. As a result, CI/CD pipelines that should speed up innovation instead light up with CVE alerts, forcing engineers to divert time away from building features to keep their systems secure.

At ActiveState, we asked a simple but crucial question: Can we build images that are vulnerability-free from the very beginning, and more importantly, what if they could stay that way no matter what?

The result is ActiveState Secure Containers, our minimal, low-to-no CVE container images for popular programming languages, frameworks, and applications. In this blog, we’ll walk through how we build them, the principles we follow, and how our approach to maintenance keeps them as close to vulnerability-free as possible.

The Two Pillars: Minimization and Hardening 

At ActiveState, container security operates on two interrelated principles: minimization and hardening. 

Minimization means removing everything unnecessary. If it’s not there, it can’t be exploited—fewer libraries, fewer tools, and fewer potential attack vectors. As a bonus, smaller images are faster to pull and easier to update.

Hardening is locking down what remains. Secure defaults, restricted permissions, and careful configuration make it harder for attackers to gain a foothold.

Together, these pillars create “defense in depth.” Instead of only reacting to CVEs once discovered, we leverage both techniques to proactively reduce the chance of vulnerabilities existing in the first place. In practice, this starts with building our own custom base image. 

Our Distroless Foundation 

For most teams, building a container image often begins with searching through DockerHub to find a pre-existing image suitable for the base of their container. While public repositories make it quick and easy for teams to get started, these images (typically  Alpine, Debian, or Ubuntu-based) are often bloated, with unpatched vulnerabilities and misconfigurations. 

To achieve complete control over our base image, ActiveState has developed a custom distroless base image that acts as the foundation for all other ActiveState images. Instead of packaging a complete Linux-based distribution with its supporting utilities and libraries, our base includes only what’s absolutely required to support containerized applications. No shells, no package managers, and no debugging tools (for developers, we provide a “dev” variant of our base image). 

Even more, we compile directly from source, allowing us complete control over the included components. More on building from source later! 

The benefits are clear, less software to manage means:   

• Reduced attack surface: fewer packages to patch or monitor.
  
• Smaller image size: faster pulls and leaner deployments.
  
• Improved compliance: control and visibility into every component.

For both our free image catalog and custom containers, this custom base allows us to simplify the maintenance of our images drastically. With fewer moving parts, patching becomes faster and easier.

The Application Layer – No More Blind Trust 

While the base is a good starting point, even the most secure base images can be undermined by what’s install on top. In nearly every containerized application, there’s a second and often more insidious layer of risk: the required application dependencies. To add functionality to their software, developers frequently rely on public package managers like pip, npm, and Maven. These tools are powerful and convenient, but also risky. See the recent npm supply chain attack for proof! 

ActiveState Secure Containers take no such chances. In addition to providing a secure base image, we build open-source software from source. Doing so allows us to layer languages, packages, and entire applications on top of our base image while maintaining control over their files and configurations. For example, in our base image, we can build glibc to have the absolute bare minimum requirements while also including the appropriate configurations for memory protection. For Python, we can build the absolute bare minimum or include any of the popular libraries that many apps rely on.  

Building from source provides us with four critical advantages:

Trustworthy supply chain: We start with verified code and validated provenance to remove the risk of malicious binaries sneaking in.

Shrink and optimize: By stripping unused dependencies, we keep images small and efficient.

Faster patching: When a vulnerability receives a fix, there is no waiting for upstream images to be updated.

Audit readiness: For regulated industries, our build platform provides complete transparency into how every component is built and assembled. 

Once the base and necessary components are ready, we assemble our container images according to the OCI image specification and ensure that we apply minimization and hardening best practices wherever possible. This includes restricting permissions, configuring metadata, and further slimming. 

Image Testing – Our Automated Pipeline 

Once assembled, it’s not enough to assume that an image is appropriately slim and secure. We run a variety of checks across key metrics to ensure that every image we produce is both functional and secure before distribution. 

Beyond basic functionality testing, we benchmark every image for total size against a variety of comparable images available on DockerHub. To successfully pass, we aim to achieve a total image size within 10-20% of the nearest comparison. We also benchmark against hardening best practices to assess:

• Image Provenance – Verifying source and authenticity 
• Configuration & Metadata – Applying secure defaults and best practices 
• Vulnerabilities – Tracking known vulnerabilities at any point in time

To assess vulnerabilities, we scan all images using a variety of SCA tools, including Docker Scout, Trivy, and Grype. To pass, all images must produce zero effective CVEs before they make it out of our testing process. 

A member of our engineering team will investigate each CVE to determine its impact and issue a Vulnerability Exploitability eXchange (VEX) advisory. For example, if the CVE does not affect the image, we issue an advisory and provide specific reasoning for why. We publish all VEX advisories to our GitHub page. 

“status”: “not_affected”,

      “justification”: “vulnerable_code_not_present”,

      “impact_statement”: “This version of gcc contains the patch.”

Rust Advisory: CVE-2023-4039

If the testing pipeline detects a failure, the image is sent back for reconstruction, further minimization, or hardening as needed. Once an image has successfully made its way through the pipeline, it is now ready for publishing and staged for further distribution. When ready, we distribute images to both public and private repositories. For our public image catalog, we publish the latest version of our container images to our DockerHub page. This rigorous process ensures that only vulnerability-free images make it out of our pipeline, simplifying image maintenance in the future. 

Staying Vulnerability Free 

Of course, our job isn’t complete after publication. Vulnerabilities emerge every day. To stay ahead, we adhere to strict remediation SLAs of 7 days for critical CVEs and 14 days for all others.

When our automation identifies a vulnerability in either our public catalog or a custom image, ActiveState takes on the entire remediation process. Our automated build system springs into action, rebuilding the affected open-source components from source using a patched version pulled from our industry-leading catalog of over 40M+ secure components. 

ActiveState’s catalog updates to include every currently supported version of software maintained by the project’s upstream. In some cases, we may even backport a patch to support custom requirements for our customers. 

All images are rebuilt nightly, tested using our pipeline described above, and delivered back to our catalog and customers’ private repositories with SBOMs, attestations, and signatures to ensure complete transparency and traceability. This comprehensive approach means there’s no manual patching for your team, no complex dependency guesswork, and the process fully offloads the overhead of managing custom images.

Container security is not a one-time task. It’s an ongoing, iterative process. Attackers are constantly looking for new ways in, and new vulnerabilities are disclosed daily. Teams that rely on public images, precompiled binaries, and bloated containers face a constant uphill battle against CVEs.

By contrast, we flip the script by:

• Starting with a clean, minimal, distroless base.
• Building everything from source.
• Ensuring assembled images are appropriately minimized and hardened. 
• Maintaining all images and their components with strict SLAs.

Containers that are as close to vulnerability-free as possible save developers time, reduce security noise, and strengthen software supply chains.

Try ActiveState Secure Containers 

To get started, the latest versions are available at no charge and ready to integrate into your existing CI/CD workflows. For teams who require custom configurations, additional packages, or further hardening, ActiveState’s custom container service is here to help. No matter what your specifications are, our team will ensure that every component is fully secured and ready for deployment.

Contact us today, and try your first custom container free!