Container adoption has a well-known pattern: developers start using Docker or similar tools on their workstations, containers spread into CI pipelines, and before long the entire organization is running workloads in Kubernetes—sometimes before the security team has had a meaningful look. If your shop is already waist-deep in containers, you are not alone.
This reality places security practitioners in a difficult position. You must simultaneously secure the container runtime and orchestration layer, validate the applications and libraries packed inside each image, maintain rigor in every other area of your program, and rapidly build expertise across container engines, orchestration platforms, microservice patterns, and cloud-native tooling. Any force multiplier helps.
The Core Problem: Opacity Inside Container Images
A container image is not simply a binary. It is a layered filesystem that can contain an operating system base, language runtimes, third-party libraries, application code, configuration files, and—if developers are not careful—credentials and secrets. Without deliberate inspection, it is easy to deploy images whose full software bill of materials (SBOM) is unknown, including packages that carry known vulnerabilities.
Traditional vulnerability scanning typically requires a live, network-accessible host. Container images sitting in a registry or on a developer’s workstation are not live hosts. You need a different approach: static image analysis that unpacks each layer of the image and inventories its contents without executing the container.
Anchore Engine: Deep Inspection for Container Images
One open source tool that addresses this problem is Anchore Engine, released under the Apache License 2.0. Anchore Engine unpacks a container image layer by layer and produces a detailed inventory of everything inside, including:
- Operating system packages (RPMs, DEBs, APKs, and others)
- Language ecosystem packages (Python, Ruby gems, Node modules, Java JARs, and similar)
- Runtime versions (JRE, Node.js, Python interpreter, etc.)
- Configuration files that affect container behavior
- Secrets and credentials inadvertently baked into the image
According to Anchore’s own documentation and public statements, the engine then maps the discovered packages against known vulnerability databases, surfacing CVE identifiers for any vulnerable software found. This gives you something functionally similar to a vulnerability scan report, but produced statically against the image—no running container required.
Why Visibility Into Image Contents Matters
Knowing exactly what is inside a container image is valuable in several contexts beyond simple vulnerability detection:
- Software architecture reviews: Image analysis exposes accidental or undocumented dependencies that would otherwise be invisible in design reviews.
- Threat modeling: A complete package inventory makes attack surface analysis much more accurate.
- Secrets management: Automated inspection can flag credentials, tokens, or private keys that developers accidentally included in an image layer.
- Compliance and audit: Regulators and auditors increasingly ask organizations to demonstrate they know what software is running in production. A generated SBOM satisfies that requirement.
- Patch management: When a new CVE is published, you can immediately query which images contain the affected package rather than waiting for a traditional scan cycle.
Integrating Container Image Scanning Into Your Workflow
There is no single right place to run image analysis. The best answer depends on your organization’s maturity, risk tolerance, and pipeline structure. Consider three common integration points:
1. Developer Workstations and Inner Loop
Enabling developers to run image analysis locally gives them immediate feedback. They can identify and remove stale libraries, unnecessary OS packages, or vulnerable base image versions before a single line is pushed to a shared repository. This is the leftmost shift possible and generally the cheapest place to fix a problem.
2. CI/CD Pipeline Gates
Integrating image scanning as a pipeline stage—immediately after the image build step and before the image is pushed to a registry—creates an automated quality gate. A pipeline script can invoke the scanner, evaluate the resulting policy report, and fail the build if images do not meet defined standards (for example, no critical CVEs, no embedded secrets). This is the most impactful integration point for most teams because it prevents vulnerable images from reaching the registry at all.
Anchore Engine exposes a REST API and CLI that are straightforward to call from Jenkins, GitLab CI, GitHub Actions, CircleCI, and similar systems. Pre-built integrations and plugins exist for several of these platforms.
3. Registry and Production Monitoring
Images already in production or sitting in a registry can be analyzed retrospectively. This is especially useful when a new CVE is published and you need to determine your exposure across a large fleet of deployed images. Point Anchore Engine at your registry, analyze the image manifests, and query the results against the new CVE.
Getting Started With Anchore Engine
Anchore Engine is designed to run as a set of containerized services orchestrated with Docker Compose. If you already have Docker and Docker Compose installed, the initial setup requires only a handful of shell commands to pull the Docker Compose configuration file and start the services. No upfront licensing cost is involved for the open source edition.
At a high level, the workflow looks like this:
- Start the Anchore Engine services using Docker Compose.
- Add the image you want to analyze (by name or digest) to the engine’s queue.
- Wait for the analysis to complete (the engine pulls the image, unpacks layers, and builds the inventory).
- Query the results: package list, CVE matches, policy evaluation outcome.
The engine ships with a default policy that flags the most commonly encountered vulnerability classes. You can customize policies to match your organization’s risk thresholds—for example, blocking on critical or high-severity CVEs while warning on medium-severity findings.
Open Source vs. Commercial Alternatives
Anchore Engine is not the only tool in this space. Other open source options—such as Trivy (from Aqua Security) and Clair (from Quay/Red Hat)—address overlapping use cases. Commercial offerings from vendors including Aqua Security, Prisma Cloud (Palo Alto Networks), Sysdig, and Snyk provide broader platform coverage, managed infrastructure, and enterprise support.
The value of starting with an open source tool is not that it is necessarily better than a commercial product—it is that you can start today. You can validate that image scanning provides real value in your environment, experiment with where it fits best in your pipeline, and build the internal case for a commercial investment if you need one. An open source tool is an ideal on-ramp and a practical stopgap, not necessarily the final destination.
Key Takeaways
- Container images often contain far more software than their owners realize, including vulnerable packages and accidentally embedded secrets.
- Static image analysis does not require a running container, making it applicable to images at any stage of the software supply chain.
- Anchore Engine is a free, Apache-licensed tool that unpacks container images layer by layer and maps their contents to CVE databases.
- The most impactful integration point for most teams is the CI/CD pipeline, where scanning can act as an automated gate before images reach a registry.
- Starting with an open source scanner costs nothing but time and provides immediate visibility, even if a commercial solution is the eventual goal.
Original article sourced from TechNewsWorld (technewsworld.com), January 2020.