Azure Pipelines

Anchore Enterprise can be integrated into Azure DevOps pipelines to generate and analyze SBOMs, perform vulnerability scanning, and enforce policy evaluation as a pipeline gate. This page covers two integration approaches: distributed analysis and centralized analysis.

Prerequisites

The following are required for both integration approaches:

A running Anchore Enterprise instance. See Deployment for setup instructions.
An Azure DevOps pipeline.
An Azure Key Vault variable group named anchoreCredentials containing your Anchore Enterprise credentials. The following variables are required:

Variable	Description
`anchore_url`	The URL of your Anchore Enterprise instance
`anchore_endpoint`	The hostname of your Anchore Enterprise instance (used to download AnchoreCTL)
`anchore_user`	Your Anchore username, or `_api_key` if using an API key
`anchore_pass`	Your Anchore password or API key value

Note: API keys are the recommended authentication method for CI/CD pipelines. They can be rotated and revoked independently of user accounts. See API Keys for setup instructions.

Distributed Analysis

In distributed analysis, AnchoreCTL generates the SBOM locally on the pipeline agent and uploads it to Anchore Enterprise for vulnerability matching and policy evaluation. The image is not required to be in a remote registry before scanning.

This is the recommended approach for most pipelines. It requires less infrastructure than centralized analysis and avoids the need for a staging registry.

Note: Distributed analysis does not support malware scanning. If your workflow requires malware scanning via ClamAV, use Centralized Analysis instead.

How It Works

The anchorectl image add command accepts a --from flag that specifies the source from which AnchoreCTL should generate the SBOM:

--from docker:<image> — generates the SBOM from a locally available Docker image on the pipeline agent.
--from registry — pulls the image from a remote registry for local analysis. Use this when the image has already been pushed to a registry in a prior pipeline step, as it captures the registry-assigned digest, which remains consistent as the image moves through environments.

The first positional argument to image add is the tag Anchore Enterprise uses to identify the image in its database. This does not need to be a pullable registry path.

Distributed Pipeline

trigger:
- master

resources:
- repo: self

variables:
- name: imageRef
  value: 'production/simpleserver:$(Build.BuildId)'
- group: anchoreCredentials

stages:
- stage: Build
  displayName: Build stage
  jobs:
  - job: Build
    displayName: Build
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - task: Docker@2
      displayName: Build image
      inputs:
        command: build
        repository: simpleserver
        dockerfile: Dockerfile
        tags: |
          $(Build.BuildId)

- stage: Security
  displayName: Security scan stage
  dependsOn: Build
  jobs:
  - job: Security
    displayName: Security
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - script: curl -X GET "https://$(anchore_endpoint)/v2/system/anchorectl?operating_system=linux&architecture=amd64" -H "accept: */*" | tar -zx anchorectl
      displayName: Install AnchoreCTL

    - script: |
        export PATH=$PATH:$HOME/.local/bin
        export ANCHORECTL_URL=$(anchore_url)
        export ANCHORECTL_USERNAME=$(anchore_user)
        export ANCHORECTL_PASSWORD=$(anchore_pass)
        # To authenticate with an API key instead:
        # export ANCHORECTL_USERNAME=_api_key
        # export ANCHORECTL_PASSWORD=$(api_token)
        ./anchorectl image add $(imageRef) --from docker:simpleserver:$(Build.BuildId) --dockerfile Dockerfile --wait
        ./anchorectl image vulnerabilities $(imageRef)
        ./anchorectl image check $(imageRef) --fail-based-on-results
      displayName: Anchore Security Scan

- stage: Production
  displayName: Production stage
  dependsOn: Security
  # Push the image to your production registry and deploy

Centralized Analysis

In centralized analysis, the image is pushed to a staging registry and Anchore Enterprise pulls and analyzes it directly using the analyzer service. The SBOM is stored in Anchore Enterprise and available for post-scan reporting, compliance auditing, and policy justification.

This approach is required when malware scanning is enabled. See Malware Scanning for configuration details. Note that enabling malware scanning increases overall scan time.

Providing the Dockerfile via --dockerfile also enables Dockerfile-specific policy checks, such as validating the effective user ID or flagging exposed ports.

Additional Prerequisites

The following are required in addition to the common prerequisites:

A staging registry. Images are pushed here before scanning and promoted to production only after passing policy evaluation. The example below provisions an Azure Container Registry using Terraform:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "blog" {
  name     = "blog"
  location = "West US"
}

resource "azurerm_container_registry" "blog" {
  name                = "staging"
  resource_group_name = azurerm_resource_group.blog.name
  location            = azurerm_resource_group.blog.location
  sku                 = "Standard"
  admin_enabled       = true
}

Note: admin_enabled = true enables the ACR built-in admin account, which uses a single shared credential and cannot be scoped or audited per consumer. For production use, set admin_enabled = false and grant access using a service principal or managed identity with the AcrPull and AcrPush roles as appropriate. See Azure Container Registry authentication options for details.

An Azure DevOps service connection. Required for the pipeline to push images to the staging registry. Configure a Docker Registry service connection targeting your Azure Container Registry. See Azure DevOps service connections for instructions.
Registry credentials in Anchore Enterprise. Anchore Enterprise must be able to pull images from the staging registry. See Registry Configuration for instructions.

Centralized Pipeline

trigger:
- master

resources:
- repo: self

variables:
- name: stagedImage
  value: 'staging/simpleserver:$(Build.BuildId)'
- name: productionImage
  value: 'production/simpleserver:$(Build.BuildId)'
- group: anchoreCredentials

stages:
- stage: Build
  displayName: Build and push to staging
  # Build and push the image to the staging registry

- stage: Security
  displayName: Security scan stage
  dependsOn: Build
  jobs:
  - job: Security
    displayName: Security
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - script: curl -X GET "https://$(anchore_endpoint)/v2/system/anchorectl?operating_system=linux&architecture=amd64" -H "accept: */*" | tar -zx anchorectl
      displayName: Install AnchoreCTL

    - script: |
        export PATH=$PATH:$HOME/.local/bin
        export ANCHORECTL_URL=$(anchore_url)
        export ANCHORECTL_USERNAME=$(anchore_user)
        export ANCHORECTL_PASSWORD=$(anchore_pass)
        ./anchorectl image add $(stagedImage) --dockerfile Dockerfile --wait
        ./anchorectl image vulnerabilities $(stagedImage)
        ./anchorectl image check $(stagedImage) --fail-based-on-results
      displayName: Anchore Security Scan

- stage: Production
  displayName: Production stage
  dependsOn: Security
  # Push the image to your production registry and deploy

Failing a Pipeline on Policy Evaluation

The --fail-based-on-results flag (shorthand: -f) on anchorectl image check causes AnchoreCTL to return a non-zero exit code when the policy evaluation result is stop. This fails the pipeline stage and prevents the image from being promoted.

anchorectl image check <image> --fail-based-on-results

Example output for a failed evaluation:

 ✔ Evaluated against policy                  [failed]
Tag: docker.io/anchore/test_images:convertigo-7.9.2
Digest: sha256:b649023ebd9751db65d2f9934e3cfeeee54a010d4ba90ebaab736100a1c34d7d
Policy ID: anchore_secure_default
Last Evaluation: 2026-02-20T17:19:26Z
Evaluation: fail
Final Action: stop
Reason: policy_evaluation
error: 1 error occurred:
        * failed policies:

One-Time Analysis

Anchore Enterprise supports one-time analysis, which performs vulnerability scanning and policy evaluation without storing the SBOM. This is useful for quick feedback during development before pushing to a registry.

For details, see the CI/CD one-time scan documentation or contact the customer success team via the Support Portal.

Next Steps

Customize which vulnerabilities and compliance violations block a release using Policy Bundles.
Review Deploying AnchoreCTL for more information on getting started with AnchoreCTL.
See the CI/CD integration overview for other supported platforms.

Last modified March 8, 2026