Slsa Build Provenance Firmware Sign Verify

title: "SLSA Build Provenance for Firmware: What to Collect, How to Sign, How to Verify" description: "Practical implementation guide for SLSA build provenance in firmware pipelines, covering provenance generation, signing with Sigstore, verification workflows, and integration with SBOMs." date: 2026-04-19T08:00:00Z lastmod: 2026-04-19T08:00:00Z draft: false hero: "/images/hero/slsa-build-provenance-firmware-sign-verify-1600x900.jpg" tags:

• Embedded Linux
• ProteanOS
• Supply Chain Security category: dev

SLSA (Supply-chain Levels for Software Artifacts) provides a framework for reasoning about build integrity. For firmware, build provenance answers the question: "Can I prove that this binary was built from this source, using this configuration, on this build system?" In 2026, with the EU Cyber Resilience Act and NIST SSDF pushing for evidence-based supply chain security, SLSA provenance is moving from nice-to-have to required.

SLSA levels for firmware

SLSA defines four levels of build integrity:

Most embedded teams should target SLSA 2 or 3. SLSA 4 requires hermetic builds, which is challenging (though possible) with Yocto or Buildroot.

What provenance contains

A SLSA provenance document records:

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "firmware-image-v2.1.0.bin",
      "digest": {
        "sha256": "a1b2c3..."
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://example.com/YoctoBuild/v1",
      "externalParameters": {
        "repository": "https://git.example.com/product.git",
        "ref": "refs/tags/v2.1.0",
        "layerManifest": "kas/product.yml"
      },
      "internalParameters": {
        "yoctoRelease": "scarthgap-5.0.5",
        "machine": "product-board"
      }
    },
    "runDetails": {
      "builder": {
        "id": "https://ci.example.com/builders/firmware-builder"
      },
      "metadata": {
        "invocationId": "build-12345",
        "startedOn": "2026-03-15T10:00:00Z",
        "finishedOn": "2026-03-15T11:23:00Z"
      }
    }
  }
}

The key fields:

• Subject: The artifact (firmware image) with its hash
• Build type: How the build was orchestrated (Yocto, Buildroot, custom)
• External parameters: What the builder was told to build (repo, ref, config)
• Internal parameters: Build system configuration not controlled by the user
• Builder ID: Which build system produced the artifact

Generating provenance

In CI/CD (GitLab CI, GitHub Actions)

Most CI systems can generate SLSA provenance natively or via plugins.

GitHub Actions: Use the slsa-framework/slsa-github-generator action. It generates signed provenance in the Sigstore transparency log.

GitLab CI: Use the slsa-verifier and custom provenance generation. GitLab CI does not have a native SLSA generator as of 2026, but the in-toto attestation format can be generated by a script step.

From Yocto

Yocto 5.2's build system generates build manifests that can be transformed into SLSA provenance. The buildhistory class records:

• Package versions and sources
• Build configuration (MACHINE, DISTRO, local.conf settings)
• Compiler versions and flags

A post-build script transforms this into SLSA provenance format.

From Buildroot

Buildroot's make legal-info generates a list of packages with versions, licenses, and source URIs. Combined with the .config file and build log, this provides sufficient data for SLSA 1-2 provenance.

Signing provenance

Unsigned provenance is just metadata. Signing makes it tamper-evident.

Sigstore (recommended for open-source)

Sigstore provides keyless signing using OIDC identity tokens. The signature and certificate are recorded in a public transparency log (Rekor).

# Sign provenance with cosign
cosign attest --predicate provenance.json \
  --type slsaprovenance1 \
  firmware-image-v2.1.0.bin

Internal PKI (recommended for proprietary firmware)

For firmware not published to public registries, use your organization's PKI:

# Sign with internal key
cosign attest --predicate provenance.json \
  --type slsaprovenance1 \
  --key cosign.key \
  firmware-image-v2.1.0.bin

Store the signing key in a hardware security module (HSM) or cloud KMS. Do not store it in the CI system's environment variables.

Verification workflow

Provenance is useful only if someone verifies it.

Before deployment

Before deploying firmware to devices, the deployment system verifies:

1. The firmware image hash matches the provenance subject
2. The provenance signature is valid
3. The builder ID matches an authorized build system
4. The source repository and ref match the expected release

slsa-verifier verify-artifact firmware-image-v2.1.0.bin \
  --provenance-path provenance.json \
  --source-uri https://git.example.com/product.git \
  --source-tag v2.1.0 \
  --builder-id https://ci.example.com/builders/firmware-builder

During audit

Auditors can use the provenance to trace any deployed firmware image back to its exact source code, build configuration, and build environment. This is the primary value for compliance.

Integration with SBOMs

Provenance and SBOMs are complementary:

• SBOM answers: "What is in this firmware?" (packages, versions, licenses)
• Provenance answers: "How was this firmware built?" (source, config, builder)

Link them through the artifact hash. The SBOM and provenance both reference the same firmware image hash, creating a complete picture.

The firmware SBOM documentation covers SBOM generation, and the VEX guide covers vulnerability status communication.

Common pitfalls

Non-reproducible builds: If your build is not reproducible, two builds from the same inputs produce different hashes. The provenance for one build does not verify the other. Work toward reproducible builds (Yocto has good support for this).

Missing source pinning: If your build fetches unpinned dependencies (e.g., SRCREV = "${AUTOREV}"), the provenance's external parameters do not fully describe the build inputs. Pin everything.

Signing key in CI environment: If the signing key is in a CI environment variable, anyone with CI access can sign arbitrary provenance. Use keyless signing (Sigstore) or HSM-backed keys.

Integration with ProteanOS

ProteanOS build pipelines generate provenance as part of the standard ProKit build process. The provenance format follows the in-toto specification and includes ProteanOS-specific build parameters.

The packaging system embeds source references that feed directly into provenance generation - each package's control file includes the upstream source URI and version.

For EU CRA compliance, the EU CRA compliance guide shows how SLSA provenance fits into the broader compliance evidence package.

Summary

SLSA build provenance for firmware is achievable today. Generate it in CI, sign it with Sigstore or your PKI, verify it before deployment, and link it to your SBOMs. The investment is modest - a few hundred lines of CI configuration - and the payoff is concrete: you can prove exactly how every firmware image was built, from source to binary.