Supply Chain Security with GitHub Artifact Attestations and Kyverno

GitHub Artifact Attestations makes it easy to cryptographically sign software artifacts like scan reports and SBOMs. But this is where they stop.  Provenance data and SBOMs is produced in CI, stored in the registry, and occasionally reviewed, yet rarely enforced.

This gap undermines security posture and complicates auditing, ultimately making systems more vulnerable to breaches by failing to verify the integrity of the software being deployed.

Frameworks such as SLSA (Supply-chain Levels for Software Artifacts) emphasize not just generating provenance, but ensuring it is:

• Verifiable
• Tamper-resistant
• Enforced in downstream systems 

Without runtime enforcement, even an SLSA Build Level 3 pipeline can be bypassed. A compromised credential or a manual image push can still introduce untrusted artifacts into production; in other words, attestations alone improve visibility, but not assurance.

To achieve meaningful supply chain security, those attestations must be evaluated at deployment time. In this post, you will learn how to use Kyverno’s ValidatingImagePolicy to fill this critical security gap by enforcing checks during admission controls.

Easier Attestations: 

GitHub Attestations 

By leveraging Sigstore and OpenID Connect (OIDC), GitHub enables teams to generate:

• SLSA v1.0 Provenance: Cryptographically signed claims about how the artifact was built.
• SPDX-compliant SBOMs: A manifest of every dependency included in the build in the form of an SBOM.
• Keyless Identity: OIDC-backed claims that link the image to a specific GitHub repository and workflow.

This eliminates the “Key Management Tax” as there are no private keys to rotate or to lose. The identity of the GitHub Runner is the key.

Key Distinction: Artifact Attestation vs. Image Signing. While Image Signing simply proves that an image was signed by a specific key or identity, Artifact Attestation provides a broader “provenance” or paper trail. Attestation doesn’t just say “this is me”; it provides signed metadata about how the software was built, what tools were used, and which vulnerabilities were present at that time. This metadata is critical for enforcing compliance checks during admission controls and runtime.

Here is an example of what this attestation looks like when viewed in the GitHub UI:

Generating and attesting artifacts

• After the step where the binary or image has been built, add the following steps to generate artifact attestations.

# Build provenance (how it was built)
# Post binary build
- name: Generate artifact attestation
uses: actions/attest-build-provenance@v3
with:
  subject-path: 'PATH/TO/ARTIFACT'


# Post image build
- name: Generate artifact attestation
uses: actions/attest-build-provenance@v3
with:
  subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
  subject-digest: 'sha256:fedcba0...'
  push-to-registry: true

---

# 1. Generate SBOM for the binary (tool depends on language/build system)
# 2. Attest the SBOM
- name: Generate SBOM attestation
uses: actions/attest-sbom@v3
with:
  subject-path: 'PATH/TO/ARTIFACT'
  sbom-path: 'PATH/TO/SBOM'


# Post image build
# Generate the SBOM from the built image, then attest it and push to the registry:
# 1. Generate SBOM from the built image (e.g., SPDX format)
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
  image: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}
  format: spdx-json
  output-file: sbom.spdx.json

# 2. Attest the SBOM and push to the registry
- name: Generate SBOM attestation
uses: actions/attest-sbom@v3
with:
  subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
  subject-digest: ${{ steps.build.outputs.digest }}
  sbom-path: sbom.spdx.json
  push-to-registry: true

• Verification with GitHub  CLI:

gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R ORGANIZATION_NAME/REPOSITORY_NAME

Enforcement With Kyverno

Enforcement at deployment time is the final link in a secure supply chain. With the introduction of the ImageValidatingPolicy in Kyverno, you can now enforce these GitHub-native attestations using a high-performance, CEL-based (Common Expression Language) policy engine.

Unlike traditional signature checks, this policy doesn’t just ask “Is this signed?” It asks:

1. Who built it? (OIDC Issuer: https://token.actions.githubusercontent.com)
2. Where was it built? (OIDC Subject: https://github.com/my-org/my-repo/.github/workflows/ci.yml@refs/heads/main)
3. Is the provenance valid? (SLSA v1.0 & v2.0 Predicate)

By validating these specific identities and building metadata, Kyverno transforms raw signals into a verifiable audit trail, ensuring that only artifacts from authorized pipelines reach production, a critical requirement for meeting SOX, PCI, NIST and internal governance standards.

A Practical Policy Example

Below is a snippet of a Kyverno policy that requires an image to have a valid SLSA provenance attestation from a specific GitHub repository before it can be deployed:

# ImageValidatingPolicy: verify GitHub Artifact Attestation (SLSA provenance).

apiVersion: policies.kyverno.io/v1
kind: ImageValidatingPolicy
metadata:
  name: verify-github-provenance
  annotations:
    policies.kyverno.io/title: Verify GitHub SLSA provenance attestation
    policies.kyverno.io/category: Software Supply Chain Security
    policies.kyverno.io/description: >-
      Enforces SLSA provenance from GitHub Artifact Attestations (build-and-attest workflow).
spec:
  validationActions: [Deny]
  failurePolicy: Fail
  webhookConfiguration:
    timeoutSeconds: 30
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  matchImageReferences:
    - glob: "ghcr.io/nirmata/*"
  attestations:
    - name: slsa
      intoto:
        type: "https://slsa.dev/provenance/v1"
  attestors:
    - name: cosign
      cosign:
        keyless:
          identities:
            - subject: "https://github.com/nirmata/demo-supply-chain/.github/workflows/build-and-attest.yml@refs/heads/main"
              issuer: "https://token.actions.githubusercontent.com"
        ctlog:
          url: "https://rekor.sigstore.dev"
  validations:
    - expression: >-
        images.containers.map(image, verifyAttestationSignatures(image, attestations.slsa, [attestors.cosign])).all(e, e > 0)
      message: "Failed to verify SLSA provenance attestation."

Explore the Implementation

To see this flow in action, you can explore the reference implementation, which provides an end-to-end look at:

• GitHub Actions workflows for generating and attaching attestations (provenance + SBOM).
• Advanced Kyverno policies for verifying SLSA provenance and SBOMs.
• Sample configurations to test blocked vs. allowed deployments, giving you a safe environment to trigger (and resolve) policy violations.

Operationalizing at Scale with Nirmata

While the “Build, Attest, Deploy” flow works for a single repository, production scale introduces new challenges. Managing individual policies across hundreds of clusters and thousands of repositories requires centralized governance.

This is where Nirmata helps teams move from experimental setups to enterprise-grade enforcement by providing:

• Centralized ​​Policy Management: Centrally manage and synchronize policies across global cluster fleets from a single control plane. This ensures uniform, SLSA-aligned enforcement without the manual effort of per-cluster configuration.
• Governed Exception & Remediation Workflows: Move beyond a simple “Allow/Deny” model. Nirmata provides structured workflows to act on violations, from granting audited, time-bound “break-glass” exceptions to triggering automated “re-scan or re-attest” actions to bring artifacts into compliance.
• Unified Visibility & Integrated Alerting: A single pane of glass to track violations across the organization and environments. Automatically assign violations to the responsible teams and send real-time alerts through integrations with Slack, Email, Jira, and ServiceNow.

Summary

GitHub Artifact Attestations make it easy to generate high-quality supply chain metadata. Kyverno’s ImageValidatingPolicy makes it possible to enforce it at runtime.

Together, they enable:

• SLSA-aligned provenance
• Keyless verification
• Automated admission control
• Stronger production guarantees

By validating attestations at the Kubernetes boundary, organizations move from “we generate security signals” to “we enforce them.”

That shift is essential for building trustworthy, resilient software supply chains.

Explore Nirmata for free at: https://www.nirmata.io/security/signup.html