SLSA Level 3 build provenance.

Why this page exists.

NIST 800-218 (SSDF) and DoD acquisition guidance both ask vendors to attest build provenance. Procurement reviewers want one of three answers: SLSA Level, in-toto attestation, or a vendor explanation of why neither applies. This page is the first.

SLSA's Build track has four levels. Level 3 requires hermetic builds on a hardened build platform, with provenance signed by the platform itself. kolm meets this today because (a) artifacts are built in CI from source we control, (b) every artifact ships with a signed SLSA provenance attestation alongside the .kolm itself, (c) the K-score gate adds non-SLSA evidence that the artifact passed the eval declared in the recipe.

01 · Source SLSA L1+

Source lives in github.com/sneaky-hippo/kolmogorov-stack. Every release is tagged. Tag protection rules require signed commits on main, two-reviewer approval on merge, and CI green before tag-push is allowed.

The compile-pipeline source is the same monorepo; no out-of-band binaries enter the runner. The artifact's manifest.source.commit field carries the exact SHA-1, and a forensic rebuild starts by checking out that commit.

02 · Build SLSA L3

Builds run on ephemeral GitHub Actions runners under an OIDC identity bound to the repo. The runner image is pinned by SHA-256; the Node and Python toolchains are pinned in lockfiles; network egress on the runner is restricted to the allow-list in .github/workflows/build.yml.

The build emits a provenance.intoto.jsonl file via github.com/slsa-framework/slsa-github-generator. The provenance is signed by the runner's short-lived identity through Sigstore Fulcio. The signing key never lives on disk.

# the provenance payload binds artifact hash to build steps
{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "support-triage-v0.4.0.kolm",
    "digest": { "sha256": "a4b2..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1",
      "externalParameters": {
        "workflow": {
          "ref": "refs/tags/v0.4.0",
          "repository": "https://github.com/sneaky-hippo/kolmogorov-stack",
          "path": ".github/workflows/release-kolm.yml"
        }
      },
      "resolvedDependencies": [
        { "uri": "git+https://github.com/sneaky-hippo/kolmogorov-stack@<commit>" }
      ]
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/actions/runner/github-hosted"
      },
      "metadata": { "invocationId": "..." }
    }
  }
}

03 · Provenance SLSA L3

The provenance is signed before the artifact is published. Two checks pass at the runner before the artifact leaves the build host:

• The artifact's .kolm file SHA-256 matches the subject[].digest.sha256 in the in-toto statement.
• The Sigstore certificate's SAN field references the exact repo and workflow that produced the build.

Both checks are re-runnable offline against the provenance.intoto.jsonl file we publish next to every release. The manifest inside the .kolm additionally carries a provenance.attestation_sha256 field, so receipt verification can confirm the artifact was the one a given provenance covers.

04 · Dependencies SLSA L3

Every transitive dependency is pinned in package-lock.json and requirements.txt. Renovate raises advisory PRs; CI fails if any lockfile drifts from what's committed. The CycloneDX SBOM at /sbom is generated by Syft from the locked tree and published as a separate signed artifact per release.

The provenance attestation references the SBOM by digest under predicate.buildDefinition.resolvedDependencies, so a procurement reviewer can verify both files came from the same build.

05 · Distribution SLSA L3

Artifacts publish to four surfaces: GitHub Releases, npm registry, Homebrew tap, Docker Hub. Each surface receives the same artifact hash and the same provenance file. The Docker image is additionally signed via cosign sign --key sigstore with the same identity as the artifact.

The kolm public registry at /registry stores only the manifest hash plus the SLSA attestation digest. A registry entry is rejected if the artifact's SHA-256 does not match what the provenance claims.

06 · Verification

How a procurement reviewer or an air-gapped operator verifies SLSA provenance, without contacting kolm.ai:

$ cosign verify-attestation \
    --type slsaprovenance \
    --certificate-identity-regexp \
      "https://github.com/sneaky-hippo/kolmogorov-stack/.github/workflows/release-kolm.yml@.*" \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    support-triage-v0.4.0.kolm

# verifies:
#   1. the attestation signature is valid (Sigstore Rekor lookup)
#   2. the signing identity is the kolm release workflow
#   3. the artifact SHA-256 matches what the attestation claims

# pairs with the artifact-level receipt check:
$ kolm verify support-triage-v0.4.0.kolm

# both must pass before the artifact is trusted in production.

For air-gapped environments, the attestation file ships alongside the artifact and is verifiable with slsa-verifier against a Rekor public-key bundle distributed in the same release tarball. Verification works without outbound network.

Beyond SLSA: the K-score gate.

SLSA tells you the artifact you hold is the artifact the build pipeline produced. The K-score gate tells you the artifact passed the recipe-declared eval before it was ever published. The two together cover both halves of "is this safe to deploy."

The provenance attestation carries an optional predicate.metadata.kolm.k_score field whose value is the K-score the artifact passed at compile time. Procurement reviewers who care about both supply-chain integrity and capability-floor evidence can check one file for both. See k-score methodology for the formula.

Where this maps in procurement.

Procurement reviewers who want the full attestation bundle for a vendor questionnaire: mail security@kolm.ai with the release tag of interest; typical turnaround one business day.