Anchore: Container Security Policy That Actually Scales

Container adoption did not create the software supply chain problem. It made an existing one impossible to ignore.

A 2024 NetRise study examining the most commonly downloaded Docker Hub images found an average of 604 known vulnerabilities per container, with more than 40% rated Critical or High severity. More than 12% of components lacked the metadata needed for traditional scanning tools to assess them at all.  That is not a scanning problem. It is a visibility problem. And visibility at the component level, across every image in every pipeline, is where most container security programs break down.

Why container security fails at scale

The challenge with containerized environments is that they move fast and layer deeply. A single production image might contain hundreds of packages spanning the base operating system, runtime dependencies, open source libraries, and application code. Each layer can introduce vulnerabilities. Each dependency can pull in transitive dependencies that nobody explicitly chose.

Point-in-time scanning helps, but only partially. A scan that clears an image today does not account for a CVE published tomorrow against a package already running in production. And as container fleets grow across CI/CD pipelines, registries, and Kubernetes clusters, manually tracking what is running where becomes operationally unmanageable.

The compliance dimension makes this harder. Frameworks like FedRAMP, NIST 800-53, and DISA STIG require organizations to demonstrate what software components are present, prove those components meet defined security standards, and provide auditable records of that proof. Assembling that evidence from disconnected scanning outputs is exactly the kind of work that does not scale.

The SBOM as a security foundation

Anchore’s approach starts with the Software Bill of Materials.

An SBOM is a structured inventory of every component in a software artifact, down to package name, version, source, and licensing information. Anchore treats the SBOM not as a compliance output but as the operational foundation for everything else. Every scan, every policy check, and every vulnerability finding runs against SBOM data rather than the image itself.

This matters for two reasons. First, it separates the question of what is in a container from the question of what is wrong with what is inside it. Once an accurate SBOM exists, vulnerability analysis and policy evaluation can run continuously against that record without rescanning the original artifact. When a new CVE drops, Anchore can immediately identify which images across the entire environment contain the affected package without waiting for a new scan cycle.

Second, it makes third-party and supplier software tractable. Organizations can ingest SBOMs generated by external vendors in standard formats like CycloneDX or SPDX and apply the same vulnerability and policy checks they run on internally built images. The security posture of the supply chain, not just what the organization builds itself, becomes visible and auditable from a single place.

Scanning that goes beyond CVEs

Anchore’s scanning covers more than known CVE entries. Container images can carry secrets baked into environment variables or configuration files. They can include malware embedded in dependencies. They can have misconfigurations, overly permissive directory settings, or hardcoded credentials that traditional vulnerability databases do not capture. Anchore scans for all of these alongside standard vulnerability checks, giving security teams a more complete picture of actual risk rather than just a CVE count.

The platform also addresses the false positive problem that erodes trust in automated scanning. Rather than surfacing every theoretical match, Anchore applies distribution-specific patch data and backport information to reduce noise. Each finding reflects actual exposure in the environment being scanned, not just a theoretical match against a vulnerability database entry.

Policy enforcement inside the pipeline

Finding vulnerabilities is one part of the problem. Preventing non-compliant images from reaching production is the other.

Anchore’s policy engine lets teams define what good looks like for a given environment and enforce it automatically within CI/CD pipelines. Policies can block a build, generate a warning, or require review depending on severity and context. A team can configure policy to fail a build on any critical CVE with a known exploit while allowing lower-severity findings to proceed with documentation. Different policies can apply to different environments, with production subject to stricter enforcement than staging.

These policies can be built from scratch or derived from pre-built packs aligned to NIST 800-53, CIS Benchmarks, FedRAMP, and DISA STIG. For organizations in regulated industries, that out-of-the-box alignment removes a significant amount of manual work in mapping security controls to compliance requirements.

The API-first architecture means these checks drop into existing workflows. Native integrations cover Jenkins, GitHub Actions, GitLab CI/CD, and Azure DevOps. Security gates that would otherwise require custom scripting and ongoing maintenance become configurable.

Compliance automation for regulated environments

For organizations subject to formal compliance requirements, the audit trail is as important as the enforcement itself.

Anchore maintains a historical record of SBOM data, vulnerability findings, policy evaluations, and remediation actions across the full application lifecycle. When an auditor asks which images were running in production at a given point, which vulnerabilities were present, and what policy enforcement was applied, that record exists in one place rather than being reconstructed from pipeline logs and scanner outputs.

This has particular relevance for defense and government environments. Anchore is an approved component of the DoD Enterprise DevSecOps initiative and a listed tool for meeting Iron Bank container compliance requirements. Organizations working toward FedRAMP authorization can use Anchore to meet the new vulnerability scanning requirements for containerized workloads directly.

What shifts when security moves left

The practical effect of embedding Anchore into CI/CD pipelines is that container security stops being a gate at the end of the delivery process and becomes a continuous check throughout it.

Developers get feedback on vulnerabilities during the build, not after deployment. Policy violations surface at the point where they are cheapest to fix. Security teams spend time on findings that reflect real risk rather than triaging noise from broad scanner output.

For organizations running containerized software at scale, that shift is what makes security policy enforceable rather than aspirational.