CI / CD Integration
Integrating Anchore Enterprise into your CI/CD pipeline enables fast shift-left feedback, so developers can identify and resolve security issues early in the software development lifecycle.
Platform-specific guides are available for GitHub, GitLab, Jenkins, Azure Pipelines, and AWS CodeBuild; see the subpages in this section. This page covers the requirements and the integration patterns common to all of them.
Requirements
- Network access. Anchore Enterprise must be deployed so its API is reachable from your pipeline runners. For centralized analysis, the deployment must also be able to reach the container registries that host your images.
- Authentication. API keys are recommended for authenticating from a pipeline, though username and password authentication is also supported.
- AnchoreCTL. AnchoreCTL is the primary interface for CI/CD automation and should be version-aligned with your deployment. A common practice is to fetch it from your Anchore Enterprise deployment during the job so the client always matches the server.
Choose an Analysis Mode
Anchore Enterprise supports two analysis modes, described in full under Centralized and Distributed Analysis:
- Distributed analysis is the recommended default for CI. AnchoreCTL generates the SBOM on the runner and uploads it, so image content never leaves the pipeline. Give your runners fast CPU and I/O, and enable cataloger parallelism to speed up SBOM generation. See Using Distributed Analysis Mode for the AnchoreCTL configuration.
- Centralized analysis is required only when you need malware scanning, which unpacks image layers server-side. The deployment pulls and analyzes the image itself.
Gate the Pipeline on Policy
Use the Anchore Enterprise policy engine to turn raw findings into a pass/fail decision the pipeline can act on. Both policy evaluation scopes expose --fail-based-on-results, which returns a non-zero exit code when the result is fail and so fails the CI step.
Evaluate a standalone image in the image catalog against the active policy:
anchorectl image check <MY_IMAGE> --fail-based-on-results --detail
Or check the status of an app version, which rolls up policy results across every asset attached to the version:
anchorectl app version policy status get <VERSION> --app <APP> --fail-based-on-results
On image check, --detail adds the gate, trigger, and remediation detail developers need to resolve violations; for an app version, list the findings behind the verdict with anchorectl app version policy findings list <VERSION> --app <APP>.
One-Time Scan (Stateless Evaluation)
When a pipeline only needs fast pass/fail feedback and does not need the build’s SBOM persisted in the deployment, use a stateless One-Time Scan:
anchorectl image one-time-scan <MY_IMAGE> --from registry --fail-on-policy-error
For the full behavior, output options, and how it appears in usage reporting, see One-Time Scan.
Last modified June 16, 2026