Skip to main content

Enforce SBOM policies

Last updated on

The creation of a Software Bill of Materials (SBOM) significantly enhances software transparency. The comprehensive view not only brings visibility but also opens up the opportunity to improve security and ensure compliance. It enables organizations to define and implement specific rules governing the use of open source components, including the criteria to allow or deny components. By applying these rules, organizations can effectively mitigate security risks, comply with licensing obligations, and exert greater control over their software supply chain.

The Harness SCS module enables you to create these rules as policies that align with your organization's security regulations and legal compliance requirements. These policies can then be enforced on SBOMs. This entire process is facilitated through the SBOM Policy Enforcement step.

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

Here's a breakdown of the overall steps involved:

  1. Create an OPA policy set
  2. Write policy definitions
  3. Enforce the policies on SBOM
  4. View policy violations and take actions

Requirements

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

info

For SBOM Policy Enforcement, an SBOM needs to be generated or ingested beforehand through the SBOM Orchestration step. Refer to the dedicated SBOM generation document for further details.

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 and ensure you enable the container based execution.

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.

  • 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.

Verify the SBOM Attestation

Verification is the process of validating an SBOM signature to ensure its authenticity and integrity. It confirms that the SBOM was signed by a trusted source, has not been tampered with, and corresponds to the expected artifact. In the SBOM Policy Enforcement step, this ensures that only trusted and compliant SBOMs are used for downstream analysis and decision-making. To understand the verification process, see attestation and verification concepts.

You can perform verification using Cosign with the following verification methods:

  • Keyless - Uses short-lived, automatically generated keys based on identity to verify attested SBOM without storing private keys.
  • Key-based - Uses a user-managed private and public key pair to verify attested SBOM, 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 verification type you select, click the tab below and specify the configurations for the SBOM Policy Enforcement step to perform the verification.

Keyless verification using Cosign allows you to verify the authenticity and integrity of an attested SBOM without requiring access to a private signing key. During verification, Cosign uses the certificate and signature associated with the SBOM to validate that it was signed by a trusted identity and has not been tampered with. It checks the certificate chain against trusted root certificates, verifies the signature using the public key embedded in the certificate, and ensures that the certificate was valid at the time of signing.

note

In air-gapped environments, transparency log (Tlog) checks are skipped. The transparency log records signing events in a tamper-evident log, enabling independent verification. By default, the airgap setting is enabled, which prevents attestations from being pushed to the Rekor transparency log.

To configure SBOM verification with Keyless verification using cosign, complete the following steps:

  1. Click the checkbox beside Verify SBOM to enable SBOM verification. 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 verification. In this approach, Harness acts as the OIDC provider and automatically generates an OIDC token during pipeline execution, which Cosign uses to verify the SBOM signature without requiring access to a private key.

The verification process uses the certificate and signature associated with the SBOM along with the identity provided through the OIDC token to confirm that the SBOM was signed by a trusted source, has not been tampered with, and corresponds to the expected artifact. No additional configuration is required when using Harness as the OIDC provider.

Non-Harness OIDC

Non-Harness OIDC allows you to use an external identity provider for keyless verification. In this approach, the OIDC token is retrieved during pipeline execution from a configured connector, such as AWS, Azure, or GCP. This token is then used by Cosign to verify the SBOM signature against the identity issued by the external provider.

The verification process checks the SBOM’s signature and certificate to ensure that it was signed by a trusted identity, has not been tampered with, and corresponds to the expected artifact. To use a Non-Harness OIDC provider for verification, you must configure the OIDC connector for keyless signing. For setup instructions, see the Non-Harness OIDC section in the Generate SBOM for Artifacts documentation.

Policy Configuration

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

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.

View Policy Violations

The policy violations arising from the SBOM Policy Enforcement step in your pipeline are accessible under the "Policy Violations" section of the artifact list. Also, the Policy Violations card in the overview displays a cumulative count of all the allow list and deny list items across all artifacts.