Anchore SBOM - SBOM Management

1 - How It Works

SBOM management in Anchore Enterprise covers the full Software Bill of Materials (SBOM) lifecycle — from generation and import through organization, vulnerability scanning, and compliance evaluation. SBOMs can be generated from source repositories and container images using AnchoreCTL as part of a command-line or CI/CD workflow, or by submitting artifacts to the Anchore API. External SBOMs can be imported in SPDX, CycloneDX, and Syft native formats; on import, each document is validated for schema conformance and data requirements, and Anchore Enterprise calculates an SBOM Quality score based on document completeness metrics — including whether artifacts, dependencies, author, supplier, and timestamp are documented. Imported SBOMs are queued for vulnerability scanning using a first-in, first-out (FIFO) queue that performs a full rescan of the imported SBOM inventory every six hours as new vulnerability data becomes available. SBOMs can be organized into groups and versioned applications to reflect how teams build and deliver software; policy compliance can be evaluated against imported SBOMs using the Vulnerabilities gate, producing a pass or fail verdict with a summary of findings by action, severity, and allowlisted entries.

See the video below for a walkthrough of the SBOM management capabilities in Anchore Enterprise:

Specific topics related to the SBOM management framework can be referenced per the links below:

• Manage Imported SBOMs
• Observe Applications in Enterprise
• Anchore Enterprise Application Groups
• SBOM Generation and Management from Source Repository - Anchore API

Generate SBOMs for Anchore-managed Assets

You can generate SBOMs using AnchoreCTL as part of a command-line or CI/CD workflow, by pulling content from a registry, or by submitting an artifact to the Anchore API.

Once generated, SBOMs can be managed via the command line, API, or GUI — supporting grouping, annotation, and search across artifact metadata, vulnerability findings, and policy evaluation results.

Manage External SBOMs

Anchore Enterprise supports importing SBOMs generated outside of Anchore — whether from other SCA tools or vendor sources — providing comprehensive visibility across all software components, beyond what is captured through standard container analysis.

Import External SBOMs

External SBOMs can be imported in SPDX, CycloneDX, and Syft native formats. Imported SBOMs are validated for schema conformance and data requirements for vulnerability scanning.

The SBOM formats supported for upload via the experimental SBOM management features are:

• CycloneDX
  • JSON: Versions 1.2–1.6
  • XML: Versions 1.0–1.6
• SPDX
  • JSON: Versions 2.2–2.3
  • Tag-Value: Versions 2.1–2.3
  • Initial SPDX 3.0 support for JSON and Tag-Value — upload and download are supported, but content and vulnerability analysis are not functional.
• Syft

For a step-by-step guide to importing and managing SBOMs in the GUI, see Manage Imported SBOMs.

Document Insights

When importing an external SBOM, Anchore Enterprise calculates a set of document insights that describe the properties of the SBOM document, indicating various quality metrics and resulting in an overall SBOM Quality score.

The metrics included in the document insights are:

• Valid Format:
  • True if the given document can be identified as a valid SBOM of one of these formats:
    • CycloneDX
    • SPDX
    • Syft
• Valid Schema:
  • True if the filetype can be identified as one of:
    • json
    • xml
    • spdx (tag-value)
• Supported Format:
  • True if the given document format is within the set of formats that Anchore Enterprise can inspect for further insights. This set is:
    • CycloneDX
    • SPDX
    • Syft
• Supported Schema:
  • True if the given document filetype is within the set of filetypes that Anchore Enterprise can inspect for further insights. This set is:
    • json
    • xml
    • spdx (tag-value)
• Artifacts Documented:
  • True if the given document contains a set of artifacts or packages.
    • CycloneDX
      • True if the document contains a components list of non-zero length.
    • SPDX
      • True if the document contains a packages list of non-zero length.
    • Syft
      • True if the document contains an artifacts list of non-zero length.
• Dependencies Documented:
  • True if the given document contains a set of dependencies.
    • CycloneDX
      • True if the document contains a dependencies list of non-zero length.
    • SPDX
      • True if the document contains a relationships list of non-zero length.
    • Syft
      • True if the document contains an artifactRelationships list of non-zero length.
• Author Documented:
  • True if the given document contains metadata on the author of the document.
    • CycloneDX
      • True if the metadata object of the given document contains either a non-null manufacturer value or an authors list of non-zero length.
    • SPDX
      • True if the creationInfo object of the given document contains a creators list of non-zero length.
    • Syft
      • Not present in the Syft specification.
• Supplier Documented:
  • True if the given document contains metadata on the supplier of the artifacts.
    • CycloneDX
      • True if the metadata object of the given document contains a non-null supplier value.
    • SPDX
      • True if entries in the packages list of the given document contain a supplier value that is not empty and is not equal to NOASSERTION.
    • Syft
      • Not present in the Syft specification.
• Document Timestamp:
  • True if the given document contains metadata on the creation date-time of the document.
    • CycloneDX
      • True if the metadata object of the given document contains a non-null timestamp value.
    • SPDX
      • True if the creationInfo object of the given document contains a non-null created value.
    • Syft
      • Not present in the Syft specification.
• SBOM Quality:
  • The percentage of the above metrics that are True for the given document.

Performance Considerations

Though no explicit limits are enforced, 10,000 SBOMs and 1,000 groups have been used as the target for optimal performance.

The SBOM scanning queue performs a full rescan of the imported SBOM inventory every six hours using a first-in, first-out (FIFO) queue, meaning the oldest SBOMs are scanned first.

For more information on the performance and configuration of the scanning queue, see Imported SBOM Scanning.

SBOM Management API (Experimental)

Appropriate user permissions are required to access these API endpoints.

2 - Manage Imported SBOMs

Use the Anchore Enterprise GUI to import, organize, and analyze external SBOMs. This page covers the full imported SBOM workflow — from the import dialog through vulnerability and compliance results.

Import an SBOM

To import an external SBOM, navigate to the Imported SBOMs view via the left navigation panel. In the top-right of the page, select the Import SBOM button.

In the Import an SBOM dialog, provide the following information:

• SBOM Name: A name for the SBOM document
• Version: A version for the SBOM document
• Type: Optionally, provide a type describing the entity represented by the SBOM. Must be one of the following: application, container, device, file, filesystem, firmware, library, module, virtual_machine_disk, or unknown
• Groups: Optionally, select one or more SBOM groups with which to associate the imported SBOM
• Annotations: Optionally, add any annotations to store with the imported SBOM — for example, a Vendor name for the application or module represented by the SBOM
• SBOM File: Select the SBOM document to import

View Document Insights

When an SBOM is imported, Anchore Enterprise calculates a set of document insights describing the properties of the SBOM document. These insights indicate various quality metrics and result in an overall SBOM Quality score. For a full breakdown of each metric, see Document Insights.

Note: Support for xml and tag-value formats is achieved by converting the stored document to Syft json before inspection. Document insights are calculated based on the converted version.

View SBOM Contents

To view the contents of an imported SBOM, select the Contents tab.

The Contents tab displays a list of packages, versions, and associated licenses for the current SBOM.

Organize Imported SBOMs

Imported SBOMs can be placed into groups to reflect logical organization structures — for example, by vendor, product line, or team. Groups provide a way to manage and analyze related SBOMs together, enabling aggregate visibility into software composition and security health across a collection of artifacts. Grouping can be done during import or after an SBOM has already been imported.

The SBOM Group Summary view shows the list of associated imported SBOMs along with their key attributes, including name, version, type, and SBOM Quality score. The group-level SBOM Quality score reflects the average quality score across all constituent SBOMs, giving a quick indication of overall documentation completeness for the group. Vulnerability results and compliance evaluations can also be viewed at the group level, aggregating findings across all SBOMs within the group.

View Vulnerabilities

Once imported, SBOMs are queued for vulnerability scanning. To view vulnerability results for an imported SBOM or SBOM group, select the Vulnerabilities tab.

The list of vulnerabilities can be filtered using the following criteria:

• Vulnerability Age: select the number of days since the last time a particular vulnerability has been reported
• Minimum Severity: select the desired minimum CVSS severity
• Minimum CVSS Score: select the desired minimum CVSS score

Select Reset Filters to revert all filters to their default values.

The Anchore Rank column provides a sequence value for prioritizing vulnerability review and remediation, based on the Anchore Score — a composite security index comprised of CVSS score and severity, EPSS percentage, and CISA KEV status. The higher the value, the higher the priority to address it.

Select Export CSV in the top-right to export all data for the filtered set of vulnerabilities. The CSV includes all data fields for the complete set of vulnerabilities matching the filter criteria, with a record for each vulnerability instance per affected package and SBOM.

Evaluate Compliance

Imported SBOMs can have policy evaluated against them. Policy support is currently limited to the Vulnerabilities gate. See SBOM Mapping for details on creating policy mappings for imported SBOMs.

To view compliance results, select the Compliance tab.

Details about the policy and rules evaluated are shown, including the Final Action and the overall Evaluation Result. A summary of findings by action, vulnerability severity, and allowlisted findings is also shown.

3 - Observe Applications in Enterprise

Observe Applications in Enterprise

You can use the Anchore Enterprise GUI to see a summary of the applications that have been collected into an application. From the application view, you can drill down into the source repositories or container images that make up the application, and browse their software bill of materials (SBOMs).

Related Topics

• View Applications from Image Containers
• View Applications from Source Repositories
• Work with Applications Generated from Image Containers
• Work with Applications Generated from Source Repositories
• Anchore Enterprise Application Groups

3.1 - View Applications from Image Containers

To work with image container data, you must first load the image container data into the Application view of Enterprise. Once your data is brought in, you can go to Applications to see the summary of the information. The information is categorized by applications, with sub-categories of application versions available from container images. For information about analyzing images, see Image Analysis. For information about adding Images, see Scanning Repositories.

When you select an application version, you will see a list of artifacts associated with that application version.

You can download a report for everything in the application or for an individual artifact. The application level download supports JSON format. Artifact level download supports JSON, SPDX, CycloneDX formats.

When you select an artifact link, you will see the analysis options for that artifact. You can then view information about the artifact, such as the policies set up, the vulnerabilities, software bill of materials (SBOM) contents, image metadata information, build summary, and action workbench.

If you want to set up policies, as well as mappings for an artifact, select *Policies to set them up there.

See Policies for more information. See Policy Mappings for more information.

3.2 - View Applications from Source Repositories

To work with source repository data, you must first use AnchoreCTL or the Anchore API to load the source repository into the Applications view of Enterprise.

Once your data is brought in, you can go to the Applications tab to see the summary of the information. The information is categorized by applications, with sub-categories of application versions available from source repositories.

When you select an application version, you will see a list of artifacts associated with that application version.

You can download a report for everything in the application or for an individual artifact. The application level download supports JSON format. Artifact level download supports JSON, SPDX, CycloneDX formats.

When you select an artifact link, you will see the analysis options for that artifact. You can then view information about the artifact, such as the policies set up, the vulnerabilities, software bill of materials (SBOM) contents, and source metadata information.

If you want to set up policies, as well as mappings for an artifact, select the Policies tab and set them up there.

For information about policies, see Policies. For information about adding policy mapping, see Policy Mappings.

3.3 - Work with Applications Generated from Image Containers

To work with image container data in Anchore Enterprise, you must first load the image container data into Enterprise. For more information, see Scanning Repositories.

Once the data is made available to Anchore Enterprise, you can then analyze it. An example workflow might be as follows.

1. Start Anchore Enterprise. You will default to the dashboard view. The Dashboard is your configurable landing page where insights into the collective status of your container image environment. The summary information is displayed through various widgets. Utilizing the Enterprise Reporting Service, the widgets are hydrated with metrics which are generated and updated on a cycle, the duration of which is determined by application configuration. See Dashboard for more information about what you can view.

2. Click Applications > Container Images to view a summary of the applications in your container images. The information is categorized by applications, with sub-categories of application versions available from image containers that you previously loaded. Notice the list of applications and application versions, as well as any artifacts in the applications.

3. Click SBOM Report Updated Application name to download a software bill of materials (SBOM) report in JSON format for everything in an application. Or, click SBOM Report to download a report for everything in an artifact.

4. Click an artifact link under Repository Name to view the detailed information for the artifact.

The Images analysis screen for an artifact shows you a summary of what is in that artifact.

5. From the analysis screen, you can perform the following actions.

• Click Policy Compliance to view the policies set up for the artifact. You can see the policy rules that are set up as well.
• Click Vulnerabilities to view the vulnerabilities associated with the artifact.
• Click SBOM to view the contents of the SBOM(s) associated with the artifact.
• Click Image Metadata to view the metadata information for the artifact.
• Click Build Summary to see the Manifest, Dockerfile, and Docker History of your artifact.
• Click Action Workbench to see the action plans and history for an image artifact.
• You have the option to click SBOM Report to download a report for everything in the artifact.
• You also have the option to click Compliance Report to download a report that shows the compliance information in the artifact.

6. Click Policies to set up the rules for the analyzed container image.

See Policies for more information. See Policy Mappings for more information.

3.4 - Work with Applications Generated from Source Repositories

To work with source repository data in Anchore Enterprise, you must first use AnchoreCTL or the Anchore API to load the source repository into Enterprise.

Once the data is made available to Anchore Enterprise, you can then view and generate reports specific to an application version. An example workflow might be as follows.

1. Start Anchore Enterprise. You will default to the dashboard view. The Dashboard is your configurable landing page where insights into the collective status of your source repository. The summary information is displayed through various widgets. Utilizing the Enterprise Reporting Service, the widgets are hydrated with metrics which are generated and updated on a cycle, the duration of which is determined by application configuration. See Dashboard for more information about what you can view.

2. Click Applications > Source Repositories to view a summary of the applications in your source repository. The information is categorized by applications, with sub-categories of application versions available from source repositories that you previously loaded via AnchoreCTL or the Anchore API. Notice the list of applications and application versions, as well as any artifacts in the applications.

3. Click SBOM Report Updated Application name to download a software bill of materials (SBOM) report in JSON format for everything in an application. Or, click SBOM Report to download a report for everything in an artifact.

4. Click an artifact link for a source repository under Repository Name to view the detailed information for the artifact.

The Sources analysis screen for an artifact shows you a summary of what is in that artifact.

5. From the analysis screen, you can perform the following actions.

• Click Policy Compliance to view the policies set up for the artifact. You can see the policy rules that are set up as well.
• Click Vulnerabilities to view the vulnerabilities associated with the artifact.
• Click SBOM to view the contents of the SBOM(s) associated with the artifact.
• Click Source Metadata to view the metadata information for the artifact.
• You have the option to click SBOM Report to download a report for everything in the artifact.
• You also have the option to click Compliance Report to download a report that shows the compliance information in the artifact.

6. Click Policies to set up the rules for the analyzed source repository. The rules set up for an artifact source repository are different from what you apply to a container image.

See Policies for more information. See Policy Mappings for more information.

4 - Anchore Enterprise Application Groups

Anchore Enterprise lets you model your versioned applications to create a comprehensive view of the vulnerability and security health of the projects your teams are building across the breadth of your Software Delivery Lifecycle.

By grouping related components into applications, and updating those components across application versions as projects grow and change, you can get a holistic view of the current and historic security health of the applications from development through built image artifacts.

The typical flow is:

• An application will be created for each project that you want to track.
• Versions will be created both for the current in-development version and for previous versions.
• Artifacts will be grouped together under those application versions.

Applications, application versions, and artifact associations can be managed via either the applications API or AnchoreCTL.

Related Topics

• Application Components
• Application Features with the Anchore Enterprise GUI
• Application Management - Anchore API
• Application Management - AnchoreCTL

4.1 - Application Components

Applications

Applications are the top-level building block in this hierarchical view, containing artifacts like packages or image artifacts. Applications can represent any project your teams deliver. Applications have user-specified name and description fields to describe them. Applications are expected to be long-lived constructs, typically with multiple versions added over time.

Application Versions

Each application is associated with one or more application versions. Application versions track the specific grouping of artifacts that comprise a product version. They have one directly user-editable field called version_name which reflects the name of the product’s application version. This field has no special constraints on it, so you can use it to reflect the versioning scheme or schemes for your projects.

Each application, on creation, automatically has one application version created for it, named “HEAD”. “HEAD” is a special version meant to track the in-development version of your product through its release. A typical flow is that, as your CI jobs build new versions of your software, they will add new versions of your source and image artifacts to Anchore Enterprise and associate them with your HEAD application version. On release, you update your “HEAD” version to reflect the actual name of your release (for example, “v1.0.0”), and then create a new “HEAD” version to track development on the next version of your project. Any application version, including the “HEAD” version, can be deleted if needed.

Application versions, rather than applications, are directly associated with artifacts from sources and images. As your project grows and evolves, the packages and package versions associated with it will naturally change and advance over time. Associating them with application versions (rather than directly with applications) allows older application versions to maintain their associations with the older packages that compose them. This allows for historical review auditing and comparison across versions.

Associating Artifacts with Application Versions

An artifact is a generic term that encompasses any SDLC artifact that can be associated with an application version. Currently, that includes sources and images. The application API has endpoints (and AnchoreCTL has subcommands) to manage the associations between application versions and artifacts.

One important distinction is that these endpoints and commands are operating on the association between artifacts and application versions, not on the artifacts themselves. A source or image must already be added to Anchore Enterprise before it can be associated with an application. Similarly, removing the association with an application version does not remove the artifact from Anchore Enterprise. It can later be re-associated with the application version, or another application version.

Application Version software bill of materials (SBOM)

Once an application version has artifacts associated with it, users can generate an application version SBOM, which aggregates the SBOMs for all of the artifacts associated with the application version.

Application Version Vulnerabilities

Users can generate a list of vulnerabilities within an application version. This will be an aggregate of all vulnerabilities found within the artifacts associated with the specific application version.

4.2 - Application Features with the Anchore Enterprise GUI

Anchore Enterprise lets you use the UI to see a summary of the applications available from source repositories. You can perform an analysis of the application and artifact data.

Additionally, you can set your policies and mappings for a source repository, similar to how you set them up for images.

Related Topics

• View Applications from Image Containers
• View Applications from Source Repositories
• Work with Applications Generated from Image Containers
• Work with Applications Generated from Source Repositories
• Anchore Enterprise Application Groups

4.3 - Application Management - Anchore Enterprise API

Use the Anchore Enterprise API to manage your applications. For more information about using Anchore Enterprise APIs via Swagger, see: Using the Anchore Enterprise API.

The API application workflow would be like the following.

Create an Application

Create an application by POSTing the JSON in the block below to http://<host:port>/v2/applications/.

{
   "name": "Application name",
   "description": "Application description"
}

GET the List of All Applications

GET the list of all applications from ​​http://<host:port>/v2/applications/.

Add the include_versions=true flag to include all application versions under each application in the API response.

GET a Single Application

GET a single application by adding the application_id to the GET command. For example: http://<host:port>/v2/applications/<application_id>/.

Add the include_versions=true flag to include all application versions under each application in the API response.

Update an Existing Application

PUT the following to http://<host:port>/v2/applications/<application_id>/ to update an existing application, such as changing the name and description.

{
   "name": "Updated application name",
   "description": "Updated application description"
}

Remove a Specified Application

Send a DELETE to http://<host:port>/v2/applications/<application_id>/ to remove the specified application.

4.3.1 - Application Version Management - Anchore Enterprise API

Use the Anchore Enterprise API to manage your application versions. For more information about using Anchore Enterprise APIs via Swagger, see: Using the Anchore Enterprise API.

The API application workflow would be like the following.

Create an Application Version

To use the Anchore Enterprise API to create an application version that is associated with an already-existing application, POST the JSON in the block below to http://<host:port>/v2/applications/<application_id>/versions/.

{
   "version_name": "v1.0.0"
}

GET the List of All Application Versions

GET the list of all application versions for the application from http://<host:port>/v2/applications/<application_id>/ versions.

GET a Single Application Version

GET a specific application version from http://<host:port>/v2/applications/<application_id>/versions/<application_version_id>.

Update an Existing Application

To update the name of an existing application version, PUT the following to http://<host:port>/v2/applications/<application_id>/versions/<application_version_id>

{
    "version_name": "v1.0.1"
}

Remove a Specified Application Version

To delete an application version, Send a DELETE to http://<host:port>/v2/applications/<application_id>/versions/<application_version_id>.

4.3.2 - Associate Artifacts with Application Versions - Anchore Enterprise API

Add an Artifact Association

The following commands require source or image artifacts to already be added to the Anchore Enterprise instance before they can be associated with the application version.

The response body for each artifact association request will contain an artifact_association_metadata block with an association_id field in it. This field uniquely identifies the association between the artifact and the application version, and is used in requests to remove the association.

Associate a Source Artifact

To associate a source artifact, POST the following body to http://<host:port>/v2/applications/<application_id>/versions/<application_version_id>/artifacts.

Note the fields specific to source artifacts in contrast to the image artifact in the next example.

{
    "artifact_type": "source",
    "artifact_keys": {
        "uuid": "<source uuid>"
    }
}

Associate an Image Artifact

To associate an image artifact, POST the following body to http://<host:port>/v2/applications/<application_id>/versions/<application_version_id>/artifacts.

Note the fields specific to image artifacts in contrast to the source artifact in the previous example.

{
    "artifact_type": "image",
    "artifact_keys": {
        "image_digest": "<image_digest>"
    }
}

List All Associated Artifacts

Each artifact in the response body will contain an artifact_association_metadata block with an association_id field in it. This field uniquely identifies the association between the artifact and the application version, and is used in requests to remove the association.

List All Artifacts Associated with an Application Version

To list all artifacts associated with an application version, GET http://<host:port>/v2/applications/<application_id>/versions/<application_version_id>/artifacts.

Filter the Results by Artifact Type

To filter the results by artifact type, add the artifact_types=<source,image> query parameter.

Remove an Artifact Association

Send a DELETE request to http://<host:port>/v2/applications/<application_id>/versions/<application_version_id>/artifacts/<association_id>.

4.3.3 - Application Version Operations - Anchore Enterprise API

Users can perform queries against specific versions of an application.

SBOM for a specific Application Version

Using the application API to generate a combined software bill of materials (SBOM) for all artifacts within an application version. This lets you easily archive the components, or provide them to others for verification process compliance requirements. The data structure metadata for the application and application version, along with the SBOMs for each artifact associated with the application version.

Download a Combined SBOM

To download a combined SBOM, GET the application version SBOM from http://<host:port>/v2/applications/<application_id>/versions/<application_version_id>/sboms/native-json.

To filter the results by artifact type, add the artifact_types=<source,image> query parameter.

Vulnerabilities for a specific Application Version

Using the application API, a user can generate a combined list of vulnerabilities found among all artifacts within an application version. This allows easier vulnerability management for any Application Version.

Get a Combined Vulnerabilities List

http://<host:port>/v2/applications/<application_id>/versions/<application_version_id>/vulnerabilities.

Optional query parameter of will_not_fix=<true | false> is provided. When true, the results will include any vulnerabilities that the vendor of an image distribution either disagrees with or does not intend to prioritize for remediation

4.4 - Application Management - AnchoreCTL

Use AnchoreCTL to manage your applications. The AnchoreCTL application workflow would be like the following.

Create a Named Application

Use AnchoreCTL to create a named application. For example: anchorectl application add <name> --description <description>

List All Applications

Use the AnchoreCTL to list all applications. For example: anchorectl application list.

Request an Individual Application

Request an individual application from Anchore via AnchoreCTL to view details about it. For example: anchorectl application get <application_name>.

Update and Change Properties of an Existing Application

Update and change the properties of an existing application via AnchoreCTL.

For example, change the application name and description as follows: anchorectl application update <application_name> --name <new_name> --description <new_description>.

Remove an Application

Use AnchoreCTL to delete applications. This lets you remove applications that are no longer useful or important to you. For example: anchorectl application delete <application_name>

4.4.1 - Application Version management - AnchoreCTL

Use AnchoreCTL to manage your application versions.

The AnchoreCTL application workflow would be like the following.

Create and Store Versions of your Application

Use AnchoreCTL to create and store versions of your applications. Versioning is useful for audit compliance and reporting. Use the following AnchoreCTL command to create a version:

anchorectl application version add <application-name>@<version-name>

List All Application Versions

Use AnchoreCTL to list all application versions that are associated with an application.

anchorectl application version list <application_name>

Update Application Version Properties

Use AnchoreCTL to update application version properties for an existing application in Anchore.

anchorectl application version update <application-name>@<version-name> --name <new_version_name>

Request a Specific Application Version

Use AnchoreCTL to request a specific version of an application to view its details. The following example shows the AnchoreCTL command to request a version:

anchorectl application version get <application-name>@<version-name>

Remove Application Version

Use AnchoreCTL to delete application versions. This lets you remove application versions that are no longer useful or important to you.

anchorectl application version delete <application-name>@<version-name>

4.4.2 - Get an Application Version SBOM - AnchoreCTL

Run the anchorectl application sbom <application_name>@<application_version> (e.g., anchorectl application sbom [email protected]) command to download a combined software bill of materials (SBOM) for all components and supply-chain elements of an application in native Syft JSON format. This lets you easily archive the components, or provide them to others for verification process compliance requirements. The data structure includes the version and version metadata for the application version, along with the SBOMs for each associated artifact in a JSON array.

To filter the results by artifact type, add the argument –-type <source,image> to the end of the command.

Note: Applications with multiple image/source artifacts associated may result in a very large SBOM.

4.4.3 - Associate Artifacts with Application Versions - AnchoreCTL

Add an Artifact Association

The following commands require source or image artifacts to already be added to the Anchore Enterprise instance before they can be associated with the application version.

The response body for each artifact association request will contain an artifact_association_metadata block with an association_id field in it. This field uniquely identifies the association between the artifact and the application version.

Associate a Source Artifact

To associate a source artifact: anchorectl application artifact add <application-name>@<version-name> source <source_uuid>

Associate an Image Artifact

To associate an image artifact: anchorectl application artifact add <application-name>@<version-name> image <image_digest>

List All Associated Artifacts

To list all artifacts associated with an application version: anchorectl application artifact list <application-name>@<version-name>

To filter the results by artifact type, add the argument --type <source,image> to the end of the command.

Remove an Artifact Association

Get the association_id of one of the associated artifacts and run the following command: anchorectl application artifact remove <application-name>@<version-name> <artifact_id>

5 - Generating SBOMs for a Source Repository using the API

Use the Anchore Enterprise API to import a source repository artifact from a software bill of materials (SBOM) file on disk. You can also get information about the source repository, investigate vulnerability packages by requesting vulnerabilities for a single analyzed source repository, or get any policy evaluations.

For more information about using Anchore Enterprise APIs via Swagger, see: Using the Anchore Enterprise API.

The SBOM management API workflow would generally be as follows.

1. Once you have generated a SBOM using anchorectl, you can use the API to import that SBOM as a source artifact. For example, to create the import “operation” (job) for importing a source.

curl -u admin:foobar -X 'POST' 'http://localhost:8228/v2/imports/sources'

{
    "created_at": "2023-10-27T16:26:33Z",
    "expires_at": "2023-10-28T16:26:33Z",
    "last_updated": "2023-10-27T16:26:33Z",
    "status": "pending",
    "uuid": "b78cda3b-eff7-4e2e-a1ed-e3f8433435cf"
}

2. Add the SBOM to the import operation. For example:

curl -u admin:foobar -X POST http://localhost:8228/v2/imports/sources/767c77fe-8f93-4e7e-a9ff-f0f39e2a80ba/sbom -d @/absolute/path/to/your/sbom.json -H "Content-Type: application/json"

{
    "created_at": "2022-02-28T20:36:32Z", 
    "digest": "6778145cdda7a3443abc9650683c6d5bf8a87e3e6b4b3c8868224e7755680446"
}

3. Finalize the import. For example:

curl -X 'POST' 'http://localhost:8228/v2/imports/sources/767c77fe-8f93-4e7e-a9ff-f0f39e2a80ba/finalize'
  -H 'accept: application/json'
  -H 'Content-Type: application/json’
  -d '{
  "branch_name": "main",
  "change_author": "[email protected]",
  "ci_workflow_execution_time": "2022-02-28T20:38:13.117Z",
  "ci_workflow_name": "default",
  "contents": {
    "sbom": "6778145cdda7a3443abc9650683c6d5bf8a87e3e6b4b3c8868224e7755680446"
  },
  "host": "http://github.com",
  "repository_name": "anchore-engine",
  "revision": "8f7e4afb9bc9a284e24b69e529863a0b99373bf7"
}'

{
  "account_name": "admin",
  "analysis_status": "not_analyzed",
  "created_at": "2022-02-28T20:43:58Z",
  "host": "http://github.com",
  "last_updated": "2022-02-28T20:43:58Z",
  "metadata_records": [
    {
      "branch_name": "main",
      "change_author": "[email protected]",
      "ci_workflow_execution_time": "2022-02-28T20:38:13Z",
      "ci_workflow_name": "default",
      "uuid": "8b97a668-2044-4f24-a5af-6010e7957ac3"
    }
  ],
  "repository_name": "anchore-engine",
  "revision": "8f7e4afb9bc9a284e24b69e529863a0b99373bf7",
  "source_status": "active",
  "uuid": "a0eb87e2-61ef-4721-bb16-9682ad528bbe",
  "vcs_type": "git"
}

4. List all sources that you’ve imported. For example:

curl -u admin:foobar -X 'GET' 'http://localhost:8228/v2/sources'
{
    "items" : [
      {
        "account_name": "admin",
        "analysis_status": "analyzed",
        "created_at": "2022-02-28T20:43:58Z",
        "host": "http://github.com",
        "last_updated": "2022-02-28T20:43:58Z",
        "repository_name": "anchore-engine",
        "revision": "8f7e4afb9bc9a284e24b69e529863a0b99373bf7",
        "source_status": "active",
        "uuid": "a0eb87e2-61ef-4721-bb16-9682ad528bbe"
      },
      …
    ]
}

5. Get information about a single source that you’ve imported. For example:

curl -u admin:foobar -X 'GET' 'http://localhost:8228/v2/sources/a0eb87e2-61ef-4721-bb16-9682ad528bbe'

{
  "account_name": "admin",
  "analysis_status": "analyzed",
  "created_at": "2022-02-28T20:43:58Z",
  "host": "http://github.com",
  "last_updated": "2022-02-28T20:43:58Z",
  "metadata_records": [
    {
      "branch_name": "main",
      "change_author": "[email protected]",
      "ci_workflow_execution_time": "2022-02-28T20:38:13Z",
      "ci_workflow_name": "default",
      "uuid": "8b97a668-2044-4f24-a5af-6010e7957ac3"
    }
  ],
  "repository_name": "anchore-engine",
  "revision": "8f7e4afb9bc9a284e24b69e529863a0b99373bf7",
  "source_status": "active",
  "uuid": "a0eb87e2-61ef-4721-bb16-9682ad528bbe",
  "vcs_type": "git"
}

6. Fetch a gzip compressed copy of the sbom for a specific type. For example:

curl -X 'GET' -u admin:foobar 'http://localhost:8228/v2/sources/a0eb87e2-61ef-4721-bb16-9682ad528bbe/sbom/native-json'
curl -X 'GET' -u admin:foobar 'http://localhost:8228/v2/sources/a0eb87e2-61ef-4721-bb16-9682ad528bbe/sbom/cyclonedx-json'
curl -X 'GET' -u admin:foobar 'http://localhost:8228/v2/sources/a0eb87e2-61ef-4721-bb16-9682ad528bbe/sbom/spdx-json'

7. Get the types of vulnerabilities that you may fetch with respect to a source. For example:

curl -X 'GET'  -u admin:foobar 'http://localhost:8228/v2/sources/a0eb87e2-61ef-4721-bb16-9682ad528bbe/vuln'


[
  "os",
  "non-os",
  "all"
]

8. Get the vulnerabilities for a source. For example:

curl -X 'GET' -u admin:foobar 'http://localhost:8228/v2/sources/a0eb87e2-61ef-4721-bb16-9682ad528bbe/vuln/all'

{
  "source_id": "a0eb87e2-61ef-4721-bb16-9682ad528bbe",
  "vulnerabilities": [
    {
        "feed": "vulnerabilities",
        "feed_group": "nvd",
        "fix": "None",
        "nvd_data": [
            {
            "cvss_v2": {
                "base_score": 5,
                "exploitability_score": 10,
                "impact_score": 2.9
            },
            "cvss_v3": {
                "base_score": 7.5,
                "exploitability_score": 3.9,
                "impact_score": 3.6
            },
            "id": "CVE-2019-13509"
            }
        ],
        "package": "docker-4.3.1",
        "package_cpe": "None",
        "package_cpe23": "cpe:2.3:a:docker:docker:4.3.1:*:*:*:*:*:*:*",
        "package_name": "docker",
        "package_path": "/Users/vijay/Documents/enterprise/requirements-test.txt",
        "package_type": "python",
        "package_version": "4.3.1",
        "severity": "High",
        "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13509",
        "vendor_data": [],
        "vuln": "CVE-2019-13509",
        "will_not_fix": false
        },
    …
  ],
  "vulnerability_type": "all"
}

9. Get the policy evaluation for a source. For example:

curl -X 'GET' -u admin:foobar 'http://localhost:8228/v2/sources/a0eb87e2-61ef-4721-bb16-9682ad528bbe/check'

[
  {
    "account_name": "admin",
    "created_at": "2022-02-28T21:11:37Z",
    "evaluation_id": "7a4611f2fa26d80bd680782eb379081f",
    "evaluation_url": "policy_evaluations/7a4611f2fa26d80bd680782eb379081f",
    "final_action": "fail",
    "final_action_reason": "policy_evaluation",
    "findings": [
        {
            "action": "warn",
            "allowlist_match": null,
            "allowlisted": false,
            "gate": "vulnerabilities",
            "message": "MEDIUM Vulnerability found in non-os package type (gem) - /syft/pkg/cataloger/ruby/test-fixtures/Gemfile.lock (fixed in: 4.1.11)(GHSA-vxvp-4xwc-jpp6 - https://github.com/advisories/GHSA-vxvp-4xwc-jpp6)",
            "policy_id": "f2dbc082-7d10-432a-9f62-02ea8f1e5dbf",
            "recommendation": "",
            "rule_id": "24c7ec4f-d795-4ee3-93e7-4d603560ddb3",
            "trigger": "package",
            "trigger_id": "GHSA-vxvp-4xwc-jpp6+Gemfile.lock"
        },
        ...
    ]
    "host": "http://github.com",
    "matched_mapping_rule": {
        "host": "*",
        "id": "9a899100-6e4c-4038-93ba-12f6d8ab97b3",
        "name": "default-source-mapping",
        "policy_id": "f2dbc082-7d10-432a-9f62-02ea8f1e5dbf",
        "repository": "*",
        "allowlist_ids": [
          "37fd763e-1765-11e8-add4-3b16c029ac5c"
        ]
    },
    "number_of_findings": 149,
    "last_updated": "2022-02-28T21:11:37Z",
    "policy_id": "2c53a13c-1765-11e8-82ef-23527761d060",
    "policy": {
        "allowlisted_images": [],
        "allowlists": [
            {
                "description": "Default global allowlist",
                "id": "37fd763e-1765-11e8-add4-3b16c029ac5c",
                "items": [],
                "name": "Global Allowlist",
                "version": "2"
            }
        ],
        "denylisted_images": [],
        "description": "Default bundle",
        "id": "2c53a13c-1765-11e8-82ef-23527761d060",
        ...
    },
    "repository_name": "anchore-engine",
    "revision": "8f7e4afb9bc9a284e24b69e529863a0b99373bf7",
    "source_id": "a0eb87e2-61ef-4721-bb16-9682ad528bbe",
     "source_mapped_to_rule": true,
     "status": "fail"
  }
]

11. Delete any individual source repository SBOM artifact from Anchore Enterprise. For example:

curl -X 'DELETE' -u admin:foobar  'http://localhost:8228/v2/sources/a0eb87e2-61ef-4721-bb16-9682ad528bbe'

Related Topics

• SBOM Generation and Management
• Observe Applications in Enterprise
• Anchore Enterprise Application Groups
• Using the Anchore Enterprise API

6 - Anchore Enterprise Package Override - License Data

Anchore Enterprise Package Override - License Data

Overview

The package override feature for license data, allows the user to override license information for specific packages in their Anchore Enterprise deployment.

License Summary Document

Anchore Enterprise provides a per image license summary document which provides a list of packages and the available license data. Each package listed, provides a list of license identifiers that were detected at the time of analysis. When the license identifier is a valid SPDX expression, additional fields will be included such as the license name, text, header, url and copyright.

This document can be retrieved via the GET /v2/images/{image_digest}/content/licenses endpoint.

• Note: Any license override data will be reflected in the license summary document.

Creating an Override of License Data

• Note: Any overrides provided will be used globally on any image that contains that specified package.

For a specific package, identified by its PURL, you can override the license data provided by the upstream package manager. Any license field that is used in the override request, will be used in place of the license data originally found. This is done with a POST to the endpoint /exp/system/package-overrides/licenses.

An override may be targeted to one or more of the license(s) that the package originally showed. Or the override can target specific license data such as the license text, header, url or copyright.

License Override RBAC Role

A new RBAC role has been added to support the license override feature. The license-override role can be conferred to any user. They will be able to create, update and delete license overrides. The license-override role has a domain value of system and a resource value of license-overrides. The license-override role is not required to view the license summary document.

Any user with role system-admin will also have permissions to create, update and delete license overrides.

Anchore Enterprise Experimental API

Please review for a complete description of the license override feature within the Experimental API. The license override feature is part of the Experimental API and is subject to change.