Skip to main content

Verify SLSA

Last updated on

In this document, we'll explore how to verify SLSA Provenance attestation and enforce policies to guarantee the provenance contents remain unaltered. Unlike the setup for SLSA provenance generation, the verification process can be conducted in both the Build and Deploy stages of your pipeline. Here’s an overview of the procedure:

Configure the SLSA verification step​

In the Harness SCS, the SLSA verification step is responsible for verifying the attested provenance and applying policies. To incorporate this, navigate to either the build or deploy stage of your pipeline and add the "SLSA Verification" step. When adding this to a deploy stage, ensure it's placed within a container step group and you enable the container based execution.

Container Images​

Follow the instructions below to configure the SLSA Verification step for container images.

  • Name: Enter a name for the step.
  • Registry Type: Choose your registry from the list of supported items.
info

When modifying the existing SLSA steps, you must manually remove the digest from the YAML configuration to ensure compatibility with the updated functionality.

  • 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@sha256:<digest>.

Non-Container Artifacts​

SLSA verification supports both container images and non-container artifacts. Non-container artifacts are files or packages that are not packaged as container images, such as binaries, manifests, or archives. They are identified using their digest (SHA). This digest is used to match the artifact with its corresponding provenance during verification.

Ensure that the artifact and its digest are generated earlier in the pipeline, typically via a Run step, and that SLSA provenance is already available. Use the same artifact reference in the SLSA Verification step.

To verify SLSA Provenance for Non-Container Artifacts:

  1. Enter a Name for the step under Name. Harness automatically generates a step ID from the name. Once the pipeline is created, you can't change the ID.
  2. Select Harness Local Stage as the Source.
  3. Specify the same workspace artifact path that was used during the SLSA Generation step under Workspace Artifact Path. This path must point to the exact location of the artifact within the workspace so that it can be matched with its provenance during verification. The default workspace path is /harness.

Verify SLSA Attestation​

Verification is the process of validating a provenance attestation to ensure its authenticity and integrity. It confirms that the attestation was signed by a trusted source, has not been tampered with, and corresponds to the expected artifact. In the SLSA Verification step, SLSA attestation verification ensures that only trusted, compliant artifacts are allowed to proceed in the pipeline. 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 SLSA provenance without storing private keys.
  • Key-based - Uses a user-managed private and public key pair to verify SLSA provenance, 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 SLSA Verification step to perform the verification.

Keyless verification using Cosign allows you to verify the authenticity and integrity of SLSA provenance without requiring access to a private signing key. During verification, Cosign uses the certificate and signature stored in the attestation bundle to validate that the provenance 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 SLSA verification with Keyless verification using cosign, complete the following steps:

  1. Click the checkbox beside Verify SLSA to enable SLSA 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:

note

This verification method is not supported for SMP at the moment.

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 validate the attestation without requiring access to a private key.

The verification process uses the certificate and signature from the attestation bundle along with the identity provided through the OIDC token to confirm that the provenance 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 validate the attestation against the identity issued by the external provider.

The verification process ensures that the provenance was signed by a trusted identity, the certificate chain is valid, and the signature matches the 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 SLSA documentation.

Enforce Policies on SLSA Provenance​

Immediately following the verification of the provenance attestation, you have the option to configure the step to enforce policies on the provenance. This ensures that the contents of the provenance remain unchanged and have not been tampered with.

To enforce policies, navigate to the Advanced tab of the SLSA Verification step, expand the Policy Enforcement section, and specify the policy sets you wish to enforce.

Run the pipeline​

When the pipeline runs, the SLSA Verification step does the following:

  • Verifies the authenticity of the attestation.
  • Verifies the provenance data by applying the specified policy set.
  • Records the policy evaluation results in the step's logs.
  • Reports the overall pass/fail for SLSA verification on the Supply Chain tab.

For more information about inspecting SLSA verification results, go to view pipeline execution results in the supply chain tab.

Verify provenance from third-party build systems​

You can use Harness SCS to verify provenance generated by third-party build systems.

To do this:

  1. Get the public key.
  2. Create SLSA policies that verify the provenance data according to the provenance structure used by in the build system provider.
  3. Add SLSA Verification step.