Signed Commits and SLSA: Securing Your Software Supply Chain

Software supply chain security has gone from a niche concern to a real engineering priority. The Solarwinds breach, the Codecov compromise, the xz utils backdoor — each one demonstrated that attackers target the systems that build software, not just the software itself. Signing commits and artifacts, plus implementing the SLSA framework's higher levels, is how production teams are responding.

This post is what each piece actually does, what it costs to adopt, and how to roll it out without breaking the existing developer workflow.

What "Supply Chain Security" Means

The software supply chain is everything that produces the bytes running in production:

• The source code in git
• The developers who commit it
• The CI/CD systems that build it
• The dependencies pulled in during build
• The artifacts produced (binaries, images)
• The deployment system that ships those artifacts

An attacker who compromises any link can ship malicious code that looks legitimate. Signed commits and SLSA address different links in this chain.

Signed Commits

Git commits include an Author field that is whatever the committer typed. There is no verification. An attacker who compromises a developer's machine can commit as anyone they want.

Signed commits add a cryptographic signature proving "this commit came from this verified identity."

# Sign commits using your SSH or GPG key
git config commit.gpgsign true
git config user.signingkey <key-id>

git commit -m "Add feature X"
# Signature is attached

GitHub, GitLab, and Bitbucket all verify signatures and display whether commits are signed.

The verification model:

• GPG keys uploaded to the git host
• SSH keys (newer, simpler) registered with the git host
• The host validates the signature on push and on display

Enforcement:

• GitHub allows requiring signed commits for protected branches
• The PR cannot merge if commits are unsigned
• Branch protection rules enforce this organization-wide

Sigstore for Keyless Signing

GPG key management is painful — keys need rotation, distribution, and backup. Sigstore offers an alternative: keyless signing using OIDC identities.

# Sign using your GitHub identity (no GPG)
gitsign init
git commit -m "Add feature X"
# Signed via OIDC; signature in the commit

The signature certificate is short-lived (10 minutes). The verification is via the public Sigstore log, which records every signature. The cryptographic proof lives in the transparency log; the developer never manages keys.

For most teams in 2026, Sigstore is the easier path to signed commits. The investment is the tooling setup; ongoing key management goes away.

Signing Container Images

The same pattern applies to container images. cosign is the standard tool.

# Sign on push
cosign sign --keyless myregistry.com/myservice:abc1234

# Verify before deploy
cosign verify --certificate-identity ci@example.com \
              --certificate-oidc-issuer https://github.com/login/oauth \
              myregistry.com/myservice:abc1234

The signature is stored in the registry next to the image. Deployments verify the signature before pulling. An attacker who pushes a malicious image cannot fake the CI's signature.

What SLSA Is

SLSA — Supply-chain Levels for Software Artifacts — is a framework for describing how an artifact was built and how trustworthy that process is. Four levels, each adding more verification.

SLSA Level 1. Build process is documented. Provenance attestation is generated. Basic accountability.

SLSA Level 2. Hosted build platform with version-controlled source. Provenance is authenticated.

SLSA Level 3. Hardened build platform. Provenance is non-forgeable. Build environment is isolated per build.

SLSA Level 4. Two-person review. Hermetic, reproducible builds. The gold standard.

Most teams aim for Level 2 or Level 3. Level 4 is hard for most software (hermetic builds are demanding).

Provenance Attestations

A provenance attestation is a signed document that describes how an artifact was built:

{
  "subject": [{
    "name": "myservice",
    "digest": {"sha256": "abc123..."}
  }],
  "predicate": {
    "buildType": "https://github.com/Attestations/GitHubActionsWorkflow@v1",
    "builder": {"id": "https://github.com/yourorg/yourrepo/.github/workflows/build.yml"},
    "invocation": {
      "configSource": {
        "uri": "git+https://github.com/yourorg/yourrepo@refs/heads/main",
        "digest": {"sha1": "def456..."}
      }
    }
  }
}

The attestation says: "This image (sha256:abc123) was built by this CI workflow from this commit." Signed with the CI's identity.

Verification at deploy time checks:

• The image was built by the expected workflow
• The workflow was run on the expected branch from the expected repo
• The signature is valid

An attacker who pushes an image without going through the legitimate CI workflow cannot produce a valid provenance attestation. The deployment refuses to deploy unsigned or wrongly-signed artifacts.

Tooling

For most teams adopting in 2026:

• GitHub Actions has built-in provenance generation via the actions/attest-build-provenance action.
• GitLab CI has similar features.
• cosign handles signing and verification across registries.
• Rekor is the transparency log Sigstore uses.
• Policy controllers in Kubernetes (Kyverno, OPA Gatekeeper) can refuse to deploy unsigned images.

A practical Kubernetes admission policy:

# Kyverno policy
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  rules:
    - name: verify-image
      match:
        resources:
          kinds: [Pod]
      verifyImages:
        - imageReferences: ["myregistry.com/*"]
          attestors:
            - entries:
                - keyless:
                    identities:
                      - issuer: https://github.com/login/oauth
                        subject: github-actions@yourorg

Unsigned images, or images signed by anyone other than the expected CI identity, are rejected at admission.

Rollout Strategy

Adopting supply chain security is a multi-stage effort.

Stage 1: Sign commits. Enable Sigstore-based commit signing. Enforce on protected branches.

Stage 2: Sign images. Add cosign to the build pipeline. Sign all images going to production registries.

Stage 3: Generate provenance. Use the CI's built-in provenance generation. Store attestations in the registry alongside images.

Stage 4: Verify on deploy. Add a policy controller (Kyverno or similar) that verifies signatures and provenance before allowing deploys.

Stage 5: Enforce. Move from "warn" to "deny" on policy violations.

Each stage is a few weeks of work. The total adoption is a quarter or two. Rushing through all stages at once produces broken deploys and frustration.

What This Defends Against

Concrete attack scenarios that signed commits and SLSA prevent:

• Compromised developer machine. Attacker pushes a malicious commit; without the developer's signing key, it does not pass verification.
• Compromised CI runner. Attacker pushes a malicious image; without the CI's signing identity, it does not pass verification at deploy.
• Compromised registry. Attacker replaces an image with a malicious version; the signature does not match.
• Insider attack with limited access. A developer with commit access cannot impersonate the CI; an operator with deploy access cannot push images that bypass the CI.

What this does not prevent:

• A fully compromised CI environment (the attacker gains the CI's signing identity)
• A compromised developer who signs and pushes malicious commits
• Bugs in dependencies (those need SCA, not signing)
• Runtime attacks (those need runtime security)

Supply chain security is one layer in a defense-in-depth strategy.

What This Costs

Real costs to budget:

• Developer onboarding for signing setup (15 minutes per developer)
• Initial CI workflow changes (a few days)
• Policy controller deployment (a week)
• Incident handling when verification fails legitimately (occasional, throughout)

The biggest cost is the cultural shift to "every artifact must be signed." Developers who push images from their laptop need to switch to CI-only pushes. Operators who used to kubectl run need to formalize their tooling.

Regulatory Trajectory

Supply chain security has moved from voluntary to required in several contexts:

• US Executive Order 14028 mandates SLSA for federal procurement
• Some financial regulators require evidence of supply chain controls
• Customer security questionnaires increasingly ask about commit signing and provenance

Adopting these now is cheaper than retrofitting after a customer or auditor asks.

When to Skip

For very small teams or non-production systems, the overhead may exceed the benefit. A side project does not need SLSA Level 3.

For most teams shipping commercial software in 2026: at least Level 2, signed commits, signed images, and admission control. The cost is one quarter of effort; the benefit is one entire category of incidents prevented.

Looking at adopting supply chain security for a delivery pipeline that currently has none? We help teams roll out signing and SLSA without breaking developer workflow. scopeforged.com