Unlocking secure software distribution with Minder and GitHub Artifact Attestations

We’re excited today to announce support in Minder for GitHub’s new Artifact Attestations feature, now in public beta. Artifact Attestations enables developers to easily publish attestations signed with the open source project sigstore. 

Stacklok CTO Luke Hinds originally created sigstore to address widely shared concerns about software supply chain security. We’ve continued to invest in sigstore, creating policies in Minder to verify signatures generated through sigstore; helping to operate the sigstore Public Good Instance; and maintaining core project libraries. GitHub’s Artifact Attestations feature now integrates sigstore natively into GitHub, marking a huge step forward in helping more developers adopt this critical technology to secure their projects. 

Minder now provides users with the ability to verify these attestations and to apply enhanced security policies based on the contents of signed attestation statements.

Background: What are attestations and why do they matter? 

An attestation is an authenticated statement about a software artifact. Any process or tool that needs to associate metadata with a piece of software for later verification can capture it in an attestation. There are many uses for attestations, such as verifying build provenance; signing a claim that a process has been performed; results of scanning tools; listing software components (SBOM); and more.

An attestation has two parts: a subject (the software the attestation applies to) and a predicate (the claims made about the software):

An example attestation structure: A provenance attestation from the SLSA website.

Attestations are the building blocks of the transparent supply chain. As more and more data is collected during the software development lifecycle, software consumers—regardless of whether they are at the end or in the middle of the chain—can understand the risk they are taking from their software.

(For more information about the importance of attestations and how they’re different from signatures, check out this great blog post by Trevor Rosen at GitHub.)

How GitHub’s Artifact Attestations feature works

The new attestations feature from GitHub fills two missing gaps that historically have been slowing down the adoption of other supply chain technologies: signing and sharing. 

Signing attestations: When sigstore came around a few years ago, it solved the key management problem by using ephemeral cryptographic signing keys. When publishing an attestation, GitHub’s attestation store automatically signs the statement using the same “keyless” mechanism (pioneered in sigstore) and records the transaction in a transparency log (sigstore rekor) to allow anyone to verify it. No long-term keys or secrets are required, removing any concerns of key compromise.

Sharing security metadata: The new attestation store associates statements with an artifact’s cryptographic digest. This means that GitHub can now store claims about any software artifact, whether it’s hosting it or not. Any tool that can hash a piece of software can query GitHub to obtain all the known information about it.

The attestation statement in the screenshot above includes information like which commit the image was built from, and the specific workflow and branch used to trigger the build. 

Finally, GitHub also offers a new private sigstore instance to protect sensitive data that organizations don’t want to record in the public transparency log.

Minder + GitHub Artifact Attestations: Better together 

It can be challenging to keep track of the information in dozens or even hundreds of attestations that can be generated through a complex software release. Minder’s reconciliation model makes it easy to keep the supply chain metadata in check, making it the ideal companion to GitHub’s new attestation repository.

As of today, Minder integrates with Artifact Attestations to provide the following features: 

• Use attestation metadata for enhanced security policies: GitHub’s blog highlights the ability to extract verified attestation contents in JSON format and pipe that to a policy engine. Minder provides native support for using the contents of an attestation to help users write detailed security policies—no JSON piping required. Examples include validating SBOM data like licenses, or verifying the results of an attested security scan. 

• Verify public and private attestations: Minder has already enabled verification of signatures generated through sigstore and cosign. Now, with native support for attestations, Minder can also verify signed attestation statements, including verifying signed attestations against GitHub’s private sigstore instance, protecting sensitive data.

Additionally, Minder can verify artifacts using the new sigstore bundle format used by GitHub’s API, which is not yet supported in cosign.

Tutorial: Verifying and applying policy for GitHub Artifact Attestations in Minder

Minder policy evaluations enable project owners and organizations to ensure that any published artifacts meet their strict criteria. Minder’s checks of attested data alert users of any divergence in the supply chain information associated with their artifacts. 

Let’s imagine a project that publishes its software in a container image. If a malicious actor can compromise the build environment, they could inject malware and produce a malicious version of the image. This image could pass as legitimate as it would continue its journey through the regular build process to be signed and distributed by the same systems and identity. By checking the provenance attestation, Minder can flag the problem right away and alert the security team.

Verifying Attestation Data With Minder

Let’s look at an example verifying a SLSA provenance attestation with a Minder profile. We’ll be using Stacklok’s demo-repo-go, which we have populated with several GitHub actions to build and publish a provenance attestation. We’ll use the build metadata to show both a passing and a failing policy.

To follow this example you need to get the repository registered in Minder: clone the stacklok/demo-repo-go repository; next, enroll GitHub as a provider and register your clone of the repo in Minder. Follow our documentation for more detailed steps.

Verifying a Newly Built Container Image

Fetch all the reference rules by cloning the minder-rules-and-profiles repository.

git clone https://github.com/stacklok/minder-rules-and-profiles.git

In that directory, you can find all the reference rules and profiles.

cd minder-rules-and-profiles

Create the artifact_signature rule type in Minder:

minder ruletype create -f rule-types/github/artifact_attestation_slsa.yaml

Once Minder can access your clone of the repository and the ruletype has been created, create a profile to watch any artifacts built from it. Paste the following into a YAML file:

---
# sample policy for validating SLSA provenance attestations
version: v1
type: profile
name: demo-repo-go-provenance
context:
  provider: github
artifact:
  - type: attestation_slsa_github
    params:
      tags: ["latest"]
      name: demo-repo-go
    def:
      workflow_repository: https://github.com/jakubtestorg/demo-repo-go
      workflow_ref: refs/heads/main
      signer_identity: .github/workflows/build-image-signed-ghat.yml
      event: ["workflow_dispatch"]
      runner_environment: https://github.com/actions/runner/github-hosted

And then create the policy in Minder:

$ minder profile create -f demo-repo-go-provenance.yaml

It’s time to build some artifacts. Navigate to your clone of demo-repo-go and run the image-signed-ghat(latest) workflow.

This workflow uses GitHub’s actions/attest-build-provenance action and pushes the provenance attestation to GitHub’s attestation store. Once the action finishes, Minder should pick up the new image and the profile will be passing, indicating that the new image matches our policy. Run the following to retrieve the profile status:

minder profile status list -n demo-repo-go-provenance

Flagging a Malicious Build Using SLSA Provenance

Now, let’s see how Minder can detect artifacts built from unauthorized workflows or sources. Go into the repository actions and trigger the image-signed-ghat(latest)-malicious workflow. This workflow will build and sign the image, but since this time the image was built from build-image-signed-ghat-malicious.yml, the profile will catch the unexpected builder:

Note that this image is also signed and was even built from the same code base, but a malicious actor could compromise your builder to inject malware into your artifacts. By drafting policies on SLSA provenance metadata you can lock down the build environment and only authorize compliant workloads.

Next Steps

We’re really grateful to GitHub for recognizing the importance of sigstore and attestations, and for taking this step to make it easier for developers to sign and verify attestations natively in the platform. We’re also excited to be able to support Minder users with the ability to use the contents of those attestations to enhance their security policies. 

To start testing out attestation verification and policy application in Minder, head to cloud.stacklok.com. Minder is free to use for public repos. 

We’d also love to hear your feedback on this feature! You can message us on Discord or open an issue in our GitHub repo.