Anchore Enterprise Documentation

1 - Quickstarts

1.1 - Achieve Federal ATO

Summary

Anchore Enterprise plays a crucial part in meeting Federal Authorization to Operate (ATO) requirements and Risk Management Framework (RMF). From implementation, assessment, to monitoring, Anchore Enterprise bakes in security compliance, vulnerability & malware scanning by constantly checking registries and running images to protect and enhance security posture. As industry continues to migrate to containerization and microservices, Anchore Enterprise supports multiple regulatory requirements using software bill of materials (SBOM) and policy as code to meet the demands through automated policy enforcement and continuous monitoring. SBOMs are vital to comply with Executive Order (EO) 14028 and understanding software inventory (NIST 800-53, 800-171, 800-218, and 800-190). As software delivery changes so should the ATO process by using code to ensure secure, quality, and reproducible results. Anchore Enterprise allows organizations to shift left, start secure, bake in compliance, and standardize security across the container, filesystem, virtual machine (VM) and source code landscape.

Security Controls

The security controls are described below with hyperlinks to the applicable documentation.

• Software Bill of Materials (SBOM)
  • SBOM is essentially the ingredient list for a software product allowing the consumer to understand and manage the associated risks. Not only do our scans produces SBOMs but they can be imported as well. SBOMs are used to maintain compliance with CM-8 Information System Component Inventory.
• Vulnerability Scanning
  • Generating a vulnerability report of both container images, virtual machine files, and source code that map to CVEs (Common Vulnerabilities & Exposures), KEV (Known Exploited Vulnerabilities) and EPSS (Exploit Prediction Scoring System) data. The reports reflect all applicable CVEs, if there are known exploits and the probability of a CVE being exploited.
• Secure Policy Enforcement
  • Create policy (policies) of image(s) and source code to ensure that only authorized software and containers meet ATO requirements.
• DISA STIGs
  • Use DISA STIGs for container images to establish and document configuration settings for images. Container images can be scanned against DISA STIGS in heimdall json format which can be easily converted using MITRE SAF™ into XCCDF and CKL files to import within STIG Viewer.
• Plan of Action & Milestones (POA&M)
  • Using policies, gates, mappings and allowlists the POA&M is now enforced with dates to ensure compliance.
• CI/CD Gate Checks
  • Use CI/CD pipelines to not only automate deployment but to ensure your security posture requirements are met each time, every time. Gates can be configured to only allow certain packages installed or be denied if there is a known exploit in a vulnerability.
• Role Based Access Controls (RBAC)
  • Robust role based access controls using least-privilege and need-to-know.
• Kubernetes Runtime Inventory
  • Always know what images are running in your kubernetes clusters and ensure they meet organizational requirements for vulnerability and policy compliance.
• Kubernetes Admission Controller
  • Ensure that all container images meet policy before deployment into production.

The links below show how Anchore Enterprise helps maintain a secure posture with policy mappings to regulatory requirements.

Policy Mappings

NIST 800-53

NIST 800-190

FedRAMP

CIS

DoD

1.1.1 - POA&M

This guide provides examples of how to setup a policy gate to enforce development teams to comply with organizational Plan of Actions & Milestones (POA&M).

The POA&M Challenge

POA&Ms can easily become an administrative nightmare to track, maintain and update. With Anchore Enterprise, POA&Ms can now be done via code configuring CI/CD policy gates that enforce compliance.

POA&M Solution

Generate an Enforceable POA&M Using Policy as Code

The example is shown using a policy from scratch but these directions could be used to add to an existing policy.

1. Create a new policy

   

2. Name and describe your policy, then click save

   

3. Now we will edit the default rule, by clicking edit:

   

4. From here we will configure a rule:

   

   1. Name the rule: RA-5 Vulnerability Monitoring & Scanning
   2. Gate: Vulnerabilities
   3. Trigger: Package
   4. package type: all
   5. severity comparison: >=
   6. severity: unknown
   7. fix available: true

   Scroll down to the bottom and click the action of STOP and click Save and Close.

   

5. Next, we will make an Allowlists for the item we want to POA&M by editing a default Allowlist or adding a New Allowlist:

   

6. Now we will edit the Allowlist:

   

   1. Name the Allowlist: POA&M
   2. Gate: Vulnerabilities
   3. CVE/Vulnerability Identifier: CVE-2025-66293
   4. Package: libpng16-16t64

   Note: Another way to get the CVE and Package information is to obtain the Trigger ID on the Policy Compliance Tab which is CVE ID+package as seen in image below:

   

7. We have a rule and an Allowlist but we want to make this a POA&M item that expires so lets make an expiration by clicking on the calendar:

   

8. A calendar will pop-up and you can select a date or or a time frame of days, weeks or months:

   

9. Next we will make a mapping to limit where this specific POA&M or Allowlist is applied by clicking Mappings, Container Images and Edit:

   

10. Next we will associate a Registry, Repository and Tag with the POA&M Allowlist we just made.

    

    1. Name the Mapping: nginx-libpng
    2. Registry: nginx-libpng
    3. Repository: nginx
    4. Tag: *

    Note: Wildcards “*” can be used for Registry, Repository, and Tag

11. Our POA&M via an Allowlist with an expiration has been created. Let’s validate:

    

    1. Toggle on Go
    2. Show Allowlisted Entries
    3. The TriggerID matches what was put in the Allowlist

You have now created a POA&M enforced by code.

1.1.2 - STIG

This guide provides examples of how to scan a container with DISA STIGs and import the data into Heimdall for a visualization or STIGViewer to create a checklist to provide as an ATO artifact.

This guide requires the dependencies located here to be installed along with the dependency below.

SAF CLI - Install Docs

Once these dependencies are installed, the STIG profiles are written as indicated in the here link and a STIG evaluation has been completed, you are ready to begin.

We will assume that the output of the scan is located in our working directory for the examples below and the STIG --stig-output-dir was saved as results.json like the example below:

anchorectl image add registry.access.redhat.com/ubi9/ubi:latest --stig --stig-profile ./rhel9/rhel9.tar.gz --stig-output-dir results.json

Work with Heimdall

1. The native format for STIG output in Anchore Enterprise is OASIS Heimdall Data Format (OHDF) and can be easily uploaded to heimdall-lite.mitre.org

2. From here, you can upload the results.json file and obtain charts and a map of the NIST 800-53 controls like the images below:

   

   

3. You can easily filter what passed, failed, not reviewed and not applicable. The data can be exported as a DISA Checklist or as XCCDF Results as indicated in the picture below:

   

4. The data can be imported back into STIGViewer to audit a checklist as indicated in Step 4 under Work with STIGViewer.

Work with STIGViewer

1. With safcli installed run the following command to convert the results.json to XCCDF:

saf convert hdf2xccdf -i results.json -o xccdf-results.xml

2. Now we want to convert the same results.json to a ckl file:

saf convert hdf2ckl -i results.json -o ubi9-check.ckl

3. Let’s open STIGViewer and import the results-xccdf.xml file we created in step 1.

4. Now we can click the Home Icon and load our checklist:

   1. Click the hamburger menu
   2. Click Import V2 Checklist and upload ubi9-check.ckl

5. The container STIG checklist can now be saved once the findings as either Open, Not a Finding, Not Applicable and submitted with the applicable Body of Evidence (BOE) documentation.

   

You have now STIG’d a container image and created a checklist.

1.2 - Create & Store SBOMs

This guide provides a quick start for creating, viewing, and storing Software Bill of Materials (SBOMs) in Anchore Enterprise.

Understand SBOM Basics and Use Cases

Supported Industry-Standard Formats

Anchore Enterprise supports the following industry-standard SBOM formats:

Anchore Enterprise also supports the below rich/analysis document format for creating standard SBOMs.

Meet NTIA Requirements

Anchore-generated SBOMs adhere to the minimum required elements defined by the U.S. National Telecommunications and Information Administration (NTIA):

• Data Fields: Supplier name, component name, version, unique identifier (e.g., purl), and dependency relationship.
• Automation: Support for automated generation and updates.
• Practices & Processes: Covers frequency of generation, depth of component coverage, and accessibility.

Create SBOMs

Anchore Enterprise can create SBOMs from container images or directly from a filesystem artifact.

Create and Store SBOM from a Container Image

Anchore Enterprise uses its component analysis capabilities to inspect a container image and create a comprehensive SBOM.

Create and Store via UI

1. Add Image

   In the Images tab, click Analyze Tag. You can either enter the Docker pull string for the container image you want to analyze or provide the registry, repository, and tag details in their respective fields. To learn more about adding a registry, see this guide.

   

2. Analyze Image

   After the image is added, Anchore Enterprise automatically analyzes it and generates an SBOM as part of the analysis process.

   

3. View SBOM

   To view the SBOM, go to the Images tab and open the image’s detail view. Select the image tag, then navigate to the Content tab on the tag report page. Here, you can browse the SBOM components organized by content type. If you need to download the SBOM, an export/download icon is available in the upper-right corner of the page.

   

4. Download the SBOM

   On the Images tab, select the repository or registry that contains the image for which you want to download the SBOM. This opens a page listing all available image tags.

   Click the tag of interest, then look to the upper-right corner of the screen for the Download icon. From the dropdown menu, choose your preferred SBOM format and click the Download icon to begin the download.

   

Create and Store via AnchoreCTL

Use the anchorectl command-line utility to generate an SBOM for a container image.

anchorectl image add <image_tag_or_digest>

Once the image analysis is completed, you can view the generated SBOM via anchorectl using:

anchorectl image sbom <image_tag_or_digest> -o json | jq .

Create and Store SBOM from a Filesystem (e.g. source code repository)

Create an SBOM from a local directory or set of files which is useful for codebases or non-containerized artifacts involves two steps.

1. Create the SBOM

You can create the SBOM by pointing anchorectl to the filesystem folder and running:

anchorectl syft <pathtosourcecode > > <name.json > 

This command will create an SBOM ready for upload to Anchore Enterprise.

2. Store the SBOM:

Once the SBOM is created, upload it to Anchore Enterprise for analysis using:

cat <sbomPATH.json > | anchorectl image add <image:tag > --from - 

Download SBOM via Anchorectl

To download an SBOM that was added as an image, run

anchorectl image sbom <imageSHA > -o <format >

Where format is the SBOM output format you want to download.

Create and Store SBOMs as Imported SBOMs Using AnchoreCTL

You can also create an SBOM from a filesystem and manage it in Anchore Enterprise.

To do this, point anchorectl to the folder containing your source code:

anchorectl sbom add --from <pathtosourcecode > --name <mytestImage> --version $(date -u +%Y%m%d%H%M%S)

This command creates an SBOM and stores it under the Imported SBOMs section of the UI. You can view and download this SBOM by navigating to that section of the UI.

1.3 - Customize the Anchore Enterprise UI

When managing a complex security platform like Anchore Enterprise, communication and accessibility are key. Whether you’re alerting your security and development teams to upcoming maintenance or providing quick access to API documentation, the ability to customize your Anchore Enterprise Deployment makes for a better user experience, that is tailored to your organization and use case.

These customizations are outlined below and can be easily made through the Web UI System Configuration or programmatically via Helm values or Manual Config. Let’s run through what and how you can configure these.

Custom Message

A Custom Message can be displayed on the Anchore Enterprise Client Web UI login view. You can specify a title and a message, both of which support Markdown formatting with any HTML tags removed.

Below is an example of a custom message title with a handy message below.

Recommendation: This can be a useful place to display messages, such as Legal Disclaimers. You can utilize Unicode characters, such as emojis, to help draw attention if required.

Configuration: Edit the config-ui.yaml file under the key ‘custom_message’ and if you are using Helm tweak your values for anchoreConfig.ui.custom_message. Below is an example yaml configuration:

custom_message:
  title: "Custom message"
  message: "This is a handy custom message you can set"

Custom Banners

Custom Banners can be displayed on the Anchore Enterprise Client Web UI across the top and/or bottom of the view. Each banner can have its own text, display mode (always, or login-only, where the banner is only displayed on the login view), as well as an optional background color and text color.

Below is an example of a top banner with always display mode, green background with white text ‘🚨🚨 ENVIRONMENT: DEMO 🚨🚨’

Recommendation: This can be a useful place to signpost users towards gaining access or displaying suitable messages, such as an upcoming maintenance window. You can utilize Unicode characters, such as emojis, to help draw attention if required.

Configuration: You can simply configure your Custom Banner via the Web UI. Alternatively, edit the config-ui.yaml file under the key ‘banners’ and if you are using Helm tweak your values for anchoreConfig.ui.banners. Below is an example yaml configuration:

banners:
  top:
    text: "🚨🚨 ENVIRONMENT: DEMO 🚨🚨"
    text_color: "white"
    background_color: "#32a883"
    display: "always"
  bottom:
    text: "Here is an example login only banner"
    text_color: "white"
    background_color: "#1e6ee6"
    display: "login-only"

Custom Links

Custom links can be displayed on the Anchore Enterprise Client Web UI on the login page and also within the system dropdown menu (top-right in the main view). You can specify a title and up to 10 links with their own titles and URIs. This feature is only enabled if a main title and at least one link and associated title are provided. HTML tags will be removed.

An example below shows how the custom links section on mouse click/hover can be expanded on both the login page:

and the system dropdown menu:

Recommendation: This might be a useful place to link to your deployments copies of AnchoreCTL for the distributions used in your organisation (Windows, Linux, MacOS). This allows users to quickly find and download AnchoreCTL, and importantly, it will download the latest compatible version of AnchoreCTL. Developers also find having links to the Anchore Enterprise Swagger API docs useful.

Configuration: You can simply configure your Custom Links via the Web UI. Alternatively, edit the config-ui.yaml file under the key ‘custom_links’ and if you are using Helm, tweak your values under anchoreConfig.ui.custom_links. Below is an example Helm yaml configuration:

custom_links:
  title: "Internal Resources"
  links:
  - title: "Download AnchoreCTL Linux AMD64"
    uri: "/v2/system/anchorectl?operating_system=linux&architecture=amd64"
  - title: "API - SwaggerUI"
    uri: "/swagger/"
  - title: "API - GraphiQL"
    uri: "/v2/reports/graphql"
  - title: "Integration - Gitlab"
    uri: "https://gitlab.anchoredemo.com/"

Configuration Changes via the Web UI

Users with an Administrator role can configure Custom Message, Custom Banners and Custom Links directly through the Anchore Enterprise Client Web UI by navigating to System > Configuration.

You can make these changes, without the need to change Helm or application values requiring a redeployment of Anchore Enterprise. However, configuring these custom elements within the Web UI, only works if you have NOT already defined the relevant custom values via config-ui.yaml, Helm values or environment variables.

The Web UI offers a helpful WYSIWYG editor allowing you to make changes instantly. Once you click ‘apply’ and then click ‘save’ on the configuration, refresh the page to see your custom changes. The example below shows adding a Top Custom Banner that has its display mode set to always appear.

1.4 - Evaluate SBOMs Using Policies

This guide provides an example of how to scan an SBOM of a filesystem generated with AnchoreCTL.

1. Create a new SBOM policy mapping:

   

   1. Within Policies navigate to Mappings
   2. Select SBOMs tab
   3. Click Let’s add a policy first!

2. Now let’s name a rule set that maps to SBOMs which we will name: sbom-demo

   

3. This will prompt us to make a rule set configuration:

   

   1. Gate: vulnerabilities
   2. Trigger: package
   3. package type: all
   4. severity comparison: >=
   5. severity: medium
   6. fix available: true

   Scroll down to the bottom and click the red STOP button.

   

   It will now look like this and can you can save the policy:

   

   1. Click Save 1 new rule, and Close

4. We have a rule set but now we need to make a rule map to SBOMs:

   

   1. Click Mappings
   2. Click SBOMs
   3. Click Let’s add one!

5. Now we will map the ruleset to SBOMs by giving it a name, the Rule Sets of ‘sbom-demo’ is applied and we will map this to all SBOM Names and Versions. Click OK when done.

   

   The result will look like this:

   

6. SBOMs can be generated using the commands below. It works for applications, containers, files, filesystems, firmware, libraries, modules and mounted virtual disks. Here are is an example below:

   For the menu:

   anchorectl sbom add --help
   

   To generate a scan of a filesystem:

   anchorectl sbom add --from /usr/bin --name usr_bin_binaries --version 1.0 --type filesystem
   

7. The SBOM is available via the UI here:

1. Navigate to Imported SBOMs 
2. Click on the user_bin_binaries 1.0 object

8. From here we can see that the SBOM has been analyzed against policy:

1. The Final Action was a STOP due to the policy rule map
2. The mapping is: SBOM Map All and Rule Sets: sbom-demo

You have now mapped a policy to an SBOM.

1.5 - Find Zero-day Vulnerabilities

This page outlines the workflow for locating zero-day vulnerabilities using Anchore Enterprise’s capabilities, most notably UI, reports and API queries, by both package and vulnerability ID.

When a zero-day vulnerability is disclosed, your first response will be to try and understand your exposure: where in your software supply chain are the affected packages and versions used? In such situations, the Common Vulnerabilities and Exposures (CVE) record may not be fully published yet. This means that you might be searching for specific package versions and by vulnerability identifier, such as a GitHub Security Advisory (GHSA) number.

Check Your Feeds

Anchore Enterprise relies on a large number of vulnerability data sources to bring you the most accurate vulnerability matching as possible. It could be that upstream sources already have knowledge of the vulnerability. Your first step should be to quickly check whether Anchore Enterprise has the latest vulnerability dataset.

In environments talking directly to the Anchore Data Service, you can force a feed sync by running the following command as the Anchore Enterprise administrator:

anchorectl feed sync

You can verify the latest feed updates using the following command:

anchorectl feed list

Feed sync status can also be found in the Anchore Enterprise UI under System and Feeds Sync.

Search by Vulnerability ID

If you know the vulnerability ID, which could be either a CVE, GHSA, or other identifier, you can utilize the native reporting capability in Anchore Enterprise.

1. Click the Reports menu item
2. Choose a new report of Artifacts by Vulnerability.
3. Choose the Vulnerability Id filter and enter the appropriate identifier.

For example, if searching for the NGINX IngressNightmare (https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/), you could use the CVE ID or GHSA for coverage:

• GHSA: GHSA-mgvx-rpfc-9mpv
• CVE: CVE-2025-1974

As you preview results, you can toggle the report scope. If you are the administrator you can run the report against all assets across all accounts.

Once you have validated the desired outcome in the report preview, you can opt to Save Report, provide some details, and tick the option to Generate immediately on save.

The report will then be generated in order to provide you results across the SBOMs for all of your assets. Once complete, the results are ready for download.

You now have an understanding of where in your software supply chain this vulnerability can be found. Go remediate!

Search for Affected Packages

Sometimes you won’t have a vulnerability record available because it has not been created or appropriately updated. Another way to assess impact during a zero-day is to search for the specific package or library version known to be vulnerable. Fortunately, this can be done via the Anchore Enterprise API.

Use the Query API to look for specific package versions. In the case of CVE-2025-1974 (GHSA-mgvx-rpfc-9mpv), the impacted packages were k8s.io/ingress-nginx with versions v1.11.0 - 1.11.4.

The following query would be used to look for a particular version:

curl -X 'GET' \
  'https://anchoredemo.com/v2/query/images/by-package?name=k8s.io%2Fingress-nginx&package_type=go&version=v1.11.0' \
  -H 'accept: application/json'

This would yield a response similar to that found below, revealing an impacted asset:

{
  "images": [
    {
      "image": {
        "image_digest": "sha256:4db2297322e827ae13892be1480800471ec83726edea921bd45af0f8ed35e094",
        "image_id": "bcb840ba02d3eb300b1c13876604e4286794e5873eacbb86ba81139e2ad66a86",
        "analyzed_at": "2025-11-18T12:04:27Z",
        "tag_history": [
          {
            "registry": "registry.k8s.io",
            "repo": "ingress-nginx/controller",
            "tag": "v1.11.0",
            "full_tag": "registry.k8s.io/ingress-nginx/controller:v1.11.0",
            "tag_detected_at": "2025-11-18T11:50:03Z"
          }
        ]
      },
      "packages": [
        {
          "name": "k8s.io/ingress-nginx",
          "version": "v1.11.0",
          "type": "go"
        }
      ]
    }
  ],
  "page": "1",
  "returned_count": 1,
  "total_count": 1
}

With this information, you can now remediate the impacted asset!

1.6 - Identify & Evaluate Images in Kubernetes Clusters

Summary

This quickstart page outlines how Anchore Enterprise integrates directly with Kubernetes environments to support continuous security and operational assurance. By connecting the Kubernetes Inventory Agent and running it in your cluster, Anchore Enterprise collects a real-time software inventory of running workloads, aligning containerized operations with vulnerability detection, configuration assessment, and policy controls.

As organizations scale Kubernetes deployments, Anchore Enterprise enables continuous monitoring of runtime images, automated policy evaluation, and actionable reporting to strengthen workload hardening and operational compliance. Through runtime inventory and policy enforcement, teams can standardize security across clusters, surface risk early, and ensure that live container images meet organizational and regulatory requirements.

Prerequisites

• Anchore Enterprise deployed and accessible.
• kubectl configured for your target Kubernetes cluster.
• Cluster access with sufficient privileges to deploy agents.
• Helm (optional, for easier deployment of the agent).

Connect the Kubernetes Inventory Agent

The Anchore Kubernetes Inventory Agent gathers information about running images and resources via an agent running inside your cluster.

To deploy the agent and begin monitoring your cluster;

1. Add Anchore’s Helm repository:

helm repo add anchore https://charts.anchore.io
helm repo update

2. Create a native user in Anchore Enterprise that uses the inventory-agent role permissions.

3. Build your values.yaml file by setting your username, password, Anchore Enterprise URL and cluster name:

k8sInventory:
  # Path should not be changed, cluster value is used to tell Anchore Enterprise which cluster this inventory is coming from
  kubeconfig:
    cluster: <unique-name-for-your-cluster>
  
  anchore:
    url: <URL for your deployment>
    # Note: recommend using the inventory-agent role
    user: <user>
    password: <password>

4. Install the Kubernetes Inventory Agent using Helm and the values file we just built:

helm install <release> -f <values.yaml> anchore/k8s-inventory

After deployment, verify the pod is up and running:

kubectl get pods -n anchore

The agent will automatically:

• Discover all running pods and containers.
• Collect image metadata and digest information.
• Submit inventory to Anchore Enterprise.

Verification & Best Practices

Once your cluster is connected, verify agent connectivity by checking the logs to confirm it’s reporting inventory and status as expected:

kubectl logs -n anchore <inventory-agent-pod>

View the Vulnerability Results of Running Images

1. Log in to the Anchore Enterprise UI.

2. Navigate to the Kubernetes tab to access your running cluster data. Be aware that you may need to wait for a brief period for discovered data to appear.

3. Select your desired cluster. From here, You will get a real-time snapshot of what images are running and also be able to view:

• The complete list of the running container images currently in use.

• Vulnerabilities associated with each image, mapped to known CVEs.

• CVSS scoring, severity distribution, and other helpful risk indicators so you can quickly spot anything that needs attention.

  

View and Enforce Policy Evaluations

Anchore Enterprise also lets you apply and enforce security policies directly against your running images—so you’re not just observing problems, you’re controlling them.

1. In the UI, go to Policies → Evaluation.

2. Choose the policy bundle you want to assess or enforce (for example, minimum CVSS severity thresholds, banned packages, or disallowed images).

3. Review the results, including:

• Pass/Fail status for each image or cluster.
• Detailed reasoning for policy violations, helping to guide remediation.

4. Optionally - if you want to take things a step further, configure notifications or enforcement actions (e.g., blocking deployment of non-compliant workloads) to keep risky images out of production.

1.7 - Identify and Remediate Vulnerabilities

This page outlines the workflow for identifying and remediating security vulnerabilities using a number of different Anchore Enterprise platform features which combined provide a layered approach for augmenting your organization’s security posture.

Analyze and View Security Vulnerabilities on an Asset

In order to remediate a given vulnerability, we must first identify whether one exists in the underlying asset through analysis.

The asset in this case could represent a container image which can be analyzed either through the UI or anchorectl — both of which are described in detail below. Once analysis is complete, we can then view any identified vulnerabilities to start the process of remediation.

Through the UI

• UI Analysis and Viewing Vulnerabilities

Through anchorectl

• anchorectl Analysis and Viewing Vulnerabilities

Flag Vulnerabilities for Remediation Using VEX Annotations

Anchore Enterprise leverages use of VEX (Vulnerability Exploitability eXchange) annotations that allows your organization to add context to identified vulnerabilities which helps prioritize remediation efforts by assessing real-world risk.

1. Click the Images menu item.
2. Select an image which has been analyzed with identified vulnerabilities.
3. Click the Vulnerabilities tab.
4. Under Annotation Status (VEX) select your intended status for the target vulnerabilities (i.e., Not Affected, Affected, Fixed, or Under Investigation).
5. Click the caption box directly to the right to add annotation details in the Vulnerability Exploit Statement. Annotation details would include information such as how an identified vulnerability would be remediated (via an Action Statement).

For example, if you wanted to add an annotation for all CRITICAL vulnerabilities which meets the below criteria:

• Package Name: java/jdk
• Version: 1.8.0_452-b09
• Annotation Status: Affected

These vulnerabilities have now been annotated accordingly per their level of severity and can be prioritized for remediation per the Action Statement.

Create a Report on Images With Annotated Vulnerabilities

Anchore Enterprise features a robust reporting service that allows your organization to create, manage, and save reports using pre-defined or custom templates for key stakeholder awareness and remediation.

1. Click the Reports menu item.

2. Choose a New Report of Images Affected by Vulnerability.

3. Choose the Vulnerability Severities and Vulnerability Annotation Status filters and select the appropriate filter patterns.

For example, if you wanted to create a report with annotated vulnerabilities which meets the below criteria:

• Vulnerability Severities: Critical
• Vulnerability Annotation Status: affected

Once you’ve set the desired filter patterns, you can then click on Preview Results which will return a listing of all images with Critical vulnerabilities that have been annotated as affected.

The Account Scope is a default filter/option which controls whether the report should return global results encompassing all accounts, or if the results should be limited to only the local account. If you’re running the report as the admin user or as a user within the admin account, you’ll have the option to select either Local or Global as an Account Scope selection.

Once you’ve validated the Preview Results, you can either click on Download Full Report which will allow you to download the report in CSV (default) or JSON format or you can opt to click on Save Report.

If saving the report, you should specify a report Name and optional Description. Additionally, you should also set the frequency (i.e., Daily, Weekly, or Monthly), day of the week, and time that report generation should occur. You also have the option to toggle Generate immediately on save which will generate a report for immediate download upon clicking the Save button.

If you toggled Generate immediately on save, the saved report will be available for download in CSV (default) or JSON format and can be accessed by clicking on the Saved Reports tab.

anchorectl can also be utilized to generate a list of images with annotated vulnerabilities that require remediation, providing you have the image identifier from anchorectl image list, it allows you to filter affected images by both Vulnerability Severity and Vulnerability Annotation Status (limited to Vulnerability Annotation Status only).

Syntax:

anchorectl image vulnerabilities <image ID, digest, or name:tag> --annotations <not affected, affected, fixed, under investigation>

With example, for all vulnerabilities annotated as Affected:

anchorectl image vulnerabilities docker.io/image/test:mytest --annotations affected
 ✔ Fetched vulnerabilities                   [2 vulnerabilities]                                                                                         docker.io/image/test:mytest 
┌────────────────┬──────────┬──────────┬───────────────┬───────────────────┬──────────────┬────────┼────────────┬───────┬────────────────┬─────────────────────────────────────────────────┬───────────────────┐
│ ID             │ SEVERITY │ NAME     │ VERSION       │ FIX               │ WILL NOT FIX │ TYPE   │ FEED GROUP │ KEV   │ CVES           │ URL                                             │ ANNOTATION STATUS │
├────────────────┼──────────┼──────────┼───────────────┼───────────────────┼──────────────┼────────┼────────────┼───────┼────────────────┼─────────────────────────────────────────────────┼───────────────────┤
│ CVE-2024-56171 │ Critical │ java/jdk │ 1.8.0_452-b09 │ 1.8.0_461,8.0.461 │ false        │ binary │ nvd        │ false │ CVE-2024-56171 │ [https://nvd.nist.gov/vuln/detail/CVE-2024-56171](https://nvd.nist.gov/vuln/detail/CVE-2024-56171) │ affected          │
│ CVE-2024-40896 │ Critical │ java/jdk │ 1.8.0_452-b09 │ 1.8.0_461,8.0.461 │ false        │ binary │ nvd        │ false │ CVE-2024-40896 │ [https://nvd.nist.gov/vuln/detail/CVE-2024-40896](https://nvd.nist.gov/vuln/detail/CVE-2024-40896) │ affected          │
└────────────────┴──────────┴──────────┴───────────────┴───────────────────┴──────────────┴────────┼────────────┴───────┴────────────────┴─────────────────────────────────────────────────┴───────────────────┘

Note: The -o, --output <string> flag can also be supplied to output the results in any one of the below allowed formats. The default is text.

Allowed Formats: text, json, json-raw, csv, cyclonedx-json, or cyclonedx-xml

anchorectl image vulnerabilities docker.io/image/test:mytest --annotations affected -o csv

Export and Download a VEX Document

Anchore Enterprise can be used to generate a VEX (Vulnerability Exploitability eXchange) document for review with key stakeholders for security state awareness.

1. Click the Images menu item.

2. Select an image which has been analyzed where annotations have previously been added.

3. Click the Export button above the Annotation Status (VEX) column.

4. From the Export dialog box, select the VEX radio button and desired export format (i.e. CycloneDX JSON, CycloneDX XML, or OpenVEX) from the drop-down box.

5. Click the Download button to download the VEX document.

Track Changes to Vulnerabilities

Anchore Enterprise features the ability to send notifications if the vulnerabilities within an image change.

For instance, changes made by the upstream providers of vulnerability data may cause CVEs to be added, removed, or modified. From a vulnerability management standpoint, it’s important to track such changes as a CVE severity level could be upgraded prompting the need to add a VEX annotation for vulnerability remediation.

Tracking changes to vulnerabilities is a core function of the Vulnerability Update subscription as described below.

Vulnerability Update Subscription

anchorectl is the primary mechanism for activating/deactivating the subscription (deactivated by default).

Managing Subscriptions

Once the subscription is activated, notifications can then be configured to notify upon changes or updates to vulnerabilities.

Notifications

Use Policies for Vulnerability Management

Anchore Enterprise features a sophisticated policy engine that allows your organization to perform evaluations against source repositories or container images using a set of rules.

1. Click the Policies menu item.

2. Click on Create New Policy or click on Edit to modify the existing Active policy.

3. Click on Add New Rule Set and select either Source Repositories or Container Images from the drop-down box.

4. Provide a Name and Description for the ruleset and proceed to select and configure the ruleset Gate and Trigger.

5. Select an action (i.e., STOP, WARN, or GO) which should be associated with the ruleset.

For example, if you wanted to create a ruleset associated with the existing Anchore Enterprise - Secure policy to detect all CRITICAL vulnerabilities:

• Ruleset Type: Container Images
• Gate: vulnerabilities
• Trigger: package

Parameters:

• package type (Required): all
• severity: critical
• severity comparison: =
• annotation status: affected

Action (on policy evaluation): STOP

6. Click on the Mappings tab followed by the Container Images tab.

7. Click on Edit for the default container Mapping Name.

8. From the Edit Container Image Mapping dialog box, add the newly created ruleset to the Rule Sets list by selecting it from the drop-down menu. Once added, click OK.

9. Click the Images menu item and select an image which has been analyzed where annotations have previously been added.

10. Click the Policy Compliance tab. Check to make sure the correct policy and newly added ruleset are listed next to Policy and under Rule Sets.

11. Type in the name of the newly added ruleset in the Search box to filter on just the vulnerabilities that match the ruleset.

12. Under the Gate Action column, verify the configured ruleset action is reflected.

13. Under the Policy Rule column, verify the name of the ruleset is reflected.

14. Verify that the Policy Result in the upper right-hand side reflects the evaluation (i.e., PASSED or FAILED).

1.8 - Best Practices for Using Anchore Enterprise in CI

This quickstart will walk you through the typical steps required to integrate Anchore Enterprise policy checks and vulnerability scans into your CI jobs.

Before You Start

In order to start instrumenting your CI pipelines with AnchoreCTL, you need to ensure the following:

1. You have access to a fully operational Anchore Enterprise deployment, with a provisioned account/tenant for your use.
2. The Anchore Enterprise API should be accessible from your CI runner(s).
3. Your Anchore Enterprise deployment and your CI runner(s) can reach any relevant container registries from which to source images.

Get AnchoreCTL

Anchore Enterprise can be integrated into various CI systems in a vendor-agnostic manner using the AnchoreCTL tool. AnchoreCTL is a golang binary which can be used to interact with an Anchore Enterprise deployment. To ensure compatibility and simplify runner configuration, AnchoreCTL should always be version-aligned with your Anchore Enterprise deployment.

A recommended practice is to fetch AnchoreCTL directly from your Anchore Enterprise installation during the CI job. This guarantees the client version matches the server. Insert a command such as the following into your job before you want to conduct a scan and evaluation:

curl -X GET "https://my-anchore.example.com/v2/system/anchorectl?operating_system=linux&architecture=amd64" -H "accept: */*" | tar -zx anchorectl

For more details, see Deploying AnchoreCTL.

Access via API Keys

AnchoreCTL can talk to an Anchore Enterprise deployment using username and password for authentication, or via API keys. The latter is recommended and otherwise commonly used if you are signing into Anchore Enterprise via SSO.

Configure an API key so your job can talk to the Anchore Enterprise API, see Using API keys for instructions.

Add Environment Variables

You’ll typically want to store AnchoreCTL configuration such as connection details in environment variables for your CI job. At a minimum, you will want to set or configure the following in your CI job specification:

• ANCHORECTL_URL
• ANCHORECTL_USERNAME
• ANCHORECTL_PASSWORD
• ANCHORECTL_UI_URL

The ANCHORECTL_UI_URL variable ensures that HTML outputs from anchorectl commands will contain deep links to the Anchore Enterprise UI for assets.

Alternatively, you could also construct an AnchoreCTL configuration file and use that. See Configuring AnchoreCTL for further details on possible parameters.

Choose Your Method of Analysis

Before you start creating a workflow in CI, you will need to determine which method of analysis you wish to use. Anchore Enterprise supports two primary modes of operation for image analysis in CI pipelines: Distributed Analysis or Centralized Analysis.

Both modes work with any CI/CD system as long as the AnchoreCTL binary can be installed and run, and you can access the Enterprise APIs directly.

Distributed Analysis (Recommended)

In Distributed Analysis, SBOM generation happens locally on the runner and is then sent to Anchore Enterprise for evaluation.

It is the recommended approach because it offers maximum flexibility in resourcing. You can potentially reduce the time to generate an SBOM by customising your anchoreCTL configuration and providing more CPU and fast I/O to your pipeline runners.

To use distributed analysis, construct your CI job to use AnchoreCTL with the --from parameter, for example:

anchorectl image add <DOCKER_USERNAME>/getting-started-todo-app --from [docker, registry] --wait

This will cause AnchoreCTL in your job to download the image from the given registry and generate the SBOM locally on the runner.

Centralized Analysis

In Centralized Analysis, the AnchoreCTL command is used to ask your Anchore Enterprise deployment to download and analyzes the image content. This is necessary if you require the malware scanning service to unpack and scan container layers.

To use centralized analysis, omit the --from parameter, for example:

anchorectl image add ghcr.io/place/thing:v0.1.0  --wait

Centralized analysis will have a different performance profile for SBOM generation, since you may not have direct control over resourcing of your Anchore Enterprise shared service.

Construct Your Workflow

You’re now ready to start putting AnchoreCTL commands into your CI jobs. For a container-focused use-case, you will generally look to construct a job which does the following:

1. Builds a container image and pushes to a staging registry
2. Downloads AnchoreCTL from Anchore Enterprise
3. Generates an SBOM of the container image
4. Conducts a vulnerability analysis, returning results
5. Conducts a policy check, returning the evaluation result

The sequence of commands will look something like this (simplified):

# Build a docker image for your project
docker build -t <DOCKER_USERNAME>/getting-started-todo-app . 

# Push the image to a staging registry (you can also skip this step by using --from docker in the next command)
docker push <DOCKER_USERNAME>/getting-started-todo-app

# Download AnchoreCTL
curl -X GET "https://my-anchore.example.com/v2/system/anchorectl?operating_system=linux&architecture=amd64" -H "accept: */*" | tar -zx anchorectl

# Generate the SBOM for the image (in this example, distributed) and wait for analysis to complete
anchorectl image add <DOCKER_USERNAME>/getting-started-todo-app --from [docker, registry] --wait

# Get vulnerability results for the image
anchorectl image vulns <DOCKER_USERNAME>/getting-started-todo-app

# Get policy evaluation results for the image
anchorectl image check <DOCKER_USERNAME>/getting-started-todo-app

Based on the results returned by Anchore Enterprise, you can then decide what additional steps to take in your CI job.

Customize Artifacts

The various anchorectl commands have various options for outputs, selected using the -o parameter. You might opt to return results as text, machine-readable JSON, csv or more! This material can be useful if you intended to have additional steps in your job work based on results, rather than just pass or fail.

Furthermore, AnchoreCTL 5.26+ and higher now includes an HTML format for vulnerability and policy check reports, for example:

anchorectl image check ghcr.io/place/thing:v0.1.0 --from [docker, registry] --fail-on-policy-error -o html > policy.html

Also with one-time-scan option:

anchorectl image one-time-scan ghcr.io/place/thing:v0.1.0 --from [docker, registry] --fail-on-policy-error -o html > onetime.html

If you set ANCHORECTL_UI_URL or ui-url in your AnchoreCTL configuration and you’re not using one-time-scan, you’ll get a handy link in the HTML which will take you straight into the Anchore Enterprise UI for that SBOM artifact.

Optimize Performance

With a basic workflow constructed, you might want to try and optimise for SBOM-generation, vuln scan and policy check times.

If you are using Distributed Analysis, you will want to ensure that your CI runners have fast CPU and I/O, to optimise the cataloging and SBOM generation process used by AnchoreCTL.

If your container images contain a large number of files and packages, you may be able to significantly reduce SBOM generation time by enabling parallelism. AnchoreCTL (v5.18+) can run catalogers in parallel rather than sequentially.

You can configure the number of concurrent worker processes using the ANCHORECTL_SYFT_PARALLELISM environment variable (or set in anchorectl.yaml). For optimal performance, try aligning the number of workers with your runner’s available vCPUs.

# Example for an 8 vCPU runner
ANCHORECTL_SYFT_PARALLELISM=8

See Configuring AnchoreCTL for further information.

Use Policy Checks

Rather than just reviewing a raw list of vulnerabilities, which can be daunting and lack context, it is a best practice to use the Anchore Enforce policy engine to conduct compliance checks.

Policy-driven gating provides developers with precise, actionable feedback based on your own organizational policy or industry standards (e.g., NIST 800-53, CIS).

Use the following command to evaluate an image against your default policy and fail the CI job if it does not meet compliance requirements. You might add this to the end of your sequence of commands:

anchorectl image check <DOCKER_USERNAME>/getting-started-todo-app --detail -f

The --detail flag can be useful for developers, as it provides the specific gate, trigger, and remediation recommendations needed to resolve policy violations.

The -f flag tells the command to give a return code of 1 in the result of the policy check being marked as fail. This can allow you to fail or break a workflow on this step.

If you wish to store output as artifacts, you can use the -o parameter and save accordingly.

Switch to Stateless Scans (One-Time Scan)

By default, adding an image to Anchore Enterprise for analysis means that the SBOM will be stored persistently in the deployment, until archived or deleted. This could mean your deployment stores more SBOMs than necessary; you may not care whether an SBOM for a CI build is persisted or not.

Anchore Enterprise has a featured called One Time Scan which can be used to deliver fast feedback in your pipeline jobs, namely vulnerability and policy analysis results, but doing so without persisting the SBOM in your Anchore Enterprise deployment. Use the anchorectl image one-time-scan command to conduct analysis in this mode. As with the anchorectl image check command, you can also pass a flag to fail the pipeline job if the policy analysis fails. For example:

anchorectl image one-time-scan <DOCKER_USERNAME>/getting-started-todo-app --from [docker, registry] --fail-on-policy-error

By default, this command will return a policy check. Using the -o json parameter, JSON results for policy check, vulnerability scan and the SBOM will be returned. These results can then be machine parsed by the CI job to determine actions.

See One Time Scan for further information.

Conclusion

You’ve now fully instrumented your pipeline to add hi-fidelity SBOM-based vulnerability and compliance checks to your CI jobs!

2 - Deploying Anchore Enterprise

Anchore Enterprise and its components are delivered as Docker container images which can be deployed as co-located, fully distributed, or anything in-between. Anchore Enterprise can run on a single host or be deployed in a scale out pattern for increased analysis throughput.

To get up and running, jump to the following guides of your choosing:

Anchore Enterprise Container Images

• Requirements
• Docker Compose
• Kubernetes with Helm
• Air-Gapped

Anchore Enterprise Cloud Images

• Cloud Image

AnchoreCTL

• AnchoreCTL

2.1 - Requirements

This section details the general requirements for running Anchore Enterprise. For a conceptual understanding of Anchore Enterprise, please see the Overview topic prior to deploying the software.

Runtime

Anchore Enterprise requires a Docker compatible runtime (version 1.12 or higher) on either AMD or Intel-based amd64 architecture.

Deployment is supported on:

• Docker Compose (only recommended for testing, for example demo or proof-of-concept < 1000 SBOMs)
• Any Kubernetes Certified Service Provider (KSCP) as certified by the Cloud Native Computing Foundation (CNCF) via Helm.
• Any Kubernetes Certified Distribution as certified by the Cloud Native Computing Foundation (CNCF) via Helm.
• Amazon Elastic Container Service (ECS) via Helm.

Resourcing

Use-case and usage patterns will determine the resource requirements for Anchore Enterprise. When deploying via Helm (package manager for Kubernetes), requests and limits are set in the values.yaml file. When deploying via Docker Compose, add reservations and limits into your Docker Compose file. The following recommendations can get you started:

• Requests specify the desired resource amounts for the container, while limits specify the maximum resource amounts the container is allowed. To achieve best QoS (quality-of-service) with Helm deployments, it’s recommended to set requests equal to limits for allocated memory units and to set requests only with no limits set for allocated CPU units.

• It’s not recommended to set less than 1 CPU unit for any container. Less than this could result in unexpected behaviour and should only be used in testing scenarios.

• For the api, catalog, policy, and postgresql service containers, a minimum of 2 CPU units is recommended.

• For Production use with Helm deployments, it’s recommended to set memory units to a minimum of 16G for the analyzer and policy services and 8G for all other services - where requests equals limits for all services. Less than these values could result in OOM errors or containers restarting unexpectedly.

If you intend on using Kubernetes, the default values.yaml found in the Anchore Enterprise Helm Chart provides some resourcing recommendations to get you started.

Database

The only service dependency strictly required by Anchore Enterprise is a PostgreSQL database (17.x or higher) that all services connect to. The database is centralized simply for ease of management and operation. For an architectural overview, go to Anchore Enterprise Architecture.

Anchore Enterprise is database-intensive. Depending on the scale of the deployment, hundreds to thousands of concurrent connections may be required. The PostgreSQL database used for Anchore Enterprise should be dedicated and not co-located with any other applications that use a PostgreSQL backend. Anchore Enterprise requires a readable and writable PostgreSQL endpoint — read replica endpoints are not supported at this time.

Anchore Enterprise uses this database to provide persistent storage for image, policy and analysis data. Database storage requirements are based on the number of SBOMs and how long these need to be stored in the active set (i.e. not archived to analysis archive/s3 or deleted). Each SBOM and its respective packages are indexed in the DB, so SBOM complexity also requires increased database storage. Runtime adds a further requirement here.

As an Anchore Enterprise deployment grows — whether through a larger volume of SBOMs, higher analysis throughput, or longer data retention — the database requires proportionally more storage, CPU, and memory. Plan to scale these resources in step with your deployment’s growth.

Reduce Total Cost of Ownership with an External Object Store

Configuring an external object store can significantly reduce database size and total cost of ownership (TCO) by offloading analysis data to object storage (for example, Amazon S3).

PostgreSQL in Anchore Enterprise Deployments

A PostgreSQL database ships with the default deployment mechanisms for Anchore Enterprise. This is often referred to as the Anchore-managed database. This can be run in a container, as configured in the example Docker Compose file and default Helm values file.

The PostgreSQL database requirement can also be provided as an external service to Anchore Enterprise. PostgreSQL databases, such as Amazon RDS for PostgreSQL, can be used for highly-scalable cloud deployments.

PostgreSQL Requirements for Anchore Enterprise 6.0

As of Anchore Enterprise 6.0, PostgreSQL 17 or higher with the pg_cron extension is required. Be aware of the following changes by deployment type:

• Helm: The Anchore Enterprise 6.0 Helm chart will not include a bundled PostgreSQL chart. The pg_cron extension must be available in your PostgreSQL instance before beginning the Anchore Enterprise 6.x migration. Helm deployments may need to build a custom PostgreSQL 17 image with the pg_cron extension and push it to a container registry accessible by the Kubernetes cluster.
• Docker Compose: Docker Compose deployments will continue to include PostgreSQL. The provided docker-compose YAML file references a Dockerfile that adds the pg_cron extension automatically.
• AECI: AECI deployments will continue to include PostgreSQL.

Network

An Anchore Enterprise deployment requires the following three categories of network access:

• Service Access
  • Connectivity between Anchore Enterprise services, including access to an external database.
• Registry Access
  • Network connectivity, including DNS resolution, to the registries from which Anchore Enterprise needs to download images.
• Anchore Data Service (ADS) Access
  • Anchore Enterprise requires access to the datasets in order to perform analysis and vulnerability matching. See Anchore Enterprise Data Feeds for more information.

Security

Anchore Enterprise is deployed from source repositories or container images that can be run manually using Docker Compose, Kubernetes, or any other supported container platform.

By default, Anchore Enterprise does not require any special permissions. It can be run as an unprivileged container with no access to the underlying Docker host.

Anchore Enterprise can be configured to pull images through the Docker socket. However, this configuration is not recommended, as it grants the Anchore Enterprise container added privileges and may incur a performance impact on the underlying Docker host.

Storage

Anchore Enterprise can be configured to depend on other storage for various artifacts. For full details on storage configuration, see Storage Configuration.

• Configuration volumes: this volume is used to provide persistent storage to the container from which it will read its configuration files, and optionally - certificates. Requirement: Less than 1MB.
• [Optional] Scratch space: this temporary storage volume is recommended but not required. During the analysis of images, Anchore Enterprise downloads and extracts all of the layers required for an image. These layers are extracted and analyzed, after which, the layers and extracted data are deleted. If a temporary storage is not configured, then the container’s/worker node’s ephemeral storage will be used to store temporary files. However, performance is likely be improved by using a dedicated volume. Scratch volumes do not need storage redundancy. For further information see Scratch
• [Optional] Layer cache: another temporary storage volume may also be used for image-layer caching to speed up analysis. This caches image layers for re-use by analyzers when generating an SBOM / analyzing an image. For further information see Layer Caching

• [Optional] Object Storage and Analysis Archiving: Anchore Enterprise stores image analysis data and policy documents as JSON objects. By default these are stored in PostgreSQL. For larger deployments, the active data set can be offloaded to Amazon S3 or an S3-compatible provider, and completed analyses can be moved to a separate archive to reduce database load. Requirement: approximately 10MB per image. For further information, see Object Storage Configuration and Analysis Archive Configuration.

Anchore Enterprise UI

The Anchore Enterprise UI module interfaces with Anchore API using the external API endpoint. The UI requires access to the Anchore database where it creates its own namespace for persistent configuration storage. Additionally, a Redis database deployed and managed by Anchore Enterprise through the supported deployment mechanisms is used to store session information.

• Network
  • Ingress
    • The Anchore Enterprise UI module publishes a web UI service by default on port 3000, however, this port can be remapped.
  • Egress
    • The Anchore Enterprise UI module requires access to three network services at the minimum:
      • External API endpoint (typically port 8228)
      • Redis Database (typically port 6379)
      • PostgreSQL Database (typically port 5432)
• Redis Service
  • Version 7.4.6 or higher

Optimize Your Deployment

Optimizing your Anchore Enterprise deployment on Kubernetes, involves various strategies to enhance performance, reliability, and scalability. Here are some key tips:

• Ensure that your Analyzer, API, Catalog, and Policy service containers have adequate CPU and memory resources. Each service has reference recommendations which can be found in the Anchore Enterprise chart values.yaml.
• Each pod can make between 30 and 100 connections to the database so ensure max_connections is set appropriately (at least 500).
• Integrate with monitoring tools like Prometheus and Grafana to monitor key metrics like CPU, memory usage, analysis times, and feed sync status. You can also Set up alerts for critical thresholds. Follow our guide on Prometheus and Grafana setup Monitoring guides
• For large deployments, it is good practice to Schedule regular vacuuming, indexing, and performance tuning to keep the database running efficiently.
• Layer caching in Docker can significantly speed up the image build process by reusing layers that haven’t changed, reducing build times and improving efficiency. Follow our guide on Layer Caching setup
• Ensure you enable reporting data egress.
• Keep in mind Anchore Enterprise supports tenancy by means of Accounts. We suggest at a minimum creating an account besides the admin account to use for normal Anchore Enterprise tasks.

Next Steps

If you feel you have a solid grasp of the requirements for deploying Anchore Enterprise, we recommend following one of our installation guides.

2.2 - Deploy using Docker Compose

In this topic, you’ll learn how to use Docker Compose to get up and running with a stand-alone Anchore Enterprise deployment.

Before moving further with Anchore Enterprise, it is highly recommended to read the Overview sections to gain a deeper understanding of fundamentals, concepts, and proper usage.

Quicklinks

• Docker Compose File

• (Optional) Prometheus Configuration File for Monitoring. See Enabling Prometheus Monitoring

• (Optional) Swagger UI Nginx Proxy to browse the API with a Swagger UI. See Enabling Swagger UI

Before You Start

The following instructions assume you are using a system running Docker v1.12 or higher, and a version of Docker Compose that supports at least v2 of the docker compose configuration format.

• A stand-alone deployment requires at least 16GB of RAM (32GB+ recommended), and enough disk space available to support the largest container images or source repositories that you intend to analyze. It is recommended to consider three times the largest source repository or container image size. We suggest at least 40GB of disk space, the more the better.
• To access Anchore Enterprise, you need a valid license.yaml file that has been issued to you by Anchore. If you do not have a license yet, visit the Anchore Contact page to request one.
• You need root or sudo access to the system where you will be running docker and deploying Anchore Enterprise, all commands in this document are run as root.

Getting Started

Follow the steps below to get up and running!

Step 1: Check access to images

You’ll need authenticated access to the anchore/enterprise and anchore/enterprise-ui repositories on DockerHub. Anchore Customer Success will provide a Dockerhub PAT (Personal Access Token) for access to images. Login with your Docker PAT to push and pull images from Docker Hub:

docker login -u <your_dockerhub_pat_user> -p <your_dockerhub_pat>

Step 2: Configure & run

Download the Docker Compose File into a working directory where you have also placed the license.yaml file you got from Anchore.

curl https://docs.anchore.com/current/docs/deployment/docker_compose/docker-compose.yaml > docker-compose.yaml
cp <path/to/your/license.yaml> ./license.yaml

Edit the compose file and uncomment the ANCHORE_ADMIN_PASSWORD env var in both the catalog and queue services to a strong password of your choice.

- ANCHORE_ADMIN_PASSWORD=yourstrongpassword

Then start your environment from your working directory:

docker compose up -d

Step 3: Install AnchoreCTL

Next, we’ll install the lightweight Anchore Enterprise client tool, quickly test using the version operation, and set up a few environment variables to allow it to interact with your deployment using the admin password you defined in the previous step.

Run the curl command below to download anchorectl and install it into your /usr/local/bin directory, which should be in your $PATH:

curl -sSfL  https://anchorectl-releases.anchore.io/anchorectl/install.sh  | sh -s -- -b /usr/local/bin v5.27.1

Run the following command to validate that you are now using your newly downloaded version of anchorectl:

anchorectl version

#Output
Application:        anchorectl
Version:            5.27.1
SyftVersion:        v0.97.1
BuildDate:          2023-11-21T22:09:54Z
GitCommit:          f7604438b45f7161c11145999897d4ae3efcb0c8
GitDescription:     v5.27.1
Platform:           linux/amd64
GoVersion:          go1.21.1
Compiler:           gc

After that, the next steps are to simply pass the basic configuration options for anchorectl into the environment variables so that these values can be used to automate:

export ANCHORECTL_URL="http://localhost:8228"
export ANCHORECTL_USERNAME="admin"
export ANCHORECTL_PASSWORD="yourstrongpassword"

Step 4: Verify service availability

After a few minutes (depending on system speed) Anchore Enterprise and Anchore UI services should be up and running, ready to use. You can verify the containers are running with docker compose, as shown in the following example.

docker compose ps

#Output
             Name                           Command                  State               Ports         
-------------------------------------------------------------------------------------------------------
anchorequickstart_analyzer_1          /docker-entrypoint.sh anch ...   Up (healthy)   8228/tcp              
anchorequickstart_anchore-db_1        docker-entrypoint.sh postgres    Up             5432/tcp              
anchorequickstart_api_1               /docker-entrypoint.sh anch ...   Up (healthy)   0.0.0.0:8228->8228/tcp
anchorequickstart_catalog_1           /docker-entrypoint.sh anch ...   Up (healthy)   8228/tcp           
anchorequickstart_data-syncer_1       /docker-entrypoint.sh anch ...   Up (healthy)   0.0.0.0:8778->8228/tcp  
anchorequickstart_notifications_1     /docker-entrypoint.sh anch ...   Up (healthy)   0.0.0.0:8668->8228/tcp
anchorequickstart_policy-engine_1     /docker-entrypoint.sh anch ...   Up (healthy)   8228/tcp              
anchorequickstart_queue_1             /docker-entrypoint.sh anch ...   Up (healthy)   8228/tcp    
anchorequickstart_reports_1           /docker-entrypoint.sh anch ...   Up (healthy)   0.0.0.0:8558->8228/tcp
anchorequickstart_reports_worker_1    /docker-entrypoint.sh anch ...   Up (healthy)   0.0.0.0:55427->8228/tcp
anchorequickstart_ui-redis_1          docker-entrypoint.sh redis ...   Up             6379/tcp              
anchorequickstart_ui_1                /docker-entrypoint.sh node ...   Up             0.0.0.0:3000->3000/tcp

You can then run a command to get the status of the Anchore Enterprise services:

anchorectl system status

#Output
 ✔ Status system
┌─────────────────┬────────────────────┬─────────────────────────────┬──────┬────────────────┬────────────┬──────────────┐
│ SERVICE         │ HOST ID            │ URL                         │ UP   │ STATUS MESSAGE │ DB VERSION │ CODE VERSION │
├─────────────────┼────────────────────┼─────────────────────────────┼──────┼────────────────┼────────────┼──────────────┤
│ analyzer        │ anchore-quickstart │ http://analyzer:8228        │ true │ available      │ 5270       │ 5.27.0       │
│ policy_engine   │ anchore-quickstart │ http://policy-engine:8228   │ true │ available      │ 5270       │ 5.27.0       │
│ apiext          │ anchore-quickstart │ http://api:8228             │ true │ available      │ 5270       │ 5.27.0       │
│ reports         │ anchore-quickstart │ http://reports:8228         │ true │ available      │ 5270       │ 5.27.0       │
│ reports_worker  │ anchore-quickstart │ http://reports-worker:8228  │ true │ available      │ 5270       │ 5.27.0       │
│ data_syncer     │ anchore-quickstart │ http://data-syncer:8228     │ true │ available      | 5270       │ 5.27.0       │
│ simplequeue     │ anchore-quickstart │ http://queue:8228           │ true │ available      │ 5270       │ 5.27.0       │
│ notifications   │ anchore-quickstart │ http://notifications:8228   │ true │ available      │ 5270       │ 5.27.0       │
│ catalog         │ anchore-quickstart │ http://catalog:8228         │ true │ available      │ 5270       │ 5.27.0       │
└─────────────────┴────────────────────┴─────────────────────────────┴──────┴────────────────┴────────────┴──────────────┘

Note: The first time you run Anchore Enterprise, vulnerability data will sync to the system in a few minutes. For the best experience, wait until the core vulnerability data feeds have completed before proceeding.
You can check the status of your feed sync using AnchoreCTL:

anchorectl feed list

#Output
 ✔ List feed                                                                                                                                                                                                                                   
┌────────────────────────────────┬──────────────────────────────────────┬─────────┬─────────────────────────┬──────────────┐
│ FEED                           │ GROUP                                │ ENABLED │ DATA SERVICE BUILD TIME │ RECORD COUNT │
├────────────────────────────────┼──────────────────────────────────────┼─────────┼─────────────────────────┼──────────────┤
│ ClamAV Malware Database        │ clamav_db                            │ true    │ 2026-03-08T12:07:30Z    │ 1            │
│ Vulnerabilities                │ alpine:3.10                          │ true    │ 2026-03-08T06:16:38Z    │ 2355         │
│ Vulnerabilities                │ alpine:3.11                          │ true    │ 2026-03-08T06:16:38Z    │ 2693         │
│ Vulnerabilities                │ alpine:3.12                          │ true    │ 2026-03-08T06:16:38Z    │ 3227         │
│ Vulnerabilities                │ alpine:3.13                          │ true    │ 2026-03-08T06:16:38Z    │ 3716         │
│ Vulnerabilities                │ alpine:3.14                          │ true    │ 2026-03-08T06:16:38Z    │ 4296         │
│ Vulnerabilities                │ alpine:3.15                          │ true    │ 2026-03-08T06:16:38Z    │ 4848         │
...
│ Vulnerabilities                │ msrc:12098                           │ true    │ 2026-03-08T06:16:20Z    │ 1777         │
│ Vulnerabilities                │ msrc:12099                           │ true    │ 2026-03-08T06:16:20Z    │ 1783         │
│ Vulnerability Match Exclusions │ anchore:exclusions                   │ true    │ 2026-03-08T12:10:14Z    │ 13362        │
│ STIG Profiles                  │ apache-tomcat-9                      │ true    │ 2026-02-19T06:25:22Z    │ 1            │
│ STIG Profiles                  │ nginx                                │ true    │ 2026-02-19T06:25:22Z    │ 1            │
│ STIG Profiles                  │ rhel8                                │ true    │ 2026-02-19T06:25:22Z    │ 1            │
│ STIG Profiles                  │ rhel9                                │ true    │ 2026-02-19T06:25:22Z    │ 1            │
│ STIG Profiles                  │ ubuntu2204                           │ true    │ 2026-02-19T06:25:22Z    │ 1            │
│ STIG Profiles                  │ ubuntu2404                           │ true    │ 2026-02-19T06:25:22Z    │ 1            │
└────────────────────────────────┴──────────────────────────────────────┴─────────┴─────────────────────────┴──────────────┘

As soon as you see RecordCount values set for all vulnerability groups, the system is fully populated and ready to present vulnerability results. Note that data syncs are incremental, so the next time you start up Anchore Enterprise it will be ready immediately. The AnchoreCTL includes a useful utility that will block until the feeds have completed a successful sync:

anchorectl system wait

#Output
 ✔ API available                                                                                        system
 ✔ Services available                        [10 up]                                                    system
 ✔ Vulnerabilities feed ready                                                                           system

Step 5: Start Using Anchore Enterprise

To get started, you can add a few images to Anchore Enterprise using AnchoreCTL. Once complete, you can also run an additional AnchoreCTL command to monitor the analysis state of the added images, waiting until the images move into an ‘analyzed’ state.

anchorectl image add docker.io/library/alpine:latest

#Output
 ✔ Added Image                                                                                                              docker.io/library/alpine:latest
Image:
  status:           not-analyzed (active)
  tag:              docker.io/library/alpine:latest
  digest:           sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870
  id:               9c6f0724472873bb50a2ae67a9e7adcb57673a183cea8b06eb778dca859181b5

```bash
anchorectl image add docker.io/library/nginx:latest

#Output
 ✔ Added Image                                                                                                              docker.io/library/nginx:latest
Image:
  status:           not-analyzed (active)
  tag:              docker.io/library/nginx:latest
  digest:           sha256:89020cd33be2767f3f894484b8dd77bc2e5a1ccc864350b92c53262213257dfc
  id:               2b7d6430f78d432f89109b29d88d4c36c868cdbf15dc31d2132ceaa02b993763
  distro:           debian@11 (amd64)
  layers:           6

anchorectl image list

#Output
 ✔ Fetched images
┌───────────────────────────────────────────────────────┬─────────────────────────────────────────────────────────────────────────┬──────────────┬────────┐
│ TAG                                                   │ DIGEST                                                                  │ ANALYSIS     │ STATUS │
├───────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────┼──────────────┼────────┤
│ docker.io/library/alpine:latest                       │ sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870 │ analyzed     │ active │
│ docker.io/library/nginx:latest                        │ sha256:89020cd33be2767f3f894484b8dd77bc2e5a1ccc864350b92c53262213257dfc │ not_analyzed │ active │
└───────────────────────────────────────────────────────┴─────────────────────────────────────────────────────────────────────────┴──────────────┴────────┘

anchorectl image add docker.io/library/nginx:latest --force --wait

#Output
 ⠏ Adding Image                                                                                                              docker.io/library/nginx:latest
 ⠼ Analyzing Image                           [analyzing]                                                                     docker.io/library/nginx:latest
...
...
 ✔ Analyzed Image                                                                                                            docker.io/library/nginx:latest
Image:
  status:           analyzed (active)
  tags:             docker.io/library/nginx:latest
  digest:           sha256:89020cd33be2767f3f894484b8dd77bc2e5a1ccc864350b92c53262213257dfc
  id:               2b7d6430f78d432f89109b29d88d4c36c868cdbf15dc31d2132ceaa02b993763
  distro:           debian@11 (amd64)
  layers:           6

anchorectl image list

#Output
 ✔ Fetched images
┌───────────────────────────────────────────────────────┬─────────────────────────────────────────────────────────────────────────┬──────────┬────────┐
│ TAG                                                   │ DIGEST                                                                  │ ANALYSIS │ STATUS │
├───────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────┼──────────┼────────┤
│ docker.io/library/alpine:latest                       │ sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870 │ analyzed │ active │
│ docker.io/library/nginx:latest                        │ sha256:89020cd33be2767f3f894484b8dd77bc2e5a1ccc864350b92c53262213257dfc │ analyzed │ active │
└───────────────────────────────────────────────────────┴─────────────────────────────────────────────────────────────────────────┴──────────┴────────┘

Now that some images are in place, you can point your browser at the Anchore Enterprise UI by directing it to http://localhost:3000/.

Enter the username admin and the password you defined in the compose file to log in. These are some of the features you can use in the browser:

• Navigate images
• Inspect image contents
• Perform security scans
• Review compliance policy evaluations
• Edit compliance policies with a complete policy editor UI
• Manage accounts, users, and RBAC assignments
• Review system events

Next Steps

Now that you have Anchore Enterprise running, you can begin to learn more about Anchore capabilities, architecture, concepts, and more.

• To learn more about Anchore Enterprise, see Overview

• To learn more about Anchore capabilities, see Capabilities
• To learn more about Anchore architecture, see Architecture
• To learn more about Anchore concepts, see Concepts
• To learn more about other deployment methods, see Deployment
• To learn more about using Anchore, start with Vulnerability Management

Optional: Enable Prometheus Monitoring

1. Uncomment the following section at the bottom of the docker-compose.yaml file:

   #  # Uncomment this section to add a prometheus instance to gather metrics. This is mostly for quickstart to demonstrate prometheus metrics exported
   #  prometheus:
   #    image: docker.io/prom/prometheus:latest
   #    depends_on:
   #      - api
   #    volumes:
   #      - ./anchore-prometheus.yml:/etc/prometheus/prometheus.yml:z
   #    logging:
   #      driver: "json-file"
   #      options:
   #        max-size: 100m
   #    ports:
   #      - "9090:9090"
   #
   

2. For each service entry in the docker-compose.yaml, change the following to enable metrics in the API for each service

   ANCHORE_ENABLE_METRICS=false
   

   to

   ANCHORE_ENABLE_METRICS=true
   

3. Download the example prometheus configuration into the same directory as the docker-compose.yaml file, with name anchore-prometheus.yml:

   curl https://docs.anchore.com/current/docs/deployment/anchore-prometheus.yml > anchore-prometheus.yml
   docker compose up -d
   

   Result: You should see a new container started and can access prometheus via your browser on http://localhost:9090.

Optional: Enable Swagger UI

1. Uncomment the following section at the bottom of the docker-compose.yaml file:

   #  # Uncomment this section to run a swagger UI service, for inspecting and interacting with the system API via a browser (http://localhost:8080 by default, change if needed in both sections below)
   #  swagger-ui-nginx:
   #    image: docker.io/nginx:latest
   #    depends_on:
   #      - api
   #      - swagger-ui
   #    ports:
   #      - "8080:8080"
   #    volumes:
   #      - ./anchore-swaggerui-nginx.conf:/etc/nginx/nginx.conf:z
   #    logging:
   #      driver: "json-file"
   #      options:
   #        max-size: 100m
   #  swagger-ui:
   #    image: docker.io/swaggerapi/swagger-ui
   #    environment:
   #      - URL=http://localhost:8080/v2/openapi.json
   #    logging:
   #      driver: "json-file"
   #      options:
   #        max-size: 100m
   

2. Download the nginx configuration into the same directory as the docker-compose.yaml file, with name anchore-swaggerui-nginx.conf:

   curl https://docs.anchore.com/current/docs/deployment/anchore-swaggerui-nginx.conf > anchore-swaggerui-nginx.conf
   docker compose up -d
   

   Result: You should see a new container started, and have access Swagger UI via your browser on http://localhost:8080.

2.3 - Deploy on Kubernetes using Helm

The supported method for deploying Anchore Enterprise on Kubernetes is with Helm. The Anchore Enterprise Helm Chart includes configuration options for a full Enterprise deployment.

About the Helm Chart

The chart is split into global and service specific configurations for the core features, as well as global and services specific configurations for the optional Enterprise services.

• The anchoreConfig section of the values file contains the application configuration for Anchore Enterprise. This includes the database connection information, credentials, and other application settings.
• Anchore Enterprise services run as a kubernetes deployment when installed with the Helm chart. Each service has its own section in the values file for making customizations and configuring the kubernetes deployment spec.

For a description of each service component see Anchore Enterprise Service Overview

Prerequisites

See the README in the chart repository for prerequisites before starting the deployment.

Install the Chart

This guide covers deploying Anchore Enterprise on a Kubernetes cluster with the default configuration. Refer to the Configuration section of the chart README for additional guidance on production deployments.

1. Create the namespace: The steps to follow will require the namespace to have been created already.

   export NAMESPACE=anchore
   
   kubectl create namespace ${NAMESPACE}
   

2. Create a Kubernetes Secret for License File: Generate a Kubernetes secret to store your Anchore Enterprise license file.

   export NAMESPACE=anchore
   export LICENSE_PATH="license.yaml"
   
   kubectl create secret generic anchore-enterprise-license --from-file=license.yaml=${LICENSE_PATH} -n ${NAMESPACE}
   

3. Create a Kubernetes Secret for DockerHub Credentials: Generate a Kubernetes secret containing the Anchore-provided DockerHub credentials. These credentials are required for authenticated access to the private Anchore Enterprise repositories on DockerHub in order to pull/download the Docker images used by the deployment. Contact Anchore Support to obtain access.

   export NAMESPACE=anchore
   export DOCKERHUB_PASSWORD="password"
   export DOCKERHUB_USER="username"
   export DOCKERHUB_EMAIL="[email protected]"
   
   kubectl create secret docker-registry anchore-enterprise-pullcreds --docker-server=docker.io --docker-username=${DOCKERHUB_USER} --docker-password=${DOCKERHUB_PASSWORD} --docker-email=${DOCKERHUB_EMAIL} -n ${NAMESPACE}
   

4. Add Chart Repository & Deploy Anchore Enterprise: Create a custom values file, named anchore_values.yaml, to override any chart parameters. Refer to the Parameters section for available options.

   Default passwords are specified in the chart and must be changed before deploying. The password for the admin user is set via the anchoreConfig.default_admin_password parameter in your custom anchore_values.yaml file. This value is only used during initial creation of the admin user; the password can be changed post-installation via the UI.
   The RELEASE variable should not contain any dots.

   export NAMESPACE=anchore
   export RELEASE=anchore
   
   helm repo add anchore https://charts.anchore.io
   helm install ${RELEASE} -n ${NAMESPACE} anchore/enterprise -f anchore_values.yaml
   

   The helm install command will initiate the installation of Anchore Enterprise into the specified namespace using the chart parameters defined in your custom anchore_values.yaml file. Upon completion, the pod status can be checked per the below and should reflect READY 1/1 and STATUS Running for each pod.

   kubectl get pods -n ${NAMESPACE}
   

   Example output:

   NAME                                                READY   STATUS    RESTARTS   AGE
   anchore-enterprise-analyzer-5f7f97ffcf-6rtrn        1/1     Running   0          5m
   anchore-enterprise-api-587fb89495-sl2xn             1/1     Running   0          5m
   anchore-enterprise-catalog-7767d58d4f-6dsv7         1/1     Running   0          5m
   anchore-enterprise-datasyncer-558959869f-qp9nx      1/1     Running   0          5m
   anchore-enterprise-notifications-64ccbf9864-pl629   1/1     Running   0          5m
   anchore-enterprise-policy-6dc88b5df6-vrrcw          1/1     Running   0          5m
   anchore-enterprise-reports-569587dbf5-jjfz2         1/1     Running   0          5m
   anchore-enterprise-reportsworker-6bc7f7b4dd-7fnrn   1/1     Running   0          5m
   anchore-enterprise-simplequeue-7f848498df-64bxq     1/1     Running   0          5m
   anchore-enterprise-ui-6fd7d78449-2vc6l              1/1     Running   0          5m
   anchore-postgresql-0                                1/1     Running   0          5m
   anchore-ui-redis-master-0                           1/1     Running   0          5m
   

   There should be 12 Anchore Enterprise pods in total, which includes PostgreSQL and Redis.

   This command installs Anchore Enterprise with a chart-managed PostgreSQL database, which may not be suitable for production use. See the External Database section of the chart README for details on using an external database.

5. Post-Installation Steps: Anchore Enterprise will take some time to initialize. After the bootstrap phase, it will begin a vulnerability feed sync. Image analysis will show zero vulnerabilities and the UI will show errors until the sync is complete, which can take an hour or more based on the enabled feeds. The sync process will take place in the background, and while it’s in progress, anchorectl can be installed and the below commands can be used to check system status.

   Export the required parameters to invoke anchorectl:

   export NAMESPACE=anchore
   export RELEASE=anchore
   export ANCHORECTL_URL=http://localhost:8228
   export ANCHORECTL_USERNAME="admin"
   export ANCHORECTL_PASSWORD="<default_admin_password>"
   

   Port-forward API and UI traffic to the associated pods. Run each command in a separate terminal window in the background:

   kubectl port-forward -n ${NAMESPACE} svc/${RELEASE}-enterprise-api 8228:8228 --address 0.0.0.0 --request-timeout=0 &
   kubectl port-forward -n ${NAMESPACE} svc/${RELEASE}-enterprise-ui 3000:80 --address 0.0.0.0 --request-timeout=0 &
   

   Gather the status of Anchore Enterprise services. anchorectl defaults to the user ${ANCHORECTL_USERNAME} and to the password ${ANCHORECTL_PASSWORD} automatically if set:

   anchorectl system status
   

   Example output:

    ✔ Status system
   ┌─────────────────┬────────────────────┬─────────────────────────────┬──────┬────────────────┬────────────┬──────────────┐
   │ SERVICE         │ HOST ID            │ URL                         │ UP   │ STATUS MESSAGE │ DB VERSION │ CODE VERSION │
   ├─────────────────┼────────────────────┼─────────────────────────────┼──────┼────────────────┼────────────┼──────────────┤
   │ analyzer        │ anchore-quickstart │ http://analyzer:8228        │ true │ available      │ 5270       │ 5.27.0       │
   │ policy_engine   │ anchore-quickstart │ http://policy-engine:8228   │ true │ available      │ 5270       │ 5.27.0       │
   │ apiext          │ anchore-quickstart │ http://api:8228             │ true │ available      │ 5270       │ 5.27.0       │
   │ reports         │ anchore-quickstart │ http://reports:8228         │ true │ available      │ 5270       │ 5.27.0       │
   │ reports_worker  │ anchore-quickstart │ http://reports-worker:8228  │ true │ available      │ 5270       │ 5.27.0       │
   │ data_syncer     │ anchore-quickstart │ http://data-syncer:8228     │ true │ available      │ 5270       │ 5.27.0       │
   │ simplequeue     │ anchore-quickstart │ http://queue:8228           │ true │ available      │ 5270       │ 5.27.0       │
   │ notifications   │ anchore-quickstart │ http://notifications:8228   │ true │ available      │ 5270       │ 5.27.0       │
   │ catalog         │ anchore-quickstart │ http://catalog:8228         │ true │ available      │ 5270       │ 5.27.0       │
   └─────────────────┴────────────────────┴─────────────────────────────┴──────┴────────────────┴────────────┴──────────────┘
   

   For more information about configuring anchorectl, see Using Environment Variables.
   The port forwarding shown above is intended only for POC purposes or an initial Anchore Enterprise installation and is not recommended for Production use. In a Production environment, an ingress controller or load balancer is recommended for exposing the Anchore Enterprise API and UI services. See the cloud-provider–specific Helm deployment guides (AKS, EKS, GKE, OpenShift) for ingress examples.
   List all Helm releases using helm list -n ${NAMESPACE}.

Next Steps

Now that you have Anchore Enterprise running, you can begin to learning more about Anchore Enterprise architecture, Anchore concepts, and Anchore usage.

• To learn more about Anchore Enterprise, go to Overview
• To learn more about Anchore Enterprise Concepts, go to Concepts

2.3.1 - Deploying Anchore Enterprise on Azure Kubernetes Service (AKS)

This document will walk you through the deployment of Anchore Enterprise in an Azure Kubernetes Service (AKS) cluster and expose it on the public Internet.

Prerequisites

• A running AKS cluster with worker nodes launched. See AKS Documentation for more information on this setup.
• Helm client on local host.
• AnchoreCTL installed on a local host.

Once you have an AKS cluster up and running with worker nodes launched, you can verify via the following command.

$ kubectl get nodes

NAME                       STATUS   ROLES   AGE     VERSION
aks-nodepool1-28659018-0   Ready    agent   4m13s   v1.30.3
aks-nodepool1-28659018-1   Ready    agent   4m15s   v1.30.3
aks-nodepool1-28659018-2   Ready    agent   4m6s    v1.30.3

Anchore Enterprise Helm Chart

Anchore maintains a Helm chart to simplify the software deployment process. An Anchore Enterprise deployment of the chart will include the following:

• Anchore Enterprise software
• PostgreSQL (13 or higher)
• Redis (7 or higher)

To make the necessary configurations to the Helm chart, create a custom anchore_values.yaml file and reference it during deployment. There are many options for configuration with Anchore Enterprise; this document is intended to cover the minimum required changes to successfully deploy Anchore Enterprise in AKS.

Azure Flexible Postgres

For production deployments we generally favor cloud-provider managed databases over using the built-in chart. This ensures the database is isolated from workloads allowing it to use CPU & Memory without contention. We suggest selecting a storage option that allows for automatic size increase.

If you choose to use Azure Flexible Postgres ensure that you make the following changes for compatibility with Anchore Enterprise:

• pgbouncer.enabled: false - It is very important that this setting be turned off!
• idle_in_transaction_session_timeout: 0
• max_connections should be at least 500. The default is based on the amount of instance memory. 16GB or larger instances will have high enough max_connections setting by default.

Refer to configuration settings in the chart for Amazon RDS: https://github.com/anchore/anchore-charts/tree/main/stable/enterprise#external-database-requirements (Configuring an external database in the chart is the essentially the same for RDS or Azure Flexible Postgres).

Configurations

For Azure Application Gateway Ingress Controller (AGIC) Ingress add-on make the following changes below to your anchore_values.yaml

Ingress

ingress:
  enabled: true
  apiPaths:
    - /v2/
    - /version/
  uiPath: /
  apiHosts:
    - anchore.mydomain.com
  uiHosts:
    - anchore.mydomain.com
  annotations:
    # See https://learn.microsoft.com/en-us/azure/application-gateway/ingress-controller-annotations for more annotations
    kubernetes.io/ingress.class: azure/application-gateway

Anchore Enterprise API Service

# Pod configuration for the anchore api service.
api:
  # kubernetes service configuration for anchore external API
  service:
    type: NodePort
    port: 8228
    annotations: {}

Anchore Enterprise UI

ui:
  # kubernetes service configuration for anchore UI
  service:
    type: NodePort
    port: 80
    annotations: {}
    sessionAffinity: ClientIP

Deploy Anchore Enterprise

Enterprise services require an Anchore Enterprise license, as well as credentials with permission to access the private DockerHub repository containing the enterprise software.

Create a Kubernetes secret containing your license file:

kubectl create secret generic anchore-enterprise-license --from-file=license.yaml=<PATH/TO/LICENSE.YAML>

Create a Kubernetes secret containing DockerHub credentials with access to the private Anchore Enterprise software:

kubectl create secret docker-registry anchore-enterprise-pullcreds --docker-server=docker.io --docker-username=<DOCKERHUB_USER> --docker-password=<DOCKERHUB_PASSWORD> --docker-email=<EMAIL_ADDRESS>

Deploy Anchore Enterprise:

helm repo add anchore https://charts.anchore.io
helm install anchore anchore/enterprise -f anchore_values.yaml

It will take the system several minutes to bootstrap. You can check the status of the pods by running kubectl get pods:

$ kubectl get pods

NAME                                                              READY   STATUS    RESTARTS   AGE
anchore-enterprise-analyzer-7f9c7c65c8-tp8cs                      1/1     Running   0          13m
anchore-enterprise-api-754cdb48bc-x8kxt                           1/1     Running   0          13m
anchore-enterprise-catalog-64d4b9bb8-x8vmb                        1/1     Running   0          13m
anchore-enterprise-datasyncer-558959869f-qp9nx                    1/1     Running   0          13m
anchore-enterprise-notifications-65bd45459f-q28h2                 1/1     Running   0          13m
anchore-enterprise-policy-657fdfd7f6-gzkmh                        1/1     Running   0          13m
anchore-enterprise-reports-596cb47894-q8g49                       1/1     Running   0          13m
anchore-enterprise-reportsworker-6bc7f7b4dd-7fnrn                 1/1     Running   0          13m
anchore-enterprise-simplequeue-98b95f985-5xqcv                    1/1     Running   0          13m
anchore-enterprise-ui-6794bbd47-vxljt                             1/1     Running   0          13m
anchore-postgresql-0                                              1/1     Running   0          13m
anchore-ui-redis-master-0                                         1/1     Running   0          13m
mangy-serval-nginx-ingress-controller-788dd98c8b-jv2wg            1/1     Running   0          21m
mangy-serval-nginx-ingress-default-backend-8686cd585b-4m2bt       1/1     Running   0          21m

We can see that NGINX ingress controller has been installed as well from the previous step. You can view the services by running the following command:

$ kubectl get services | grep ingress

mangy-serval-nginx-ingress-controller                LoadBalancer   10.0.30.174    40.114.26.147   80:31176/TCP,443:30895/TCP                     22m
mangy-serval-nginx-ingress-default-backend           ClusterIP      10.0.243.221   <none>          80/TCP                                         22m

Anchore Enterprise System

Check the status of the system with AnchoreCTL to verify all of the Anchore Enterprise services are up:

ANCHORECTL_URL=http://40.114.26.147/v2/ ANCHORECTL_USERNAME=admin ANCHORECTL_PASSWORD=foobar anchorectl system status

Anchore Enterprise Feeds

It can take 5 minutes or more to fetch all of the vulnerability feeds from the Anchore Data Service. Check on the status of feeds with AnchoreCTL:

ANCHORECTL_URL=http://40.114.26.147/v2/ ANCHORECTL_USERNAME=admin ANCHORECTL_PASSWORD=foobar anchorectl feed list

Once the vulnerability feed sync is complete, Anchore Enterprise can begin to return vulnerability results on analyzed images. Please continue to the Vulnerability Management section of our documentation for more information.

2.3.2 - Deploying Anchore Enterprise on Amazon EKS

This section provides information on how to deploy Anchore Enterprise onto Amazon EKS. Here is recommended architecture on AWS EKS:

Prerequisites

You’ll need a running Amazon EKS cluster with worker nodes. See EKS Documentation for more information on this setup.

Once you have an EKS cluster up and running with worker nodes launched, you can verify it using the following command:

$ kubectl get nodes
NAME                             STATUS   ROLES    AGE   VERSION
ip-192-168-2-164.ec2.internal    Ready    <none>   10m   v1.30.3-eks-a737599
ip-192-168-35-43.ec2.internal    Ready    <none>   10m   v1.30.3-eks-a737599
ip-192-168-55-228.ec2.internal   Ready    <none>   10m   v1.30.3-eks-a737599

In order to deploy the Anchore Enterprise services, you’ll then need the Helm client installed on local host. Anchore maintains a Helm chart to simplify the software deployment process.

To make the necessary configurations to the Helm chart, create a custom anchore_values.yaml file and reference it during deployment. There are many options for configuration with Anchore. The following is intended to cover the recommended changes for successfully deploying Anchore Enterprise on Amazon EKS.

Configuration

The following configurations should be used when deploying on EKS.

RDS

Anchore recommends utilizing Amazon RDS for a managed database service, rather than the Anchore chart-managed postgres. For information on how to configure for an external RDS database, see Amazon RDS. It is suggested to allow the storage to automatically increase as needed.

S3 Object Storage

Anchore Enterprise supports the use of S3 object storage for archival of SBOMs, configuration details can be found here. Consider using the iamauto: True option to utilise IAM roles for access to S3.

PVCs

Anchore Enterprise by default uses ephemeral storage for pods but we recommend configuring Analyzer scratch space, at a minimum. Further details can be found here.

Anchore generally recommends providing EBS-backed storage for analyzer scratch of the gp3 type. Note that you will need to follow the AWS guide on storing K8s volumes with Amazon EBS. Once the CSI driver is configured for your cluster, you will then need to configure your helm chart with values similar to this:

analyzer:   
  scratchVolume:
    details:
      ephemeral:
        volumeClaimTemplate:
          metadata: {}
          spec:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                # must be 3xANCHORE_MAX_COMPRESSED_IMAGE_SIZE_MB + analyser_cache_size
                # Setting this to 100G would mean the largest image you can scan is 30G (not counting analysis cache if you choose to configure that)
                storage: 100Gi
            # this would refer to whatever your storage class was named
            storageClassName: "gp3"

Ingress

Anchore recommends using the AWS load balancer controller or EKS Auto Mode (https://docs.aws.amazon.com/eks/latest/userguide/auto-configure-alb.html) for ingress.

We also suggest using a vanity domain (anchore.mydomain.com in the example below) over TLS with Route53 & ACM however this goes beyond the scope of this document.

Here is a sample manifest for use with the AWS LBC or EKS Auto Mode ALB ingress:

ingress:
  enabled: true
  apiPaths:
    - /v2/
    - /version/
  uiPath: /
  ingressClassName: alb
  annotations:
    # See https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/main/docs/guide/ingress/annotations.md for further customization of annotations
    alb.ingress.kubernetes.io/scheme: internet-facing
  # If you do not plan to bring your own hostname (i.e. use the AWS supplied CNAME for the load balancer) then you can leave apiHosts & uiHosts as empty lists:
  #apiHosts: []
  #uiHosts: []
  # If you plan to bring your own hostname then you'll likely want to populate them as follows:
  apiHosts:
    - anchore.mydomain.com
  uiHosts:
    - anchore.mydomain.com

You must also configure/change the following from ClusterIP to NodePort:

Anchore Enterprise API Service

# Pod configuration for the Anchore Enterprise API service.
api:
  # kubernetes service configuration for anchore external API
  service:
    type: NodePort
    port: 8228
    annotations: {}

Anchore Enterprise UI Service

ui:
  # kubernetes service configuration for anchore UI
  service:
    type: NodePort
    port: 80
    annotations: {}
    sessionAffinity: ClientIP

Amazon ALB Parameters

Users of ALB may want to align the timeout between gunicorn & ALB. The AWS ALB Connection idle timeout defaults to 60 seconds. The Anchore Enterprise Helm charts have a timeout setting that defaults to 5 seconds which should be aligned with the ALB timeout setting. Sporatic HTTP 502 errors may be emitted by the ALB if the timeouts are not in alignment. Please see this reference:

anchoreConfig:
  server:
    timeout_keep_alive: 65

Install Anchore Enterprise

Deploy Anchore Enterprise by following the instructions here.

Verify Ingress

Run the following command for details on the deployed ingress resource using the ELB:

$ kubectl describe ingress
Name:             anchore-enterprise
Namespace:        default
Address:          xxxxxxx-default-anchoreen-xxxx-xxxxxxxxx.us-east-1.elb.amazonaws.com
Default backend:  default-http-backend:80 (<none>)
Rules:
  Host  Path  Backends
  ----  ----  --------
  *     
        /v2/*   anchore-enterprise-api:8228 (192.168.42.122:8228)
        /*      anchore-enterprise-ui:80 (192.168.14.212:3000)
Annotations:
  alb.ingress.kubernetes.io/scheme:  internet-facing
  kubernetes.io/ingress.class:       alb
Events:
  Type    Reason  Age   From                    Message
  ----    ------  ----  ----                    -------
  Normal  CREATE  14m   alb-ingress-controller  LoadBalancer 904f0f3b-default-anchoreen-d4c9 created, ARN: arn:aws:elasticloadbalancing:us-east-1:077257324153:loadbalancer/app/904f0f3b-default-anchoreen-d4c9/4b0e9de48f13daac
  Normal  CREATE  14m   alb-ingress-controller  rule 1 created with conditions [{    Field: "path-pattern",    Values: ["/v2/*"]  }]
  Normal  CREATE  14m   alb-ingress-controller  rule 2 created with conditions [{    Field: "path-pattern",    Values: ["/*"]  }]

The output above shows that an ELB has been created. Next, try navigating to the specified URL in a browser:

Verify Anchore Enterprise Service Status

Check the status of the system with AnchoreCTL to verify all of the Anchore services are up:

ANCHORECTL_URL=http://xxxxxx-default-anchoreen-xxxx-xxxxxxxxxx.us-east-1.elb.amazonaws.com ANCHORECTL_USERNAME=admin ANCHORECTL_PASSWORD=foobar anchorectl system status

2.3.3 - Deploying Anchore Enterprise on Google Kubernetes Engine (GKE)

Get an understanding of deploying Anchore Enterprise on a Google Kubernetes Engine (GKE) cluster and exposing it on the public Internet.

Prerequisites

• A running GKE cluster with worker nodes launched. See GKE Documentation for more information on this setup.
• Helm client installed on local host.
• AnchoreCTL installed on local host.

Once you have a GKE cluster up and running with worker nodes launched, you can verify it by using the following command.

$ kubectl get nodes
NAME                                                STATUS   ROLES    AGE   VERSION
gke-standard-cluster-1-default-pool-c04de8f1-hpk4   Ready    <none>   78s   v1.30.3-gke.1639000
gke-standard-cluster-1-default-pool-c04de8f1-m03k   Ready    <none>   79s   v1.30.3-gke.1639000
gke-standard-cluster-1-default-pool-c04de8f1-mz3q   Ready    <none>   78s   v1.30.3-gke.1639000

Anchore Enterprise Helm Chart

Anchore maintains a Helm chart to simplify the software deployment process. An Anchore Enterprise deployment of the chart will include the following:

• Anchore Enterprise software
• PostgreSQL (13 or higher)
• Redis (7 or higher)

To make the necessary configurations to the Helm chart, create a custom anchore_values.yaml file and reference it during deployment. There are many options for configuration with Anchore Enterprise. The following is intended to cover the minimum required changes to successfully deploy Anchore Enterprise on Google Kubernetes Engine.

Configurations

Make the following changes below to your anchore_values.yaml

Ingress

ingress:
  enabled: true
  apiPaths:
    - /v2/*
  uiPath: /*

Anchore Enterprise API Service

api:
  replicaCount: 1
  # kubernetes service configuration for anchore external API
  service:
    type: NodePort
    port: 8228
    annotations: {}

Anchore Enterprise UI

ui:
  # kubernetes service configuration for anchore UI
  service:
    type: NodePort
    port: 80
    annotations: {}
    sessionAffinity: ClientIP

Anchore Enterprise Deployment

Create Secrets

Enterprise services require an Anchore Enterprise license, as well as credentials with permission to access the private DockerHub repository containing the enterprise software.

Create a Kubernetes secret containing your license file:

kubectl create secret generic anchore-enterprise-license --from-file=license.yaml=<PATH/TO/LICENSE.YAML>

Create a Kubernetes secret containing DockerHub credentials with access to the private Anchore Enterprise software:

kubectl create secret docker-registry anchore-enterprise-pullcreds --docker-server=docker.io --docker-username=<DOCKERHUB_USER> --docker-password=<DOCKERHUB_PASSWORD> --docker-email=<EMAIL_ADDRESS>

Deploy Anchore Enterprise:

helm repo add anchore https://charts.anchore.io
helm install anchore anchore/enterprise -f anchore_values.yaml

It will take the system several minutes to bootstrap. You can check the status of the pods by running kubectl get pods:

$ kubectl get pods
NAME                                                              READY   STATUS    RESTARTS   AGE
anchore-enterprise-analyzer-7f9c7c65c8-tp8cs                      1/1     Running   0          13m
anchore-enterprise-api-754cdb48bc-x8kxt                           1/1     Running   0          13m
anchore-enterprise-catalog-64d4b9bb8-x8vmb                        1/1     Running   0          13m
anchore-enterprise-datasyncer-558959869f-qp9nx                    1/1     Running   0          13m
anchore-enterprise-notifications-65bd45459f-q28h2                 1/1     Running   0          13m
anchore-enterprise-policy-657fdfd7f6-gzkmh                        1/1     Running   0          13m
anchore-enterprise-reports-596cb47894-q8g49                       1/1     Running   0          13m
anchore-enterprise-reportsworker-6bc7f7b4dd-7fnrn                 1/1     Running   0          13m
anchore-enterprise-simplequeue-98b95f985-5xqcv                    1/1     Running   0          13m
anchore-enterprise-ui-6794bbd47-vxljt                             1/1     Running   0          13m
anchore-postgresql-0                                              1/1     Running   0          13m
anchore-ui-redis-master-0                                         1/1     Running   0          13m

Run the following command for details on the deployed ingress resource:

$ kubectl describe ingress
Name:             anchore-enterprise
Namespace:        default
Address:          34.96.64.148
Default backend:  default-http-backend:80 (10.8.2.6:8080)
Rules:
  Host  Path  Backends
  ----  ----  --------
  *
        /v2/*   anchore-enterprise-api:8228 (<none>)
        /*      anchore-enterprise-ui:80 (<none>)
Annotations:
  kubernetes.io/ingress.class:            gce
  ingress.kubernetes.io/backends:         {"k8s-be-31175--55c0399dc5755377":"HEALTHY","k8s-be-31274--55c0399dc5755377":"HEALTHY","k8s-be-32037--55c0399dc5755377":"HEALTHY"}
  ingress.kubernetes.io/forwarding-rule:  k8s-fw-default-anchore-enterprise--55c0399dc5750
  ingress.kubernetes.io/target-proxy:     k8s-tp-default-anchore-enterprise--55c0399dc5750
  ingress.kubernetes.io/url-map:          k8s-um-default-anchore-enterprise--55c0399dc5750
Events:
  Type    Reason  Age   From                     Message
  ----    ------  ----  ----                     -------
  Normal  ADD     15m   loadbalancer-controller  default/anchore-enterprise
  Normal  CREATE  14m   loadbalancer-controller  ip: 34.96.64.148

The output above shows that an Load Balancer has been created. Navigate to the specified URL in a browser:

Anchore Enterprise System

Check the status of the system with AnchoreCTL to verify all of the Anchore services are up:

ANCHORECTL_URL=http://34.96.64.148 ANCHORECTL_USERNAME=admin ANCHORECTL_PASSWORD=foobar anchorectl system status

Anchore Enterprise Feeds

It can take some time to fetch all of the vulnerability feeds from the upstream data sources. Check on the status of feeds with AnchoreCTL:

ANCHORECTL_URL=http://34.96.64.148 ANCHORECTL_USERNAME=admin ANCHORECTL_PASSWORD=foobar anchorectl feed list

Once the vulnerability feed sync is complete, Anchore Enterprise can begin to return vulnerability results on analyzed images. Please continue to the Vulnerability Management section of our documentation for more information.

2.3.4 - Deploying Anchore Enterprise on OpenShift

This document will walk through the deployment of Anchore Enterprise on an OpenShift 4.x cluster and expose it on the public internet.

Prerequisites

• A running OpenShift 4.x cluster. Read more about the installation requirements in the OpenShift Container Platform documentation.
• Helm client and server installed and configured with your cluster.
• AnchoreCTL installed on local host.

Anchore Enterprise Helm Chart

Anchore maintains a Helm chart to simplify the software deployment process. An Anchore Enterprise installation of the chart will include the following:

• Anchore Enterprise software
• PostgreSQL (13 or higher)
• Redis (7 or higher)

To make the necessary configurations to the Helm chart, create a custom anchore_values.yaml file and reference it during deployment. There are many options for configuration with Anchore Enterprise; this document is intended to cover the minimum required changes to successfully deploy Anchore Enterprise on OpenShift.

OpenShift Configurations

Create a New Project

Create a new project called anchore-enterprise:

oc new-project anchore-enterprise

Create Secrets

Two secrets are required for an Anchore Enterprise deployment.

Create a secret for the license file:

oc create secret generic anchore-enterprise-license --from-file=license.yaml=license.yaml

Create a secret for pulling the images:

oc create secret docker-registry anchore-enterprise-pullcreds --docker-server=docker.io --docker-username=<username> --docker-password=<password> --docker-email=<email>

Verify these secrets are in the correct namespace (anchore-enterprise):

oc describe secret <secret-name>

Link ImagePullSecret

Link the above Docker registry secret to the default service account:

oc secrets link default anchore-enterprise-pullcreds --for=pull --namespace=anchore-enterprise

Verify this by running the following:

oc describe sa

Anchore Enterprise Configurations

Create a custom anchore_values.yaml file for your Anchore Enterprise deployment:

# NOTE: This is not a production ready values file for an openshift deployment.

securityContext:
  fsGroup: null
  runAsGroup: null
  runAsUser: null
postgresql:
  primary:
    containerSecurityContext:
      enabled: false
    podSecurityContext:
      enabled: false
ui-redis:
  master:
    podSecurityContext:
      enabled: false
    containerSecurityContext:
      enabled: false

Install Software

Run the following commands to install the software:

helm repo add anchore https://charts.anchore.io
helm install anchore -f anchore_values.yaml anchore/enterprise

It will take the system several minutes to bootstrap. You can check the status of the pods by running oc get pods:

$ oc get pods
NAME                                                READY   STATUS    RESTARTS   AGE
anchore-enterprise-analyzer-7f9c7c65c8-tp8cs        1/1     Running   0          13m
anchore-enterprise-api-754cdb48bc-x8kxt             1/1     Running   0          13m
anchore-enterprise-catalog-64d4b9bb8-x8vmb          1/1     Running   0          13m
anchore-enterprise-datasyncer-585997576d-2fgkg      1/1     Running   0          13m
anchore-enterprise-notifications-65bd45459f-q28h2   1/1     Running   0          13m
anchore-enterprise-policy-657fdfd7f6-gzkmh          1/1     Running   0          13m
anchore-enterprise-reports-596cb47894-q8g49         1/1     Running   0          13m
anchore-enterprise-reportsworker-6fb4f55455-f2ts2   1/1     Running   0          13m
anchore-enterprise-simplequeue-98b95f985-5xqcv      1/1     Running   0          13m
anchore-enterprise-ui-6794bbd47-vxljt               1/1     Running   0          13m
anchore-postgresql-0                                1/1     Running   0          13m
anchore-ui-redis-master-0                           1/1     Running   0          13m

Create Route Objects

Create two route objects in the OpenShift console to expose the UI and API services on the public internet:

API Route

UI Route

Routes

Verify by navigating to the anchore-enterprise-ui route hostname. You should see the Anchore Enterprise login page.

Anchore Enterprise System

First you will need to retrieve the admin password. This is stored as a secret during the helm install process:

oc get secret anchore-enterprise-env -o jsonpath='{.data.ANCHORE_ADMIN_PASSWORD}' -n anchore | base64 -d

You can customize your Helm anchore_values.yaml file to use an existing/custom secret rather than have Helm generate one for you with a generated password.

Verify the API route hostname with AnchoreCTL:

ANCHORECTL_URL=http://<anchore-api-anchore.apps.rm2.thpm.p1.openshiftapps.com>\
ANCHORECTL_USERNAME=admin \
ANCHORECTL_PASSWORD=foobar \
anchorectl system status

Anchore Vulnerability Data

Anchore has a datasyncer service that pulls the vulnerability and other data sources such as the ClamAV malware database into your Anchore Enterprise deployment. You can check on the status of these feeds using AnchoreCTL:

ANCHORECTL_URL=http://<anchore-ui-anchore.apps.rm2.thpm.p1.openshiftapps.com> \
ANCHORECTL_USERNAME=admin \
ANCHORECTL_PASSWORD=foobar \
anchorectl feed list

2.4 - Anchore Enterprise Cloud Image

Overview

The Anchore Enterprise Cloud Image (AECI) is a fully functional machine image with an Anchore Enterprise deployment that is pre-configured with the goal of simplifying deployment complexity for our end users.

AECI contains a proprietary tool known as Cloud Image Manager. It allows users to manage their deployment by providing an easy way to install, configure and upgrade. For more information about the Cloud Image Manager, see the Cloud Image Manager.

To get started with deploying Anchore Enterprise Cloud Image, please see AECI - AWS.

Supported Limits

The Cloud Image has the following limits, independent of instance type:

• 10,000 Image SBOMs
• Max Image Size is 10 GB
• 300 Report Executions
• 100 System Users

Non-supported Features

The Cloud Image does not currently support the following Anchore Enterprise features:

• Air-gapped Deployment
• Runtime Inventory
• Application Groups and Source Code Analysis
• Windows Image Analysis
• Legacy Image Archive

To discuss further, contact Anchore Customer Success.

2.4.1 - Enterprise Cloud Image - Amazon Machine Image (AMI)

Requirements

The baseline supported instance type on Amazon Web Services is the r7a.xlarge. This gives the best mix of performance to cost for running Anchore Enterprise in alignment with the supported system limits.

For more information on Amazon EC2 Instance types Please review the following links

• AWS Instance Types Overview

• AWS Pricing Calculator

• Memory Requirement - AECI requires a minimum of 32 GB of memory to operate.

• Disk Requirement - AECI requires a minimum of 128 GB of disk space for root volume and 1 TB for data volume to operate.

  • Note: The data volume by default will not delete on termination of your AMI.

• CPU Requirement - AECI requires a minimum of 4 vCPU to operate.

License

The Anchore Enterprise Cloud Image requires a valid license entitlement to operate. The license is provided by Anchore during the purchase process. The license file is required to be uploaded via the Cloud Image Manager during the initial setup. Please have it available before starting the installation process.

EC2 Key Pair Type

Anchore Enterprise Cloud Image is running with FIPS enabled. When creating your Key Pair, you must use an RSA key. The ED25519 key will be rejected as a non-FIPS-compliant algorithm.

Please review the AWS documentation on using Amazon EC2 Key Pairs

Security Group

The Anchore Enterprise Cloud Image requires the following ports to be open in the security group:

• TCP 22 - SSH
• TCP 443 - HTTPS
• TCP 8443 - Grafana

Please review the AWS documentation on Security Groups.

Terminals

Please review the Best Practices for the Cloud Image Manager for the recommended terminal applications to use.

Getting Started

To launch the Anchore Enterprise Cloud Image AMI, please refer to the AWS documentation on Launch an Amazon EC2 instance.

You may also want to review the AWS guide for how to Connect to your EC2 instance.

Once the instance is launched, please review the Cloud Image Manager documentation for the next steps on Accessing the Cloud Image Manager. The Cloud Image Manager will walk you through the preflight checks, configuration, and management of your Anchore Enterprise Cloud Image deployment.

Operations

With AECI up and running, there is some limited feeding and watering required. You’ll want to consider the following activities:

Backups

It is important that you have a backup and restore strategy in place to protect your data. Cloud Image Manager will prompt you to create a snapshot prior to upgrading your Anchore Enterprise Cloud Image or expanding your disks. It is also reasonable for you to consider using AWS Backup and/or creating snapshots of your EBS volume on a regular basis:

Please refer to the AWS documentation on AWS Backup and Amazon EBS Snapshots.

Disk Space

During the course of using the product, you may wish to expand the size of your disks. It is strongly recommended that you create a snapshot of your EBS volume prior to expanding your disks.

Please refer to the AWS documentation on Extend or modify disk volume

Once you have expanded your disk, you will need to resize the filesystem to take advantage of the additional space. Cloud Image Manager provides a utility to resize the filesystem. Please refer to the Cloud Image Manager Configuration Disk Expansion for more information.

Upgrade

Occasionally, Anchore will release updates to the Anchore Enterprise Cloud Image and the subsequent version of Anchore Enterprise shipped with it. The Cloud Image Manager will provide you with upgrades that are available and allow you to determine when you want to upgrade. It is strongly recommended that you create a snapshot of your EBS volume prior to upgrading your Anchore Enterprise Cloud Image.

Please refer to the Cloud Image Manager upgrade documentation for more information.

Getting Support

During operation of Anchore Enterprise Cloud Image, you may require support from Anchore Customer Success. The Cloud Image Manager provides you with a seamless way to generate a support bundle and upload it to Anchore.

Please refer to the Cloud Image Manager Support documentation for more information.

2.4.2 - Anchore Enterprise Cloud Image Manager

Overview

The Cloud Image Manager is a proprietary tool that allows users to seamlessly manage their Anchore Enterprise Cloud Image deployments. It walks users through the process of installing, configuring, and upgrading their Anchore Enterprise Cloud Image deployment.

Best Practices

The Cloud Image Manager uses Textual (a TUI framework for Python) to provide a terminal-based interface. For your best user experience, please use the following terminal emulators when connecting to the Cloud Image Manager.

• On Linux
  • Kitty
  • WezTerm
• On macOS
  • iTerm2
  • Kitty
  • WezTerm
• On Windows
  • PowerShell

Note: We recommend against using the default macOS Terminal application as it may not render the TUI correctly. For more information on why, please see Textual FAQ.

Access the Cloud Image Manager

After your instance is launched, you can access the Cloud Image Manager by connecting to the instance via SSH. Using your private key file used for authentication (likely generated when setting up the instance) and the public IP address of the instance, connect using the following example command:

ssh -i ~/my-keypair.pem [email protected]

Potential Issues

1. Permissions on key file - If you get a WARNING: UNPROTECTED PRIVATE KEY FILE error, fix it by setting the correct permissions on your key file. Run the following command to set the correct permissions:

   chmod 400 ~/my-keypair.pem
   

2. Connection Issues - If you experience a Connection Timeout or Host Unreachable error, verify that the instance is running and that the security group allows SSH traffic on port 22.

You should now be connected to the Cloud Image Manager.

Preflight Checks

The Cloud Image Manager will perform a series of preflight checks to ensure that the system is ready for installation. These checks include ensuring that the machine image has met memory, disk space, and CPU requirements. If the system does not meet the requirements, the preflight checks will fail and the installation will not proceed.

Initial Install

The Cloud Image Manager will walk you through the initial installation process. At the end of this process, the Cloud Image Manager will provide you with the URL to access the Anchore Enterprise UI as well as your administrator credentials.

Upgrade

The Cloud Image Manager will determine if there are any upgrades available for your Anchore Enterprise Cloud Image deployment. If an upgrade is available, the Cloud Image Manager will walk you through the upgrade process. If downtime is required, the Cloud Image Manager will notify you prior to proceeding. This will allow you to plan for the upgrade when it is convenient for you. It is highly recommend that you take a snapshot of your EBS volume prior to upgrade.

Configuration

The Cloud Image Manager configuration screen allows the following options:

• Adding and updating the Anchore Enterprise License.
• Providing any Server Certificates required for TLS access to Anchore Enterprise services.
• Providing a custom Root Certificate if one is required for your environment.
• Configuring any optional proxy settings required for your environment.
• Disk Expansion

Reconfigure Proxy Settings

Changing Proxy settings after completing the installation process currently requires manual intervention for the settings to be fully applied. If you must change the Proxy settings, please contact customer support for assistance.

Expand Disks

The Cloud Image Manager provides a utility to expand the root and data volumes once your virtual hard disk has been increased in size. This step is necessary to take advantage of the additional space. The Cloud Image Manager will shut down Anchore Enterprise during this operation. It is highly recommend that you take a snapshot of your EBS volume prior to any operation that may modify your disk volumes.

System Status

The Cloud Image Manager provides a system status screen that shows the current service and container status of the Anchore Enterprise services. It also provides the list of currently deployed versions of Anchore Enterprise, Anchore Enterprise UI as well as the other infrastructure components that are automatically deployed within the Anchore Enterprise Cloud Image.

Support

The Cloud Image Manager provides a support screen that allows you to:

• Generate a support bundle. This will result with the location of the support bundle.
• Upload a generated support bundle. This will be automatically uploaded to Anchore. You must create a support ticket and provide the Support Bundle ID and Filename to the support team.
• As part of the Cloud Image deployment, you have access to Grafana data that is collected for your deployment. This data can be used to monitor the health of your deployment. The Cloud Image Manager provides a link and credentials to access the Grafana dashboard.

2.5 - Anchore Enterprise in an Air-Gapped Environment

Anchore Enterprise can run in an isolated environment with no outside internet connectivity. It does require a network connection to its own components and should be able to reach registries (Docker v2 API compatible) where the images to be analyzed are hosted.

Installation

Air-gapped deployment follows the standard deployment procedure for either Docker Compose or Kubernetes with Helm.

• Deploy from a private container registry
• Deploy from local images

Data Synchronization

To ensure that the Anchore Enterprise installation has up-to-date vulnerability data from the vulnerability sources, you will need to periodically download and import feed data into your Anchore Enterprise deployment. Details on how to do this can be found in the Air-Gapped Configuration.

For more detail regarding the Anchore Data Service, please see Anchore Data Service.

2.5.1 - Anchore Enterprise in an Air-Gapped Environment

This document is intended to be a complete reference guide to deploying Anchore Enterprise in an air-gapped environment. Use the print button to take this guide into your air-gapped environment.

Prerequisites

Please note that detailed deployment requirements can be otherwise found in Requirements

Kubernetes

• Kubernetes (>=1.23)
• Install command-line tools Helm (>=3.8) and Docker static binary (low side and high side)
• Install command-line tool kubectl (high side)
• Helm is the package manager for Kubernetes used to manage Kubernetes applications using Helm charts.
• Kubectl communicates with the Kubernetes API server to send commands and manage resources within a Kubernetes cluster.
• Helm and Docker (client/static binary) can be installed as standalone binaries. The Docker static binary is only needed to pull/download/save/load Docker images.
• Kubectl can be installed as a standalone binary.
• For an air-gapped deployment:
• Helm and Docker should be installed on an Internet-facing system (can be a normal workstation on the low side) as well as the air-gapped system (can be the management system/control node on the high side).
• Kubectl should be installed on the air-gapped system (can be the management system/control node on the high side) to interact with the Kubernetes cluster.
• How to install (Helm, >=3.8): https://helm.sh/docs/intro/install/
• How to install (Docker, static binary): https://docs.docker.com/engine/install/binaries/
• How to install (kubectl): https://kubernetes.io/docs/tasks/tools/

Docker

• Install Docker static binary (low side)
• Install Docker Engine/CE (>=1.12) (high side)
• The Docker static binary is only needed to pull/download/save Docker images (on the low side).
• Docker Engine/CE is needed for the Anchore Enterprise deployment (on the high side).
• For an air-gapped deployment:
• The Docker static binary should be installed on an Internet-facing system (can be a normal workstation on the low side) and Docker Engine/CE should be installed on the air-gapped system.
• How to install (Docker, static binary): https://docs.docker.com/engine/install/binaries/
• How to install (Docker Engine/CE): https://docs.docker.com/engine/install/

Pull/Download images locally (from low side)

Kubernetes

1. Pull the latest Anchore Enterprise Helm chart and dependencies

helm repo add anchore https://charts.anchore.io
helm repo update
helm pull anchore/enterprise

• The “helm pull” command will create a .tgz file named: enterprise-“helm-chart-version”.tgz
• The file size will be small (under 1 MB).

2. Pull the latest Anchore Enterprise and dependent Docker images

docker pull docker.io/anchore/enterprise:v5.27.0
docker pull docker.io/anchore/enterprise-ui:v5.27.0
docker pull docker.io/bitnamilegacy/postgresql:16.6.0-debian-12-r2
docker pull docker.io/redis:7.4.6
docker pull docker.io/bitnamilegacy/kubectl:1.30
docker pull docker.io/postgres:13-bookworm

Docker

1. Download the latest Docker Compose file which should correspond to the latest/current version of Anchore Enterprise

curl https://docs.anchore.com/current/docs/deployment/docker_compose/docker-compose.yaml > docker-compose.yaml

2. Pull the latest Anchore Enterprise and dependent Docker images

docker pull docker.io/anchore/enterprise:v5.27.0
docker pull docker.io/anchore/enterprise-ui:v5.27.0
docker pull docker.io/postgres:16
docker pull docker.io/redis:7.4.6

Tag and push images to private container registry (from low side)

Kubernetes

1. Re-tag the pulled/downloaded Docker images with your private container registry

docker tag docker.io/anchore/enterprise:v5.27.0 <private container registry domain>/anchore/enterprise:v5.27.0
docker tag docker.io/anchore/enterprise-ui:v5.27.0 <private container registry domain>/anchore/enterprise-ui:v5.27.0
docker tag docker.io/bitnamilegacy/postgresql:16.6.0-debian-12-r2 <private container registry domain>/bitnamilegacy/postgresql:16.6.0-debian-12-r2
docker tag docker.io/redis:7.4.6 <private container registry domain>/redis:7.4.6
docker tag docker.io/bitnamilegacy/kubectl:1.30 <private container registry domain>/bitnamilegacy/kubectl:1.30
docker tag docker.io/postgres:13-bookworm <private container registry domain>/postgres:13-bookworm

2. Push the re-tagged Docker images up to your private container registry

docker push <private container registry domain>/anchore/enterprise:v5.27.0
docker push <private container registry domain>/anchore/enterprise-ui:v5.27.0
docker push <private container registry domain>/bitnamilegacy/postgresql:16.6.0-debian-12-r2
docker push <private container registry domain>/redis:7.4.6
docker push <private container registry domain>/bitnamilegacy/kubectl:1.30
docker push <private container registry domain>/postgres:13-bookworm

Docker

1. Re-tag the pulled/downloaded Docker images with your private container registry

docker tag docker.io/anchore/enterprise:v5.27.0 <private container registry domain>/anchore/enterprise:v5.27.0
docker tag docker.io/anchore/enterprise-ui:v5.27.0 <private container registry domain>/anchore/enterprise-ui:v5.27.0
docker tag docker.io/postgres:16 <private container registry domain>/postgres:16
docker tag docker.io/redis:7.4.6 <private container registry domain>/redis:7.4.6

2. Push the re-tagged Docker images up to your private container registry

docker push <private container registry domain>/anchore/enterprise:v5.27.0
docker push <private container registry domain>/anchore/enterprise-ui:v5.27.0
docker push <private container registry domain>/postgres:16
docker push <private container registry domain>/redis:7.4.6

Transfer source files (to high side)

Kubernetes

1. Transfer (via USB or other medium/method) the below files to the air-gapped system (on the high side):

• The Anchore Enterprise Helm chart .tgz file
• The Anchore-provided Anchore Enterprise license file

2. Untar the Anchore Enterprise Helm chart .tgz file on the air-gapped system

• The tarball will be extracted to a directory named: enterprise
• The directory will include the Anchore Enterprise Helm chart and the dependent PostgreSQL and Redis Helm charts.

3. Copy the Anchore Enterprise license file into the “enterprise” directory and if need be rename the file to: license.yaml

Docker

1. Transfer (via USB or other medium/method) the below files to the air-gapped system (on the high side):

• The Docker Compose file
• The Anchore-provided Anchore Enterprise license file

2. Place the Docker Compose and Anchore Enterprise license files into a designated working directory on the air-gapped system

• If need be, rename the Anchore Enterprise license file to: license.yaml

Deploy Anchore Enterprise (on high side)

Kubernetes

1. From the air-gapped system (on the high side), change into the “enterprise” directory that was extracted from the Anchore Enterprise Helm chart .tgz file and make a backup copy of the existing values.yaml file (as custom settings will be defined).

cd enterprise
cp values.yaml values-original.yaml

2. Modify the settings in the values.yaml file so that the default password for the admin user is set. Save the file once modified.

• The password for the admin user MUST be initially set via the “default_admin_password” parameter. The admin password can be changed post-installation via the UI.

- default_admin_password stanza under "Anchore Configuration Parameters" section

## @param anchoreConfig.default_admin_password The password for the Anchore Enterprise admin user
## This value is only used during creation of the admin user, cannot be used to change the password
  ##
  default_admin_password: <strong password_of_your_choosing>

3. Modify the settings in the values.yaml file so that the Anchore Enterprise, Anchore Enterprise UI, PostgreSQL, Redis, and bookworm Docker images are appropriately referenced relative to an installation from the private container registry. Save the file once modified.

• The Anchore Enterprise and Enterprise UI images should correspond to the latest/current version of Anchore Enterprise based on the previously pulled images.
• The “image” value for Anchore Enterprise and Enterprise UI should be modified to reflect the private container registry domain.
• The “tag” value for PostgreSQL and Redis should correspond to the version based on the previously pulled image.
• The “registry” value for PostgreSQL and Redis should be modified to reflect the private container registry domain.
• The “kubectlImage” value should be modified to reflect the private container registry domain.
• The “migrationPodImage” value should be modified to reflect the private container registry domain.

Example:

- Anchore Enterprise stanza under "Common Resource Parameters" section

## @param image Image used for all Anchore Enterprise deployments, excluding Anchore UI
## Only one of digest or tag should be used if using image.tag / image.digest, if both are specified it will default to using tag
## Ensure tag value is quoted so it's interpreted as a string
##
image: <private container registry domain>/anchore/enterprise:v5.27.0
  # registry: docker.io
  # repository: anchore/enterprise
  # tag: "v5.27.0"
  # digest: sha256:abcdef123456

- Anchore Enterprise UI stanza under "Anchore UI Parameters" section

ui:
  ## @param ui.image Image used for the Anchore UI container
  ## Ensure tag value is quoted so it's interpreted as a string
  ##
  image: <private container registry domain>/anchore/enterprise-ui:v5.27.0
    # registry: docker.io
    # repository: anchore/enterprise-ui
    # tag: v5.27.0
    # digest: sha256:abcdef123456

- postgresql stanza under "Anchore Database Parameters" section

  ## @param postgresql.image.repository Specifies the image repository to use for this chart.
  ## @param postgresql.image.registry Specifies the image registry to use for this chart.
  ## @param postgresql.image.tag Specifies the image to use for this chart.
  ## @param postgresql.image.pullSecrets Specifies the image pull secrets to use for this chart.
  ##
  image:
    repository: bitnamilegacy/postgresql
    registry: <private container registry domain>
    tag: 16.6.0-debian-12-r2
    pullSecrets:
      - anchore-enterprise-pullcreds

- ui-redis stanza under "Anchore UI Redis Parameters" section

  ## @param ui-redis.image.registry Specifies the image registry to use for this chart.
  ## @param ui-redis.image.repository Specifies the image repository to use for this chart.
  ## @param ui-redis.image.tag Specifies the image to use for this chart.
  ## @param ui-redis.image.pullSecrets Specifies the image pull secrets to use for this chart.
  ##
  image:
    registry: <private container registry domain>
    repository: redis
    tag: 7.4.6
    pullSecrets:
      - anchore-enterprise-pullcreds

- kubectlImage stanzas under "Common Resource Parameters", "Anchore Upgrade Job Parameters", and
"Anchore Object Store and Analysis Archive Migration" sections

## @param kubectlImage The image to use for the job's init container that uses kubectl to scale down deployments for the migration / upgrade
## This is only used in the osaaMigration and upgrade jobs.
##
kubectlImage: <private container registry domain>/bitnamilegacy/kubectl:1.30
  # registry: docker.io
  # repository: bitnamilegacy/kubectl
  # tag: "1.30"
  # digest: sha256:abcdef123456

 ## @param upgradeJob.kubectlImage The image to use for the upgrade job's init container that uses kubectl to scale down deployments before an upgrade
  ## This is only used in the preupgrade job. NOTE: This is deprecated. Please use `common.kubectlImage` instead.
  ##
  kubectlImage: <private container registry domain>/bitnamilegacy/kubectl:1.30

## @param osaaMigrationJob.kubectlImage The image to use for the job's init container that uses kubectl to scale down deployments for the migration
  ## This is only used in the osaaMigrationJob job. NOTE: This is deprecated. Please use `common.kubectlImage` instead.
  ##
  kubectlImage: <private container registry domain>/bitnamilegacy/kubectl:1.30

- migrationPodImage stanza under "Common Resource Parameters" section

## @param migrationPodImage The image reference to the migration pod
##
migrationPodImage: <private container registry domain>/postgres:13-bookworm

4. Modify the settings in the values.yaml file so that the environment variable “ANCHORE_DATA_SYNC_AUTO_SYNC_ENABLED” is set to false. This environment variable needs to be defined under the dataSyncer.extraEnv stanza. Save the file once modified.

• This setting governs downloading of feeds data by the Anchore data syncer service. As the deployment will be air-gapped, feeds data will be downloaded/uploaded manually via the anchorectl binary.

- dataSyncer stanza under "Anchore Data Syncer k8s Deployment Parameters" section

## @param dataSyncer.extraEnv Set extra environment variables for Anchore DataSyncer pods
  ##
  extraEnv:
    - name: ANCHORE_DATA_SYNC_AUTO_SYNC_ENABLED
      value: "false"

5. Perform the Helm deployment of Anchore Enterprise

• Follow the below steps from the Helm deployment guide:
• Installing the Chart: https://docs.anchore.com/current/docs/deployment/helm/
• Step 1: The NAMESPACE can be named: anchore
• Step 2: The license file should exist in the same directory as the extracted Anchore Enterprise Helm chart and the dependent PostgreSQL and Redis Helm charts - which would be the “enterprise” directory. If need be, the license file should also be renamed: license.yaml
• Step 3: This step can be skipped as a Kubernetes secret for DockerHub credentials will not be needed in an air-gapped deployment to pull/download Docker images.
• Step 4: A custom values file will not need to be created as the existing one (values.yaml) with custom-defined settings will be used.
• There is also no need to add the charts repository as the chart/dependencies would have been previously pulled and transferred to the air-gapped system (on the high side).
• RELEASE can be the same value as NAMESPACE and the variables can be exported as listed below.

export NAMESPACE=anchore
export RELEASE=anchore

The Helm command to deploy Anchore Enterprise would be as follows:

helm install ${RELEASE} -n ${NAMESPACE} /path/to/extracted/enterprise/directory

• The “helm install” will initiate the installation of Anchore Enterprise. Upon completion, the pod status can be checked per the below and should reflect READY 1/1 and STATUS Running for each pod.

kubectl get pods -n ${NAMESPACE}

- Example Output

kubectl get pods -n anchore
NAME                                                READY   STATUS    RESTARTS      AGE
anchore-enterprise-analyzer-5f7f97ffcf-6rtrn        1/1     Running   1 (72s ago)   20h
anchore-enterprise-api-587fb89495-sl2xn             1/1     Running   1 (72s ago)   20h
anchore-enterprise-catalog-7767d58d4f-6dsv7         1/1     Running   1 (72s ago)   20h
anchore-enterprise-datasyncer-558959869f-qp9nx      1/1     Running   1 (72s ago)   20h
anchore-enterprise-notifications-64ccbf9864-pl629   1/1     Running   1 (72s ago)   20h
anchore-enterprise-policy-6dc88b5df6-vrrcw          1/1     Running   1 (72s ago)   20h
anchore-enterprise-reports-569587dbf5-jjfz2         1/1     Running   1 (72s ago)   20h
anchore-enterprise-reportsworker-6bc7f7b4dd-7fnrn   1/1     Running   1 (72s ago)   20h
anchore-enterprise-simplequeue-7f848498df-64bxq     1/1     Running   1 (72s ago)   20h
anchore-enterprise-ui-6fd7d78449-2vc6l              1/1     Running   1 (72s ago)   20h
anchore-postgresql-0                                1/1     Running   1 (72s ago)   20h
anchore-ui-redis-master-0                           1/1     Running   1 (72s ago)   20h

• There should be 12 Anchore Enterprise pods in total which includes PostgreSQL and Redis.

Docker

1. From the air-gapped system (on the high side), change into the designated working directory where the Docker Compose and Anchore Enterprise license files were placed.

cd <designated working directory>

2. Modify the settings in the docker-compose.yaml file so that the default password for the admin user is set. Save the file once modified.

• The password for the admin user MUST be initially set via the “ANCHORE_ADMIN_PASSWORD” environment variable. This environment variable is listed by default under the “catalog” and “queue” services. The admin password can be changed post-installation via the UI.

- default "ANCHORE_ADMIN_PASSWORD" environment variable

environment:
  - ANCHORE_ADMIN_PASSWORD=<strong password of your choosing>

3. Modify the settings in the docker-compose.yaml file so that the Anchore Enterprise, Anchore Enterprise UI, PostgreSQL, and Redis Docker images are appropriately referenced relative to an installation from the private container registry for each Anchore Enterprise service. Save the file once modified.

• The Anchore Enterprise and Enterprise UI images should correspond to the latest/current version of Anchore Enterprise based on the previously pulled images.
• The “image” value should be modified to reflect the private container registry domain.
• The “repository:tag” should match exactly what’s listed within the private container registry.
• There should be 12 Anchore Enterprise services in total which includes PostgreSQL and Redis.

Example:

services:
  api:
    image: <private container registry domain>/anchore/enterprise:v5.27.0

  ui:
    image: <private container registry domain>/anchore/enterprise-ui:v5.27.0

  anchore-db:
    image: <private container registry domain>/postgres:16

  ui-redis:
    image: <private container registry domain>/redis:7.4.6

4. Modify the settings in the docker-compose.yaml file so that the environment variable “ANCHORE_DATA_SYNC_AUTO_SYNC_ENABLED” is set to false. This environment variable is listed by default under the “data-syncer” service. Save the file once modified.

• This setting governs downloading of feeds data by the Anchore data syncer service. As the deployment will be air-gapped, feeds data will be downloaded/uploaded manually via the anchorectl binary.

- data-syncer stanza

environment:
  - ANCHORE_DATA_SYNC_AUTO_SYNC_ENABLED=false

5. Perform the Docker deployment of Anchore Enterprise

• From within the designated working directory where the Docker Compose and Anchore Enterprise license files were placed, execute the below command.

docker compose up -d

• Upon completion, the container status can be checked per the below and should reflect STATUS (healthy) for each container.

docker ps

- Example Output

CONTAINER ID   IMAGE                           COMMAND                  CREATED         STATUS                   PORTS                          NAMES
f1cbeeb57d17   anchore/enterprise-ui:v5.27.0   "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   0.0.0.0:3000->3000/tcp         anchore-airgap-ui-1
9a31c0b9179e   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   8228/tcp                       anchore-airgap-policy-engine-1
4dbe734493ec   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   0.0.0.0:8228->8228/tcp         anchore-airgap-api-1
e9b28374d305   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   8228/tcp                       anchore-airgap-reports_worker-1
a59c7e637b29   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   0.0.0.0:8558->8228/tcp         anchore-airgap-reports-1
800e9d3e59d6   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   8228/tcp                       anchore-airgap-analyzer-1
cc990f7b6025   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   0.0.0.0:8668->8228/tcp         anchore-airgap-notifications-1
05b93536f286   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   0.0.0.0:8778->8228/tcp         anchore-airgap-data-syncer-1
569ebfec977b   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   8228/tcp                       anchore-airgap-catalog-1
128c2874c243   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   8228/tcp                       anchore-airgap-queue-1
efeadcbf1dbc   postgres:16                     "docker-entrypoint.s…"   4 minutes ago   Up 4 minutes (healthy)   0.0.0.0:5432->5432/tcp         anchore-airgap-anchore-db-1
2d23836db688   redis:7.4.6                     "docker-entrypoint.s…"   4 minutes ago   Up 4 minutes (healthy)   6379/tcp                       anchore-airgap-ui-redis-1

• There should be 12 Anchore Enterprise containers in total which includes PostgreSQL and Redis.

2.5.2 - Anchore Enterprise in an Air-Gapped Environment

This document is intended to be a complete reference guide to deploying Anchore Enterprise in an air-gapped environment. Use the print button to take this guide into your air-gapped environment.

Prerequisites

Please note that detailed deployment requirements can be otherwise found in Requirements

Kubernetes

• Command-line tools Helm (>=3.8) and Docker static binary (low side and high side)
• Command-line tool kubectl (high side)
• Helm is the package manager for Kubernetes used to manage Kubernetes applications using Helm charts.
• Kubectl communicates with the Kubernetes API server to send commands and manage resources within a Kubernetes cluster.
• Helm and Docker (client/static binary) can be installed as standalone binaries. The Docker static binary is only needed to pull/download/save/load Docker images.
• Kubectl can be installed as a standalone binary.
• For an air-gapped deployment:
• Helm and Docker should be installed on an Internet-facing system (can be a normal workstation on the low side) as well as the air-gapped system (can be the management system/control node on the high side).
• Kubectl should be installed on the air-gapped system (can be the management system/control node on the high side) to interact with the Kubernetes cluster.
• How to install (Helm, >=3.8): https://helm.sh/docs/intro/install/
• How to install (Docker, static binary): https://docs.docker.com/engine/install/binaries/
• How to install (kubectl): https://kubernetes.io/docs/tasks/tools/

Docker

• Install Docker static binary (low side)
• Install Docker Engine/CE (>=1.12) (high side)
• The Docker static binary is only needed to pull/download/save Docker images (on the low side).
• Docker Engine/CE is needed for the Anchore Enterprise deployment (on the high side).
• For an air-gapped deployment:
• The Docker static binary should be installed on an Internet-facing system (can be a normal workstation on the low side) and Docker Engine/CE should be installed on the air-gapped system.
• How to install (Docker, static binary): https://docs.docker.com/engine/install/binaries/
• How to install (Docker Engine/CE): https://docs.docker.com/engine/install/

Pull/Download images locally (from low side)

Kubernetes

1. Pull the latest Anchore Enterprise Helm chart and dependencies

helm repo add anchore https://charts.anchore.io
helm repo update
helm pull anchore/enterprise

• The “helm pull” command will create a .tgz file named: enterprise-“helm-chart-version”.tgz
• The file size will be small (under 1 MB).

2. Pull the latest Anchore Enterprise and dependent Docker images

docker pull docker.io/anchore/enterprise:v5.27.0
docker pull docker.io/anchore/enterprise-ui:v5.27.0 
docker pull docker.io/bitnamilegacy/postgresql:16.6.0-debian-12-r2
docker pull docker.io/redis:7.4.6
docker pull docker.io/bitnamilegacy/kubectl:1.30
docker pull docker.io/postgres:13-bookworm

3. Save the Anchore Enterprise and dependent Docker images into a single tar file for transfer to the high side

docker save -o <filename>.tar \
docker.io/anchore/enterprise:v5.27.0 \
docker.io/anchore/enterprise-ui:v5.27.0  \
docker.io/bitnamilegacy/postgresql:16.6.0-debian-12-r2 \
docker.io/redis:7.4.6 \
docker.io/bitnamilegacy/kubectl:1.30 \
docker.io/postgres:13-bookworm

Docker

1. Download the latest Docker Compose file which should correspond to the latest/current version of Anchore Enterprise

curl https://docs.anchore.com/current/docs/deployment/docker_compose/docker-compose.yaml > docker-compose.yaml

2. Pull the latest Anchore Enterprise and dependent Docker images

docker pull docker.io/anchore/enterprise:v5.27.0
docker pull docker.io/anchore/enterprise-ui:v5.27.0 
docker pull docker.io/postgres:16
docker pull docker.io/redis:7.4.6

3. Save the Anchore Enterprise and dependent Docker images into a single tar file for transfer to the high side

docker save -o <filename>.tar \
docker.io/anchore/enterprise:v5.27.0 \
docker.io/anchore/enterprise-ui:v5.27.0  \
docker.io/postgres:16 \
docker.io/redis:7.4.6

Transfer source files (to high side)

Kubernetes

1. Transfer (via USB or other medium/method) the below files to the air-gapped system (on the high side):

• The Anchore Enterprise Helm chart .tgz file
• The Docker images tar file
• The Anchore-provided Anchore Enterprise license file

2. Untar the Anchore Enterprise Helm chart .tgz file on the air-gapped system

• The tarball will be extracted to a directory named: enterprise
• The directory will include the Anchore Enterprise Helm chart and the dependent PostgreSQL and Redis Helm charts.

3. Copy the Anchore Enterprise license file into the “enterprise” directory and if need be rename the file to: license.yaml

4. Load and verify the Docker images locally on the air-gapped system

docker load -i <filename>.tar
docker images

5. Import the Docker images into the container runtime/Kubernetes cluster directly (from the air-gapped system) as the images may not be visible to the cluster although they are available locally

• For instance, if containerd or CRI-O is the container runtime - the ctr command can be used directly from the management system/worker node.

ctr images import <filename>.tar
ctr images ls

• If using Rancher (RKE), KIND, K9s, Minikube, etc. the procedure may vary so be sure to research accordingly.

Docker

1. Transfer (via USB or other medium/method) the below files to the air-gapped system (on the high side):

• The Docker Compose file
• The Docker images tar file
• The Anchore-provided Anchore Enterprise license file

2. Place the Docker Compose and Anchore Enterprise license files into a designated working directory on the air-gapped system

• If need be, rename the Anchore Enterprise license file to: license.yaml

3. Load and verify the Docker images locally on the air-gapped system

docker load -i <filename>.tar
docker images

Deploy Anchore Enterprise (on high side)

Kubernetes

1. From the air-gapped system (on the high side), change into the “enterprise” directory that was extracted from the Anchore Enterprise Helm chart .tgz file and make a backup copy of the existing values.yaml file (as custom settings will be defined).

cd enterprise
cp values.yaml values-original.yaml

2. Modify the settings in the values.yaml file so that the default password for the admin user is set. Save the file once modified.

• The password for the admin user MUST be initially set via the “default_admin_password” parameter. The admin password can be changed post-installation via the UI.

- default_admin_password stanza under "Anchore Configuration Parameters" section

## @param anchoreConfig.default_admin_password The password for the Anchore Enterprise admin user
## This value is only used during creation of the admin user, cannot be used to change the password
  ##
  default_admin_password: <strong password_of_your_choosing>

3. Modify the settings in the values.yaml file so that the Anchore Enterprise, Anchore Enterprise UI, PostgreSQL, Redis, and bookworm Docker images are appropriately referenced relative to an installation from local images. Save the file once modified.

• The Anchore Enterprise and Enterprise UI images should correspond to the latest/current version of Anchore Enterprise based on the previously pulled images.
• The “image” value for Anchore Enterprise and Enterprise UI should be modified to remove the “docker.io” registry as local images will be used.
• The “tag” value for PostgreSQL and Redis should correspond to the version based on the previously pulled image.
• The “registry” key for PostgreSQL and Redis should be commented out as local images will be used.
• The “migrationPodImage” value should be modified to remove the “docker.io” registry as a local image will be used.

Example:

- Anchore Enterprise stanza under "Common Resource Parameters" section

## @param image Image used for all Anchore Enterprise deployments, excluding Anchore UI
## Only one of digest or tag should be used if using image.tag / image.digest, if both are specified it will default to using tag
## Ensure tag value is quoted so it's interpreted as a string
##
image: anchore/enterprise:v5.27.0
  # registry: docker.io
  # repository: anchore/enterprise
  # tag: "v5.27.0"
  # digest: sha256:abcdef123456

- Anchore Enterprise UI stanza under "Anchore UI Parameters" section

ui:
  ## @param ui.image Image used for the Anchore UI container
  ## Ensure tag value is quoted so it's interpreted as a string
  ##
  image: anchore/enterprise-ui:v5.27.0 
    # registry: docker.io
    # repository: anchore/enterprise-ui
    # tag: "v5.27.0"
    # digest: sha256:abcdef123456

- postgresql stanza under "Anchore Database Parameters" section

  ## @param postgresql.image.repository Specifies the image repository to use for this chart.
  ## @param postgresql.image.registry Specifies the image registry to use for this chart.
  ## @param postgresql.image.tag Specifies the image to use for this chart.
  ## @param postgresql.image.pullSecrets Specifies the image pull secrets to use for this chart.
  ##
  image:
    repository: bitnamilegacy/postgresql
    #registry: docker.io
    tag: 16.6.0-debian-12-r2
    pullSecrets:
      - anchore-enterprise-pullcreds

- ui-redis stanza under "Anchore UI Redis Parameters" section

  ## @param ui-redis.image.registry Specifies the image registry to use for this chart.
  ## @param ui-redis.image.repository Specifies the image repository to use for this chart.
  ## @param ui-redis.image.tag Specifies the image to use for this chart.
  ## @param ui-redis.image.pullSecrets Specifies the image pull secrets to use for this chart.
  ##
  image:
    #registry: docker.io
    repository: redis
    tag: 7.4.6
    pullSecrets:
      - anchore-enterprise-pullcreds

- migrationPodImage stanza under "Common Resource Parameters" section

## @param migrationPodImage The image reference to the migration pod
##
migrationPodImage: postgres:13-bookworm

4. Modify the settings in the values.yaml file so that the environment variable “ANCHORE_DATA_SYNC_AUTO_SYNC_ENABLED” is set to false. This environment variable needs to be defined under the dataSyncer.extraEnv stanza. Save the file once modified.

• This setting governs downloading of feeds data by the Anchore data syncer service. As the deployment will be air-gapped, feeds data will be downloaded/uploaded manually via the anchorectl binary.

- dataSyncer stanza under "Anchore Data Syncer k8s Deployment Parameters" section

## @param dataSyncer.extraEnv Set extra environment variables for Anchore DataSyncer pods
  ##
  extraEnv:
    - name: ANCHORE_DATA_SYNC_AUTO_SYNC_ENABLED
      value: "false"

5. Perform the Helm deployment of Anchore Enterprise

• Follow the below steps from the Helm deployment guide:
• Installing the Chart: https://docs.anchore.com/current/docs/deployment/helm/
• Step 1: The NAMESPACE can be named: anchore
• Step 2: The license file should exist in the same directory as the extracted Anchore Enterprise Helm chart and the dependent PostgreSQL and Redis Helm charts - which would be the “enterprise” directory. If need be, the license file should also be renamed: license.yaml
• Step 3: This step can be skipped as a Kubernetes secret for DockerHub credentials will not be needed in an air-gapped deployment to pull/download Docker images.
• Step 4: A custom values file will not need to be created as the existing one (values.yaml) with custom-defined settings will be used.
• There is also no need to add the charts repository as the chart/dependencies would have been previously pulled and transferred to the air-gapped system (on the high side).
• RELEASE can be the same value as NAMESPACE and the variables can be exported as listed below.

export NAMESPACE=anchore
export RELEASE=anchore

The Helm command to deploy Anchore Enterprise would be as follows:

helm install ${RELEASE} -n ${NAMESPACE} /path/to/extracted/enterprise/directory

• The “helm install” will initiate the installation of Anchore Enterprise. Upon completion, the pod status can be checked per the below and should reflect READY 1/1 and STATUS Running for each pod.

kubectl get pods -n ${NAMESPACE}

- Example Output

kubectl get pods -n anchore
NAME                                                READY   STATUS    RESTARTS      AGE
anchore-enterprise-analyzer-5f7f97ffcf-6rtrn        1/1     Running   1 (72s ago)   20h
anchore-enterprise-api-587fb89495-sl2xn             1/1     Running   1 (72s ago)   20h
anchore-enterprise-catalog-7767d58d4f-6dsv7         1/1     Running   1 (72s ago)   20h
anchore-enterprise-datasyncer-558959869f-qp9nx      1/1     Running   1 (72s ago)   20h
anchore-enterprise-notifications-64ccbf9864-pl629   1/1     Running   1 (72s ago)   20h
anchore-enterprise-policy-6dc88b5df6-vrrcw          1/1     Running   1 (72s ago)   20h
anchore-enterprise-reports-569587dbf5-jjfz2         1/1     Running   1 (72s ago)   20h
anchore-enterprise-reportsworker-6bc7f7b4dd-7fnrn   1/1     Running   1 (72s ago)   20h
anchore-enterprise-simplequeue-7f848498df-64bxq     1/1     Running   1 (72s ago)   20h
anchore-enterprise-ui-6fd7d78449-2vc6l              1/1     Running   1 (72s ago)   20h
anchore-postgresql-0                                1/1     Running   1 (72s ago)   20h
anchore-ui-redis-master-0                           1/1     Running   1 (72s ago)   20h

• There should be 12 Anchore Enterprise pods in total which includes PostgreSQL and Redis.

Docker

1. From the air-gapped system (on the high side), change into the designated working directory where the Docker Compose and Anchore Enterprise license files were placed.

cd <designated working directory>

2. Modify the settings in the docker-compose.yaml file so that the default password for the admin user is set. Save the file once modified.

• The password for the admin user MUST be initially set via the “ANCHORE_ADMIN_PASSWORD” environment variable. This environment variable is listed by default under the “catalog” and “queue” services. The admin password can be changed post-installation via the UI.

- default "ANCHORE_ADMIN_PASSWORD" environment variable

environment:
  - ANCHORE_ADMIN_PASSWORD=<strong password of your choosing>

3. Modify the settings in the docker-compose.yaml file so that the Anchore Enterprise, Anchore Enterprise UI, PostgreSQL, and Redis Docker images are appropriately referenced relative to an installation from local images for each Anchore Enterprise service. Save the file once modified.

• The Anchore Enterprise and Enterprise UI images should correspond to the latest/current version of Anchore Enterprise based on the previously pulled images.
• The “image” value should be modified to remove the “docker.io” registry as local images will be used.
• The “repository:tag” should match exactly what’s listed on the local system when running the “docker images” command.
• There should be 12 Anchore Enterprise services in total which includes PostgreSQL and Redis.

Example:

services:
  api:
    image: anchore/enterprise:v5.27.0

  ui:
    image: anchore/enterprise-ui:v5.27.0 

  anchore-db:
    image: postgres:16

  ui-redis:
    image: redis:7.4.6

4. Modify the settings in the docker-compose.yaml file so that the environment variable “ANCHORE_DATA_SYNC_AUTO_SYNC_ENABLED” is set to false. This environment variable is listed by default under the “data-syncer” service. Save the file once modified.

• This setting governs downloading of feeds data by the Anchore data syncer service. As the deployment will be air-gapped, feeds data will be downloaded/uploaded manually via the anchorectl binary.

- data-syncer stanza

environment:
  - ANCHORE_DATA_SYNC_AUTO_SYNC_ENABLED=false

5. Perform the Docker deployment of Anchore Enterprise

• From within the designated working directory where the Docker Compose and Anchore Enterprise license files were placed, execute the below command.

docker compose up -d

• Upon completion, the container status can be checked per the below and should reflect STATUS (healthy) for each container.

docker ps

- Example Output

CONTAINER ID   IMAGE                           COMMAND                  CREATED         STATUS                   PORTS                          NAMES
f1cbeeb57d17   anchore/enterprise-ui:v5.27.0   "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   0.0.0.0:3000->3000/tcp         anchore-airgap-ui-1
9a31c0b9179e   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   8228/tcp                       anchore-airgap-policy-engine-1
4dbe734493ec   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   0.0.0.0:8228->8228/tcp         anchore-airgap-api-1
e9b28374d305   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   8228/tcp                       anchore-airgap-reports_worker-1
a59c7e637b29   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   0.0.0.0:8558->8228/tcp         anchore-airgap-reports-1
800e9d3e59d6   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   8228/tcp                       anchore-airgap-analyzer-1
cc990f7b6025   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   0.0.0.0:8668->8228/tcp         anchore-airgap-notifications-1
05b93536f286   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   0.0.0.0:8778->8228/tcp         anchore-airgap-data-syncer-1
569ebfec977b   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   8228/tcp                       anchore-airgap-catalog-1
128c2874c243   anchore/enterprise:v5.27.0      "/docker-entrypoint.…"   4 minutes ago   Up 3 minutes (healthy)   8228/tcp                       anchore-airgap-queue-1
efeadcbf1dbc   postgres:16                     "docker-entrypoint.s…"   4 minutes ago   Up 4 minutes (healthy)   0.0.0.0:5432->5432/tcp         anchore-airgap-anchore-db-1
2d23836db688   redis:7.4.6                     "docker-entrypoint.s…"   4 minutes ago   Up 4 minutes (healthy)   6379/tcp                       anchore-airgap-ui-redis-1

• There should be 12 Anchore Enterprise containers in total which includes PostgreSQL and Redis.

2.6 - Deploying AnchoreCTL

In this section you will learn how to deploy and configure AnchoreCTL, the Anchore Enterprise Command Line Interface.

AnchoreCTL is published as a simple binary available for download either from your Anchore Enterprise deployment or Anchore’s release site.

Using AnchoreCTL, you can manage and inspect all aspects of your Anchore Enterprise deployments, either as a manual human-readable configuration/instrumentation/control tool or as a CLI that is designed to be used in scripted environments such as CI/CD and other automation environments.

Installation

AnchoreCTL’s major and minor release version coincides with the release version of Anchore Enterprise, however patch versions may differ. For example,

• Enterprise v5.27.0
• AnchoreCTL v5.27.1

MacOS / Linux

Download a local (from your Anchore Enterprise deployment) or remote (from Anchore servers) version without installation:

Linux Intel/AMD64 [Local]

curl -X GET "https://my-anchore.example.com/v2/system/anchorectl?operating_system=linux&architecture=amd64" -H "accept: */*" | tar -zx anchorectl

[Remote]

curl -o anchorectl.tar.gz https://anchorectl-releases.anchore.io/anchorectl/v5.27.1/anchorectl_5.27.1_linux_amd64.tar.gz

MacOS Intel/AMD64 [Local]

curl -X GET "https://my-anchore.example.com/v2/system/anchorectl?operating_system=darwin&architecture=amd64" -H "accept: */*"

[Remote]

curl -o anchorectl.tar.gz https://anchorectl-releases.anchore.io/anchorectl/v5.27.1/anchorectl_5.27.1_darwin_amd64.tar.gz

MacOS ARM/M-Series [Local]

curl -X GET "https://my-anchore.example.com/v2/system/anchorectl?operating_system=darwin&architecture=arm64" -H "accept: */*"

[Remote]

curl -o anchorectl.tar.gz https://anchorectl-releases.anchore.io/anchorectl/v5.27.1/anchorectl_5.27.1_darwin_arm64.tar.gz

Windows

For windows, you must specify the version of AnchoreCTL to download if using a script. [Local]

curl -X GET "https://my-anchore.example.com/v2/system/anchorectl?operating_system=windows&architecture=amd64" -H "accept: */*"

[Remote]

curl -o anchorectl.zip https://anchorectl-releases.anchore.io/anchorectl/v5.27.1/anchorectl_5.27.1_windows_amd64.zip

Install a Specific AnchoreCTL Version

Replace <DESTINATION_DIR> with /usr/local/bin (for example)

curl -sSfL  https://anchorectl-releases.anchore.io/anchorectl/install.sh  | sh -s -- -b <DESTINATION_DIR> v5.27.1

Configuration

Once AnchoreCTL has been installed, learn about AnchoreCTL Configuration.

3 - What is Anchore Enterprise

Anchore Enterprise is a software supply chain security platform that uses software bills of materials (SBOMs) to provide continuous visibility, vulnerability detection, policy enforcement, and compliance management for container images, source code repositories, and filesystem artifacts. It is designed for organizations that need to secure software at scale across development, CI/CD, and production environments.

How Anchore Enterprise Secures the Software Supply Chain

Anchore Enterprise takes a data-driven approach to software supply chain security. At the core of every operation is a high-fidelity SBOM that captures detailed metadata about software components, dependencies, licenses, file permissions, and more. This SBOM becomes the foundation for all downstream security analysis — see SBOMs for what an SBOM is in the context of Anchore Enterprise and the full set of uses a stored SBOM supports.

Generate and Store SBOMs

Anchore Enterprise automatically generates SBOMs when analyzing container images or source code. SBOMs can be generated server-side (centralized analysis) or locally on a CI runner using AnchoreCTL (distributed analysis). Anchore Enterprise stores all SBOMs in a centralized repository, enabling continuous monitoring for new vulnerabilities even after deployment. SBOMs can be exported in industry-standard formats including SPDX and CycloneDX.

Identify Vulnerabilities and Security Risks

Using the SBOM, Anchore Enterprise matches software components against multiple vulnerability data sources including the National Vulnerability Database (NVD), GitHub Security Advisories (GHSA), and vendor-specific feeds for distributions like RHEL, Debian, Ubuntu, Alpine, and more. A precision matching algorithm selects the most accurate data source for each component, reducing false positives and false negatives. Anchore Enterprise also enriches vulnerability data with EPSS (Exploit Prediction Scoring System) scores and CISA KEV (Known Exploited Vulnerabilities) status to help prioritize remediation.

Beyond vulnerabilities, Anchore Enterprise detects malware using ClamAV signatures, identifies embedded secrets and credentials, and flags misconfigurations.

Enforce Compliance with Policy-as-Code

Anchore Enterprise includes a policy engine that evaluates SBOMs and their associated scan results against customizable rules. Policies use a gate-and-trigger model where gates define categories of checks (vulnerabilities, licenses, file permissions, secrets, metadata) and triggers define specific conditions within each gate. Policy evaluations return pass, warn, or fail results that can be used to gate CI/CD pipelines, block non-compliant deployments via Kubernetes admission control, or generate compliance reports.

Anchore Enterprise ships with pre-built policy packs mapped to industry standards including NIST 800-53, FedRAMP, CIS Benchmarks, and DoD requirements.

Monitor Runtime Environments

Anchore Enterprise integrates with Kubernetes and Amazon ECS to maintain a real-time inventory of container images running in production. The Kubernetes Inventory Agent and ECS Inventory Agent report running workloads back to Anchore Enterprise, enabling continuous policy evaluation and vulnerability monitoring of live deployments. Combined with the Kubernetes Admission Controller, organizations can prevent non-compliant images from being deployed.

Key Components

Learn More

• SBOMs for the foundational concept Anchore Enterprise is built around
• Anchore Enterprise Capabilities for a detailed breakdown of features
• Architecture Overview for the service-level architecture
• Core Concepts for foundational concepts like SBOMs, images, policies, and remediation
• Anchore Data Service for vulnerability data sources and synchronization

3.1 - Anchore Enterprise Capabilities

Anchore Enterprise provides a comprehensive set of capabilities for securing the software supply chain, from SBOM generation and management through vulnerability remediation and compliance enforcement. It builds and integrates Anchore’s proven open source tooling; Syft, Grype and more.

SBOM Generation

Anchore Enterprise generates SBOMs using Syft, Anchore’s open-source SBOM tool. Both AnchoreCTL (the command-line client) and the server-side Analyzer embed Syft, so SBOMs produced locally on a CI runner, on a developer workstation, or centrally by the Anchore Enterprise deployment are consistent in structure and fidelity.

Two analysis modes are supported:

• Distributed analysis — AnchoreCTL generates the SBOM locally on a CI runner or workstation and uploads the result to Anchore Enterprise. Image content never leaves the build environment.
• Centralized analysis — The Analyzer service pulls images from registries, unpacks them, and generates SBOMs server-side. Required for malware scanning.

See SBOM Generation for detailed workflows.

High-Fidelity SBOM Content

Anchore Enterprise generates SBOMs that include a rich superset of data beyond what standard SBOM formats capture. This additional metadata enables detection of secrets, file permissions issues, misconfigurations, and malware — in addition to standard package identification.

Anchore Enterprise SBOMs identify:

• Open source and proprietary packages with ecosystem metadata (OS, language, binary)
• Nested dependencies in archive files (JAR, WAR, EAR, and more)
• Package details including name, version, creator, and license information
• Filesystem metadata including file name, size, permissions, creation time, modification time, and hashes
• Malware and cryptominers (via ClamAV signatures)
• Embedded secrets, keys, and credentials

Supported Ecosystems

Anchore Enterprise supports the following packaging ecosystems for SBOM content identification:

Operating System Packages: RPM, DEB, APK, Linux kernel archives (vmlinuz), Linux kernel modules (ko)

Language Packages: C/C++ (conan), Dart (pubs), Dotnet (deps.json), Elixir (mix), Erlang (rebar3), Go (go.mod, Go binaries), Haskell (cabal, stack), Java (jar, ear, war, par, sar, nar, native-image), JavaScript (npm, yarn), Jenkins Plugins (jpi, hpi), Nix (outputs in /nix/store), Objective-C (cocoapods), PHP (composer), Python (wheel, egg, poetry, requirements.txt), Ruby (gem), Rust (cargo.lock), Swift (cocoapods, swift-package-manager)

Binary Detection: Apache httpd, BusyBox, Consul, Golang, HAProxy, Helm, Java, Memcached, Node.js, PHP, Perl, PostgreSQL, Python, Redis, Rust, Traefik

SBOM Management

Generated SBOMs — whether produced by Anchore Enterprise or imported from external tooling — are stored in a centralized repository. Anchore Enterprise continuously re-evaluates stored SBOMs as new vulnerability data or policy rules arrive, so existing artifacts do not need to be re-scanned to pick up newly disclosed issues. This storage-first model turns SBOMs from a point-in-time artifact into an ongoing source of insight.

Insights delivered from stored SBOMs include:

• Vulnerability matching — SBOMs are matched against vulnerability feeds from the Anchore Data Service on every sync cycle, with EPSS and CISA KEV enrichment applied.
• Policy evaluation — Policies are re-evaluated automatically when the SBOM, the policy, or the underlying data feeds change.
• Drift detection — Changes between successive SBOMs for the same artifact are surfaced (see below).
• Secrets, malware, and misconfiguration findings — Rich SBOM metadata drives additional checks beyond CVE matching.
• Application-level aggregation — Per-image SBOMs roll up into application groups for program-wide visibility.

See SBOM Management for detailed workflows.

SBOM Drift Detection

Anchore Enterprise detects changes in SBOMs between builds — components added, removed, or changed. Policy rules can alert or block deployments when unexpected changes occur, helping identify developer errors, unauthorized modifications, or supply chain attacks. See SBOM Drift for more information.

SBOM Export and Compliance

SBOMs can be exported via the UI or API in SPDX and CycloneDX formats, as well as Anchore’s native Syft JSON format. Anchore Enterprise can export aggregated SBOMs for entire applications to meet customer and federal compliance requirements including Executive Order 14028 and NTIA minimum element guidelines.

Vulnerability and Security Scanning

Anchore Enterprise scans for vulnerabilities and security risks at every stage of the software development process: source code repositories, CI/CD pipelines, container registries, and runtime environments.

Precision Vulnerability Matching

Anchore Enterprise applies a precision matching algorithm that selects the most accurate vulnerability data source for each component. When the SBOM identifies a specific Linux distribution (such as RHEL or Ubuntu), Anchore Enterprise automatically uses that vendor’s security advisory feed rather than generic NVD data. This approach significantly reduces both false positives and false negatives.

Multiple Vulnerability Data Sources

Vulnerability data is sourced from 20+ providers, including the National Vulnerability Database (NVD), GitHub Security Advisories (GHSA), and vendor-specific feeds for all major Linux distributions. Anchore also maintains a curated dataset of known false-positive matches for automatic suppression. See Anchore Data Service for the complete list of sources.

EPSS and KEV Enrichment

Vulnerability findings are enriched with EPSS (Exploit Prediction Scoring System) scores that provide a probability estimate of exploitation, and CISA KEV (Known Exploited Vulnerabilities) flags that identify vulnerabilities with confirmed active exploitation in the wild. These data points help security teams prioritize remediation based on real-world risk.

Zero-Day Vulnerability Response

When a zero-day vulnerability is disclosed, Anchore Enterprise can instantly identify impacted components by querying stored SBOMs. There is no need to re-scan images or repositories — the existing SBOM data is matched against the updated vulnerability records.

Malware Detection

Anchore Enterprise scans container image layers for malware, cryptominers, and other malicious content using ClamAV signatures that are kept current through the Anchore Data Service.

Vulnerability Management and Remediation

Anchore Enterprise provides tools beyond detection to help teams manage and remediate security findings efficiently.

Manage False Positives

Anchore Enterprise reduces false positives through precision matching, Anchore-curated match exclusions, and user-defined corrections. Corrections allow teams to override CPE-based matching for specific packages, improving accuracy over time. Allowlists and time-limited allowlists provide exceptions for known acceptable risks.

VEX Annotations

Anchore Enterprise supports VEX (Vulnerability Exploitability eXchange) annotations that allow teams to document the exploitability status of specific vulnerabilities. Annotations can be set to Not Affected, Affected, Fixed, or Under Investigation, and can include action statements describing planned remediation. VEX documents can be exported in CycloneDX and OpenVEX formats.

Reporting and Notifications

Anchore Enterprise includes a reporting service with scheduled report generation, filterable by vulnerability severity, annotation status, and account scope. Reports can be exported as CSV or JSON. Notifications can be routed through webhooks, Slack, Jira, and email to alert teams when vulnerability states change, policy evaluations update, or analysis completes.

Policy Enforcement and Compliance

Anchore Enterprise includes a policy engine that enables automated compliance checking against customizable rules, industry standards, and regulatory requirements.

Gate-and-Trigger Policy Model

Policies use a gate-and-trigger model. Gates define categories of checks (vulnerabilities, licenses, secrets, file permissions, metadata), and triggers define specific conditions within each gate. Each trigger evaluation produces a stop, warn, or go action. Multiple rule sets can be combined into a single policy and mapped to specific registries, repositories, or tags.

See Policies for more information.

Pre-Built Policy Packs

Anchore Enterprise ships with policy packs mapped to common compliance standards:

• FedRAMP — Validates container images against FedRAMP Vulnerability Scanning Requirements and controls specified in NIST 800-53 Rev 5 and NIST 800-190.
• DISA Image Creation and Deployment Guide — Aligns with DoD Container Image Creation and Deployment Guide requirements.
• DoD Iron Bank — Validates images against U.S. Air Force security standards at Platform One and Iron Bank.
• CIS — Validates against container image best practices and a subset of NIST 800-53 and NIST 800-190 controls. Customizable for alignment with CIS Benchmarks.
• NIST — Validates content against NIST 800-53 and NIST 800-190 controls.

DISA STIG Compliance

Anchore Enterprise can scan container images against DISA Security Technical Implementation Guides (STIGs). Scan results are output in OASIS Heimdall Data Format (OHDF) and can be converted to XCCDF and CKL formats for import into STIG Viewer using MITRE SAF CLI tools.

CI/CD Pipeline Integration

Policies can be enforced directly in CI/CD pipelines using AnchoreCTL. The anchorectl image check command evaluates images against the active policy and returns a pass/fail result that can gate pipeline progression. Distributed analysis mode allows SBOM generation to happen locally on CI runners for faster feedback.

Kubernetes Admission Control

The Kubernetes Admission Controller evaluates container images against Anchore Enterprise policies before allowing deployment. Images that fail policy evaluation can be blocked, providing a runtime enforcement point for production environments.

Runtime Monitoring

Anchore Enterprise integrates with container orchestration platforms to provide continuous visibility into running workloads.

Kubernetes Runtime Inventory

The Kubernetes Inventory Agent (anchore-k8s-inventory) runs inside your cluster and continuously reports running container images back to Anchore Enterprise. This enables real-time vulnerability monitoring and policy compliance checking of production workloads.

ECS Runtime Inventory

The ECS Inventory Agent (anchore-ecs-inventory) provides the same runtime inventory capability for Amazon ECS environments.

Open Source Dependency and License Management

Anchore Enterprise identifies open source dependencies incorporated at any stage of the software lifecycle, including both direct and transitive dependencies. License information is extracted for all identified packages, and license policies can be configured to enforce compliance with organizational open source requirements.

Related Topics

• What is Anchore Enterprise
• Architecture Overview
• Core Concepts
• Anchore Data Service

3.2 - Architecture Overview

Anchore Enterprise is a distributed application deployed as a set of container images that communicate through RESTful APIs and a shared PostgreSQL database. The platform can be deployed on Kubernetes (via Helm), Docker Compose, or as a pre-configured cloud image. Each service runs independently and can be scaled horizontally to meet throughput requirements.

Services

API Service

The API service is the primary external-facing gateway for Anchore Enterprise. All client interactions — from AnchoreCTL, the web UI, and third-party integrations — route through this service. It exposes a RESTful API (v2) that provides access to image management, policy evaluation, vulnerability queries, user and account administration, SBOM operations, reporting, and system configuration.

Catalog

The catalog is the central state manager. It coordinates image lifecycle operations, tracks analysis state, manages subscriptions and event notifications, and provides data access to all other services from the backend PostgreSQL database. The catalog also handles artifact lifecycle policies (automatic archiving and deletion), garbage collection, and Kubernetes runtime inventory tracking.

Analyzer

The analyzer generates SBOMs from container images and source repositories. It unpacks image layers, catalogs all software packages and dependencies, detects malware using ClamAV signatures, searches for embedded secrets, and extracts filesystem metadata. Each analyzer instance processes one artifact at a time; scaling analyzer replicas increases parallel analysis throughput.

In distributed analysis mode, SBOM generation happens locally on the AnchoreCTL client and the resulting SBOM is uploaded to Anchore Enterprise for evaluation — bypassing the need for the analyzer to pull images directly.

Policy Engine

The policy engine loads SBOMs and evaluates them against the configured policy rules. It uses a gate-and-trigger model where each gate (vulnerabilities, licenses, secrets, file permissions, metadata) contains triggers with configurable parameters. The policy engine also handles vulnerability matching, applying the precision matching algorithm against the appropriate data feeds, and incorporates EPSS scores and KEV status into results. Policy evaluation results are stored and returned as pass, warn, or fail outcomes.

Data Syncer

The data syncer periodically downloads and normalizes datasets from the hosted Anchore Data Service. These datasets include vulnerability databases from 20+ sources, CISA KEV annotations, EPSS exploit prediction scores, ClamAV malware signatures, and STIG compliance profiles. By default, the data syncer checks for updates hourly. In air-gapped deployments, data synchronization is performed manually using AnchoreCTL.

Reports and Reports Worker

The reports service provides a GraphQL-based API for querying vulnerability, policy, and inventory data across the deployment. Users can create, schedule, and export reports in CSV or JSON format. The reports worker handles asynchronous report generation and scheduled report execution in t