Create SLSA policies

Create SLSA policies using OPA.

This document provides a step-by-step guide on how to create SLSA Policies. Go to write policy definitions to learn how to write these policies. To learn about implementing SLSA policies, follow the instructions in the section on enforcing SLSA policies.

Before you begin

As you learn to create SLSA policies, ensure you thoroughly review

• Harness Policy as Code - Overview

• Harness Policy as Code - Quickstart

The Harness Policy Library provides sample policies that simplify the process of creating and enforcing them against SLSA. Here is a guide on how to utilize these samples for policy creation.

Policies can be created at the account, organization, and project levels, this guide will focus on creating a policy at the account level. For instructions on crafting policies for the organization and project levels, go to the linked overview guide to follow a similar process.

Create SLSA policies

You must create a set of OPA policies that you want Harness SCS to use for SLSA Provenance verification. You can create a dedicated SLSA Provenance verification policy set or use existing policy sets that you have already created. Go to the Harness Policy As Code overview to create policies in Harness.

OPA policies used for SLSA Provenance verification are different from SBOM policies used for SBOM policy enforcement.

1. In your Harness Project, under Project Setup, go to Policies. You can also create policies at the Account and Org scopes.

2. Select Policies, and then create policies for the individual rules that you want to enforce. You can select from the policy library or write your own policies.

3. Create policy sets to group related policies. You must have at least one policy set.

SLSA policy example

Here is an example of an OPA policy that could be used to verify an SLSA Provenance generated in Harness. If you are verifying provenance from a third-party build system provider, make sure your OPA policies reflect the provenance structure used by that build system provider. Different providers might use different SLSA Provenance structures.

Validate repo and branch:

package slsa

# Build repo must be 'https://github.com/abc/abc-sample'. SLSA verification fails if a different repo is detected. <a href="#build-repo-must-be-httpsgithubcomabcabc-sample-slsa-verification-fails-if-a-different-repo-is-detected" id="build-repo-must-be-httpsgithubcomabcabc-sample-slsa-verification-fails-if-a-different-repo-is-detected"></a>
deny[msg]{
  input[0].outcome.stepArtifacts.provenanceArtifacts[0].predicate.buildDefinition.externalParameters.codeMetadata.repositoryURL != "https://github.com/abc/abc-sample"
  msg := "Repository verification failed in Provenance"  
}

# Build branch must be 'main'. SLSA verification fails if a different branch is detected. <a href="#build-branch-must-be-main-slsa-verification-fails-if-a-different-branch-is-detected" id="build-branch-must-be-main-slsa-verification-fails-if-a-different-branch-is-detected"></a>
deny[msg]{
  input[0].outcome.stepArtifacts.provenanceArtifacts[0].predicate.buildDefinition.externalParameters.codeMetadata.branch != "main"
  msg := "Branch verification failed in provenance"  
}

Validate trigger type:

package slsa

deny[msg] {
  input[0].outcome.stepArtifacts.provenanceArtifacts[0].predicate.buildDefinition.externalParameters.trigger != "push"
  msg := "Invalid trigger type: only 'push' is allowed"
}

Validate pipeline identifier:

package slsa

deny[msg] {
  input[0].outcome.stepArtifacts.provenanceArtifacts[0].predicate.buildDefinition.buildType != "https://example.com/ci-pipeline@v1"
  msg := "Pipeline identifier does not match expected value"
}

For more examples, go to Policy samples.