Enforce SBOM policies

Enforce SBOM policies in the CI and CD stages of your Harness pipelines to ensure that your artifacts only contain approved components.

Requirements

To enforce SBOM policies in a Harness pipeline, you need:

• A pipeline with a CI (build) stage, a CD (deploy) stage, or both. You'll add the SBOM Enforcement step to one of these stages.
• SBOM OPA policies that you want to enforce.
• SBOM to compare policies against. For example, you can use SCS to generate SBOM or import SBOM.
• A Harness file secret containing the public key from the key pair used to sign and attest the SBOM.

Add SBOM Policy Enforcement step

You can add the SBOM Policy Enforcement step to either the Build or Deploy stage of a Harness pipeline.

• In a Build stage, add the step after the SBOM generation step.
• In a Deploy stage, add the step before the deployment step.

info

SBOM Orchestration and Enforcement steps in deploy stage can only be used in the Containerized Step Groups

The SBOM Policy Enforcement step has the following settings:

• Name: Enter a name for the step.

• Source: Select the Source by choosing either a supported container registry from the list or Repository.

DockerHub

• Container Registry: Select the Docker Registry connector that is configured for the DockerHub container registry where the artifact is stored.

• Image: Enter the name of your image with tag, such as repo-name:tag.

ECR

• Container Registry: Select the Docker Registry connector that is configured for the Elastic container registry where the artifact is stored.

• Image: Enter the name of your image with tag for the image for which you're generating an SBOM, such as my-docker-repo/my-artifact:latest.

• Region: The geographical location of your ECR repository.

• Account ID: The unique identifier associated with your AWS account.

GCR

• Container Registry: Select the Docker Registry connector that is configured for the Google container registry where the artifact is stored.

• Image: Enter the name of your image with tag for which you're generating the SBOM, example docker-image:tag.

• Host: Enter your GCR Host name. The Host name is regional-based. For instance, a common Host name is gcr.io, which serves as a multi-regional hostname for the United States.

• Project ID: Enter the unique identifier of your Google Cloud Project. The Project-ID is a distinctive string that identifies your project across Google Cloud services. example: my-gcp-project

GAR

• Container Registry: Select the Docker Registry connector that is configured for the Google artifact registry where the artifact is stored.

• Image: Enter the name of your image with tag for which you're generating the SBOM, example repository-name/image:tag.

• Host: Enter your GAR Host name. The Host name is regional-based. For example, us-east1-docker.pkg.dev.

• Project ID: Enter the unique identifier of your Google Cloud Project. The Project-ID is a distinctive string that identifies your project across Google Cloud services. example: my-gcp-project

ACR

• Container Registry: Select the Docker Registry connector that is configured for the Azure container registry where the artifact is stored.

• Image: Enter your image details in the format <registry-login-server>/<repository>:<tag>. The <registry-login-server> is a fully qualified name of your Azure Container Registry. It typically follows the format <registry-name>.azurecr.io, where <registry-name> is the name you have given to your container registry instance in Azure. Example input: automate.azurecr.io/acr:test

• Subscription Id: Enter the unique identifier that is associated with your Azure subscription.

Repository

info

The Repository option requires that your repository is cloned into the stage workspace before the SBOM Orchestration step runs. There are several ways you can do this:

• Clone the codebase by default, such as a Build stage's default codebase.
• Add a Git Clone step or Run step to the Deploy stage.
• Add a Git Clone step or Run step to a Build stage.

• Repository URL: The Repository URL you've configured for cloning into the workspace.
• Source Path: Leave blank or enter a path (in the repository) for which you want to generate SBOM. Use this setting to generate SBOM for a specific section of your code repo, rather than your entire repo. The path must start with /. For example, if your repository URL is https://github.com/username/repo, and you want to generate SBOM for https://github.com/username/repo/service-core/source, then enter /service-core/source for Source Path. To generate an SBOM for the entire repository, leave this field empty.
• Git Branch: The branch of the repository for which you want to generate the SBOM.
• Workspace: If you cloned the codebase to a different directory than the root workspace directory (/harness), enter the path to the subdirectory using the format /harness/PATH/TO/SUBDIRECTORY. Leave this field empty if you cloned your codebase into the default directory (/harness). Usually, your codebase is only cloned into a non-default directory if you are cloning multiple codebases into a pipeline.

Verify the SBOM Attestation

To verify the SBOM attestation, in addition to the above configuration, you need to enable the Verify SBOM Attestation checkbox in the SBOM Policy Enforcement step. Enabling this is optional and not required for SBOM policy enforcement.

The attestation verification process requires the corresponding public key of the private key used for SBOM attestation. You can perform the verification by providing the public key through the Cosign option or Cosign with Secret Manager.

Cosign

To perform the attestation verification with Cosign selected, you need to pass the key from the Harness Secret Manager

• Public Key: Input your Public key from the Harness file secret.

Cosign with Secret Manager

If you used HashiCorp Vault as your Secret Manager for attestation, you can also use it for verifying the attestation.

• Connector: Select the same HashiCorp Vault connector that was used during the attestation process.
• Key: Enter the path to the Transit Secrets Engine in your HashiCorp Vault where your public key is stored. This should be the same path used for the attestation process. Note that HashiCorp Vault does not allow viewing the private key directly.

Policy Configuration

You can configure the step to enforce policies on the SBOM by selecting the appropriate policy set.

• Policy Sets: Choose the policy sets you want to use for enforcement. You can select multiple policy sets from the Account, Org, or Project levels. For more details, refer to Creating SBOM Policies and Writing SBOM Policy Definitions.

Run the pipeline

When the pipeline runs, the SBOM Policy Enforcement step does the following:

• With the artifact details, the step verifies the authenticity of the attestation.
• Applies policies defined in the specified policy set.
• If violations are detected based on the policy evaluation criteria, the pipeline may issue a warning and proceed, or it may generate an error and terminate.
• Records policy violations and shows them on the Supply Chain tab on the Execution details page.

SCS evaluates the components described in the artifact's SBOM against your policy definitions. For a component to pass the evaluation, it must meet these conditions:

• The component must not be denied based on the rules in the deny_list.
• The component must be allowed based on the rules in the allow_list.
• If the allow_list has multiple sections, the component must be allowed by all sections. For example, if the allow_list has licenses and suppliers sections, then the component's license must be allowed according to the licenses section, and the component's supplier must be allowed according to the suppliers section. If the component fails to pass either section, the policy evaluation fails for that component.

All components must meet the conditions described in both the allow_list and deny_list to fully pass the policy evaluation.

You can review policy violations on the Execution details page in Harness. For more information, go to view pipeline execution results.