Anchore Engine gave teams a central place to inspect container images before deploying them. It collected information about an image's contents and checked that information against rules, such as whether known vulnerabilities should block a release. Build systems could request a scan through its API instead of each team maintaining an unrelated scanning process. This page concerns the retired Engine service and the work needed to replace its integrations.
Current guidance
Anchore Engine has not been maintained since 2023; upstream points to Syft and Grype for related SBOM and vulnerability workflows.
Those tools do not automatically reproduce every centralized Engine API, policy or enterprise feature. Inventory the actual scanner integration, reports and gating behavior before choosing replacements.
Compare a pinned image set with current advisory databases and inspect disagreements. Keep old reports for audit context, but do not present their counts as current results. Update CI failure handling and exception policy when moving tools.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub marks anchore/anchore-engine as archived. This confirms the repository's read-only archive state; any successor or supported distribution needs separate evidence. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
Anchore Engine
The Anchore Engine is an open source project that provides a centralized service for inspection, analysis and certification of container images. The Anchore engine is provided as a Docker container image that can be run standalone (a docker-compose file is provided), or on an orchestration platform such as Kubernetes, Docker Swarm, Rancher or Amazon ECS.
The Anchore engine can be accessed directly through a RESTful API or via the Anchore CLI.
Using the Anchore Engine, container images can be downloaded from Docker V2 compatible container registries, and then evaluated against user defined policies. The Anchore Engine can integrate with Anchore’s Navigator service, allowing you to define policies and whitelists using a graphical editor that are automatically synchronized to the Anchore Engine.
Chart Details
The chart is split into three primary sections: GlobalConfig, CoreConfig, WorkerConfig. As the name implies, the GlobalConfig is for configuration values that all components require, while the Core and Worker sections are tier-specific and allow customization for each role.
NOTE: It is highly recommended to set a non-default password when deploying. The admin password is set to a default in the chart. To customize it use: –set globalConfig.users.admin.password=<pass> or set it in the values.yaml locally.
New to v0.1.8 of the chart: configurable archive drivers. Archive drivers allow Anchore Engine to store the large analysis results in storage other than the postgresql db (the default). The currently supported drivers are: S3 and OpenStack’s Swift, as well as a localfs option for testing (not for production).
Core Role
The core services provide the apis and state management for the system. Core services must be available within the cluster for use by the workers.
Core component provides webhook calls to external services for notifications of events:
- New images added
- CVE changes in images
- Policy evaluation state change for an image
Worker Role
The workers download and analyze images and upload results to the core services. The workers poll the queue service and do not have their own external api.
Sources & further reading
Spotted something that needs another look?
Help improve this page →