Skip to main content

Generate and Manage Software Bill of Materials (SBOM)

Last updated on

A Software Bill of Materials (SBOM) is an exhaustive list of all components, libraries, and other dependencies utilized in a software application. The SBOM Orchestration step within Harness SCS facilitates the generation of SBOMs for your software artifacts and code repositories.

If you already possess an SBOM and wish to ingest it, please refer to the Ingest SBOM section.

note

In the SBOM, dependency names may differ from their original source names, as SBOM tools sometimes list dependencies under a product or bundle name rather than the actual dependency name.

SBOM Orchestration step configuration​

You can use SBOM Orchestration step to generate an SBOM in either the Build or Deploy stage of a Harness pipeline.

  • In a Build stage, add the SBOM Orchestration step after the artifact (image) has been pushed to an artifact repository.
  • In a Deploy stage, add the SBOM Orchestration step before the deployment step.
info

SBOM Orchestration step in deploy stage can only be used in the Containerized Step Groups and ensure you enable the container based execution.

The SBOM Orchestration step allows you to generate the SBOM for both Container images and Repositories.

note

SBOM generation is not supported for non-container artifacts. For artifact types such as JAR files, Helm charts, or YAML manifests, you must use the SBOM orchestration step in Ingestion mode and provide a pre-generated SBOM file. Go to Ingest SBOM for Non-Container Images to understand SBOM orchestration via ingestion mode.

Follow the steps to configure the fields for each supported type:

  • Name: Enter a name for the step.

  • Step Mode: Select Generation.

  • SBOM Tool: Select Syft or cdxgen. For other SBOM tools, go to Ingest SBOM.

  • SBOM Format: Select SPDX or CycloneDX.

    If you're using Syft to generate the SBOM and want to ensure it includes all component licenses with high accuracy, you'll need to set specific environment variables based on your project's programming language. Here are the relevant variables:

    Set variables for enhanced SBOM
    Programming LanguageName of VariableValue
    GoSYFT_GOLANG_SEARCH_REMOTE_LICENSEStrue
    JavaSYFT_JAVA_USE_NETWORKtrue
    JavaScriptSYFT_JAVASCRIPT_SEARCH_REMOTE_LICENSEStrue

    To add a new environment variable, go to Overview section of your Build stage, and expand the Advanced section.

    By setting these variables, Syft can more effectively fetch and populate the licensing data for the components in your SBOM. This not only enhances the quality of the SBOM but also improves its overall SBOM score. If your SBOM contains NOASSERTIONS, it indicates that Syft was unable to retrieve necessary data.

  • Registry Type: Select Harness Artifact Registry or Third-Party Artifact Registry, based on where your artifact is stored.
  • Source: Select the Source by choosing either a supported container registry from the list or Repository if you are generating the SBOM for source code.

  • Registry: Select the Harness Registry configured for the Harness Artifact Registry where your artifact is stored.

  • Image: Enter the name of your image with tag or digest, such as imagename:tag or imagename:digest.

With this configuration, the step generates the SBOM and stores it in the Artifact section of SCS. Optionally, you can attest to the generated SBOM, follow the instructions in the section below.

info

The SBOM generation step supports all registry types, including JFrog, Harbor, and Kubernetes registries. Select the Docker Registry Connector that is configured for the Docker Registry where the artifact is stored.

Enter the name of your image with tag, such as:

JFrog: </your-repo/test-image>:tag

Harbor: </your-project/test-image>:tag

Attest the Generated SBOM​

SBOM signing is the process of cryptographically signing a generated SBOM to ensure its authenticity and integrity. It ensures that the SBOM has not been tampered with and can be trusted by downstream systems for analysis and compliance. To understand the signing and verification process, see attestation and verification concepts.

You can perform attestation using Cosign with the following signing methods:

  • Keyless - Uses short-lived, automatically generated keys based on identity to sign generated SBOMs without storing private keys.
  • Key-based - Uses a user-managed private and public key pair to sign generated SBOMs, requiring secure key storage and handling.
  • Secret Manager - A secure service used to store, manage, and access sensitive data such as cryptographic keys without exposing them directly in pipelines.

Based on the attestation type you select, click the tab below and specify the configurations for the SBOM Orchestration step to perform the attestation.

Keyless signing using Cosign lets you sign generated SBOMs without managing long-lived signing keys. Instead, Cosign uses your workload identity (via OIDC) to obtain a short-lived signing certificate during pipeline execution, which is then used to sign the SBOM. The signing key is generated and used only in memory and is not persisted. This reduces the risk of key compromise while ensuring the SBOM remains verifiable and trusted. The signed attestation is pushed to the container registry and associated with the image digest, typically referenced using the digest with a .att extension.

To configure SBOM attestation for generated SBOMs with Keyless signing using cosign, complete the following steps:

  1. Click the checkbox beside Attest SBOM to enable SBOM attestation. The radio button beside Keyless will be selected by default.

  2. Select your preferred OIDC Provider from the dropdown under OIDC Provider. The available options are:

Harness OIDC​

Harness OIDC allows you to use the pipeline’s built-in identity for keyless signing of generated SBOMs. In this approach, Harness acts as the OIDC provider and automatically supplies the identity required during pipeline execution, eliminating the need for external identity configuration.

Non-Harness OIDC​

Non-Harness OIDC allows you to use an external identity provider for keyless signing of generated SBOMs. In this approach, the OIDC token is retrieved from a configured connector (such as AWS, Azure, or GCP) during pipeline execution and used to obtain a signing certificate. This option is useful when you want to integrate with your organization’s existing identity and access management system instead of using Harness as the OIDC provider.

To use a Non-Harness OIDC provider, you need to configure the Connector for Keyless Signing. To configure the Connector:

  1. Navigate to the Configuration page under the Manage section from the sidebar navigation of your SCS account. The General tab opens by default.
  2. Click Select Connector next to Connector for Keyless Signing to open the Create or Select an Existing Connector dialog.
  3. Select your required connector from the list of existing connectors. You can search for your created connector or filter connectors by Project, Organization, and Account.
  4. Alternatively, click + New Connector to create a new OIDC connector for your preferred cloud provider. For more information, see Connectors for Cloud Providers.
  5. Click Apply Selected. Once selected, you can view the Configuration Saved Successfully toaster message at the top, indicating that the connector has been selected or created successfully.

Once the connector configuration is done successfully, you can perform attestation using keyless signing with a Non-Harness OIDC provider.

Configure SBOM Drift​

This feature allows you to track changes in SBOMs by comparing against the last generated SBOM. It provides a detailed analysis of addition or removal of components and licenses, helping you manage and oversee software artifacts more effectively. However, this is optional and not required for SBOM generation. If you prefer not to detect changes in SBOMs, leave this option unchecked.

tip

When SBOM and SLSA attestation steps run in parallel, only one attestation layer may be uploaded to the container registry due to a race condition in Cosign.

Recommended approach:

  • Run the SBOM and SLSA attestation steps sequential rather than in parallel way to avoid SLSA verification or SBOM policy enforcement failures.
  • Place the SLSA generation step just after the Docker Build and Push step.

Run the pipeline​

When the pipeline runs, the SBOM Orchestration step performs the following actions:

  • Generates an SBOM in the chosen format for both Containers and Repositories.
  • Specifically for Containers:
    • Generates and signs an attestation using the provided private key and password.
    • Stores the SBOM in Harness and uploads the .att file to your container registry.

SBOMs for both Containers and Code Repositories are accessible in the Artifacts view. Additionally, you can locate the SBOM for any artifact on the Supply Chain tab within the Execution Details page in Harness.

Example Pipeline for SBOM generation

These example demonstrate how you could set up Build and Deploy stages to generate SBOM.

This example Build stage has three steps:

  • Run step: Build and test an artifact (image).
  • Build and Push an image to Docker Registry step: Build and push the image to a Docker registry.
  • SBOM Orchestration step: Generate the SBOM.

View vulnerabilities in the SBOM​

After you run the SBOM orchestration step followed by the STO Snyk scan, the SBOM tab on the Artifacts page displays vulnerabilities for the components identified by Snyk. This helps you effectively identify and prioritize open source risks

Publish SBOM​

After you run the SBOM Orchestration step, you can download or publish SBOM through multiple ways depending on your workflow:

  • Via Harness API
  • Use the Download SBOM button available on the Artifacts page.
  • Download the SBOM score for an artifact via Harness API
  • Access the SBOM file directly from the pipeline output, generated under the default /harness working directory and is available at /harness/harness/sbom/{sbom_<sbom_orchestration_step_execution_id>}.json.

Next steps​

After generating an SBOM, you can apply SBOM Policy Enforcement to achieve open source governance.