Skip to main content

Generate SLSA

Last updated on

Harness SCS when used along with Harness CI Hosted Builds(Harness Cloud), ensures that the resulting artifacts have SLSA Level 3 provenance that every consumer (including the following deployment stage) can verify for artifact integrity prior to making use of this artifact. Build hardening for Level 3 compliance is achieved through:

  1. Built-in infrastructure isolation for every build where new infrastructure is created for every run and deleted after the run completes.
  2. OPA policy enforcement on CI stage templates with non-privileged, hosted containerized steps that do not use volume mounts. This disallows the build steps to access the provenance key information in compliance with SLSA specifications.

End result is that hackers cannot do tampering during the build process. This capability when coupled with open source governance through SBOM lifecycle management provides the most advanced shift-left supply chain security solution in the market today.

In Harness SCS, you can use the SLSA Generation step to configure your pipeline to generate SLSA Provenance and optionally attest and sign the attestation. The generated provenance is saved in Harness and can be easily accessed from the Artifact section in SCS. If the provenance is attested and signed with keys, the resulting attestation file (.att) is pushed to the container registry. Here's an overview of the workflow:

SLSA Generation step configuration​

The SLSA Generation step enables you to generate SLSA Provenance and optionally attest it. The generated provenance is saved in the Artifact section in SCS, while the attestation file is pushed to the configured container registry. This step should be configured immediately after completing your image-building process, as the image digest is required for provenance generation and attestation.

Container Images​

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

  • Search and add the SLSA Generation step to your pipeline. It is important to place this step immediately after the steps that complete your image-building process, as it requires the artifact digest as input.
  • Artifact Source: Configure your artifact source by selecting from the options available in the dropdown menu. You can choose from Docker Registry, ECR, ACR, or GAR. Select the corresponding artifact source tab below for detailed instructions on configuration.
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, such as imagename:tag or imagename@sha256:<digest>.

Non-Container Artifacts​

SLSA generation is not limited to container images. You can also generate SLSA provenance for non-container artifacts. Non-container artifacts are files or packages that are not packaged as container images, such as binaries, manifests, or archives. Each artifact is uniquely identified by its digest (SHA), which is used during verification. For non-container artifacts, ensure your pipeline includes a step (e.g., a Run step) that generates the artifact and its digest before the SLSA Generation step.

The following non-container artifact types are supported:

  • Helm charts (.tgz)
  • YAML manifests (.yaml)
  • Java archives (.jar)
  • Web application archives (.war)
note

Artifacts not listed above are treated as unknown types.

To generate 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. Provide the exact path to the artifact within the workspace under Workspace Artifact Path. Ensure that you run a custom step to pull the artifact into the workspace directory. The default workspace path is /harness.
  4. Click the radio buttons under Target Detection to set the artifact name and version. The available options are Auto and Manual.
  • By default, the target detection is set to Auto. It automatically sets the artifact name from the provided path.
  • Click the radio button beside Manual to manually specify the artifact name and version.
    • Provide the name of the artifact under Artifact Name. Optionally, provide the artifact version under Version.

With this configuration, the step generates the SLSA Provenance and stores it in the Artifact section of SCS. To attest to the generated provenance, follow the instructions in the section below.

Attest SLSA Provenance​

Attestation is the process of cryptographically signing the generated provenance to ensure its authenticity and integrity. In SLSA generation, attestation ensures that the provenance has not been tampered with and can be trusted by downstream systems. To understand the attestation 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 SLSA provenance without storing private keys.
  • Key-based - Uses a user-managed private and public key pair to sign 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 attestation type you select, click the tab below and specify the configurations for the SLSA Generation step to perform the attestation.

Keyless signing using Cosign lets you sign SLSA provenance 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 provenance. The signing key is generated and used only in memory and is not persisted. This reduces the risk of key compromise while ensuring the provenance 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 SLSA attestation with Keyless signing using cosign, complete the following steps:

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

note

This attestation 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 signing. 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. 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.

Here’s an example of what the signed attestation would look like


{
  "payloadType": "application/vnd.in-toto+json",
  "payload": "CJTUERYUmVmLVBhY2thZ2UtZGViLXpsaWIxZy1mOTFhODZjZjhhYjJhZTY3XCIsXCJyZWxhdGlvbnNoaXBUeXBlXCI6XCJDT05UQUlOU1wifSx7XCJzcGR4RWxlbWVudE",
  "signatures": [
    {
      "keyid": "dEdLda4DzZYoQgNCgW",
      "sig": "MEUCIFoNt/ELa4DzZYoQgNCgW++AaCbYv4eOu0FloUFfAiEA6EJQ31P0ROEbLhDpUhMdMAzkqlBSCMFPDk1cyR1s6h8="
    }
  ]
}

Additionally, you can perform Base64 decoding on the payload data to view your SLSA Provenance. For verifying the SLSA attestation, please refer to Verify SLSA documentation.

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 you run a pipeline with SLSA generation enabled, Harness SCS:

  • Generates an SLSA Provenance for the image created by the Build and Push steps in the Build stage.
  • Generates and signs an attestation using the provided key and password.
  • Stores the SLSA Provenance in Harness and uploads the .att file to your container registry alongside the image.

The signed attestation is stored, as a .att file, in the artifact repository along with the image. You can also find the SLSA Provenance on the Supply Chain tab on the Pipeline Execution details page in Harness.You can download your SLSA provenance and find the status of the SLSA verification step. The overview section presents a cumulative count of all Success and failure cases.

Provenance example​

Here's an example of an SLSA Provenance generated by Harness SCS. The information in your SLSA Provenance might vary depending on your build and changes to the provenance structure applied in SCS updates. Identifiers, repo names, and other details in this example are anonymized or truncated.

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "subject": [
    {
      "name": "index.docker.io/harness/plugins",
      "digest": {
        "sha256": "2deed18c31c2bewfab36d121218e2dfdfccafddd7d2llkkl5"
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://developer.harness.io/docs/software-supply-chain-assurance/slsa/generate-slsa/",
      "externalParameters": {
        "codeMetadata": {
          "repositoryURL": "https://github.com/nginxinc/docker-nginx",
          "branch": "master"
        },
        "triggerMetadata": {
          "triggerType": "MANUAL",
          "triggeredBy": "Humanshu Arora"
        }
      },
      "internalParameters": {
        "pipelineExecutionId": "UECDFDECEn8PpEfqhQ",
        "accountId": "ppbDDDVDSarz_23sd_d_tWT7g",
        "pipelineIdentifier": "SLSA_Build_and_Push",
        "tool": "harness/slsa-plugin"
      }
    },
    "runDetails": {
      "builder": {
        "id": "https://developer.harness.io/docs/continuous-integration/use-ci/set-up-build-infrastructure/which-build-infrastructure-is-right-for-me"
      },
      "metadata": {
        "invocationId": "aRrEdsfdfdRwWdfdfdecEnwdg",
        "startedOn": "2024-11-26T09:37:18.000Z",
        "finishedOn": "2024-11-26T09:37:18.000Z"
      }
    }
  }
}

Verify SLSA Provenance​

After generating SLSA Provenance, you can configure your pipeline to verify SLSA Provenance.