How to Prove Where Your Software Was Built to a Federal Customer

You prove where your software was built by handing the federal customer signed build provenance: a machine readable record, in the SLSA provenance format inside an in-toto attestation, that says which build platform produced the artifact, from which source commit, with which inputs, bound to the artifact's SHA-256 digest. Ship it with a matching SBOM, a signature the customer can check without your private keys, and the exact commands to verify it. A statement in a cover letter is a claim; a signed attestation that a reviewer can check against the artifact in front of them is evidence.

This post is for platform and release engineers at companies selling software to US federal agencies or their primes. It covers what the SLSA build track asks for, how provenance maps to the SSDF and NIST SP 800-53 controls a reviewer will cite, how to produce and present it with open tooling, and, near the end, what Safeguard can and cannot do for this job today.

Key takeaways

• Provenance answers one question: was this artifact built from this source, by this build platform, with these inputs? It does not say the code is free of vulnerabilities or well written.
• SLSA build levels stop at Build L3. The SLSA v1.0 build track defines Build L0 to Build L3, and the current v1.2 specification keeps the same four build levels while adding a separate Source track. Any document that promises "SLSA L4" is quoting the retired pre 1.0 draft.
• The government-wide attestation mandate is gone; the questions are not. OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16, but it tells agencies to build their own risk-based assurance processes and says they may still use the CISA attestation form and ask for a current SBOM. Provenance is one of the cleanest artifacts you can bring.
• Provenance maps to SSDF PS.2.1, PS.3.1 and PS.3.2 and supports, but does not by itself satisfy, the agency's own SP 800-53 SR-4 (Provenance) and SR-11 (Component Authenticity) controls.
• Keyless signing with a public transparency log (the Sigstore model) lets a customer verify a signature against a build identity rather than a key you have to distribute. Key-based signing is also valid but asks the customer to trust how you protect the key.
• Safeguard's part, with labels: Attestation and signing is GA. SBOM generation and analysis is GA. Policies and gates are GA. The Safeguard CLI and local runner are GA. Autonomous remediation is GA and ships switched off, with every category set to Manual. Fork and patch is GA. Trust Center is GA.
• Know the current product limits before you plan around them. Safeguard's docs say its own attestations are signed with Safeguard's key and not written to a public transparency log, that there is no CLI command and no public API for attestations yet, and that the Kubernetes admission controller is not published yet.

What is build provenance, and what does SLSA v1.0 require at each build level?

Build provenance is metadata about how an artifact was produced. The SLSA specification describes it as a record of what entity built the artifact, what process they used, and what the inputs were. In practice it is a JSON document that names the artifact by digest and then describes the build: the builder's identity, the build type, the external parameters (for example the repository and the ref), the resolved dependencies (for example the exact commit the ref resolved to), and run details such as invocation IDs and timestamps.

SLSA, short for Supply chain Levels for Software Artifacts, is maintained by the OpenSSF community under the Linux Foundation. Its v1.0 release reorganised the old single "SLSA 1 to 4" ladder into tracks, and shipped only one track: Build. The levels page for v1.0 says plainly that the previous version used a single unnamed track, SLSA 1 to 4, and that source aspects were removed so 1.0 could focus on the build track. Version 1.2, now the current version on slsa.dev, adds a Source track but leaves the build levels as they were.

The four build levels

The SLSA v1.0 levels page says Build L1 provenance may be unsigned and is "trivial to bypass or forge". That helps you catch your own release mistakes but gives an outside reviewer very little. If a federal buyer will rely on your provenance, Build L2 is the practical floor, because that is where the build platform's signature appears.

At Build L3 the requirement shifts from the producer to the platform. Your pipeline definition matters less than whether the build service isolates runs and keeps the signing material out of reach of the steps you wrote. The SLSA requirements page lists this as provenance being "unforgeable" and isolation being "isolated", on top of the "authentic" provenance and "hosted" platform required at L2. You cannot get there by adding a step to a shared runner that also holds the signing key in an environment variable.

There is no Build L4

The SLSA v1.0 build track ends at L3, and v1.2 still ends at L3. Older blog posts, vendor sheets and procurement templates sometimes ask for "SLSA Level 4" with hermetic builds and two person review. That language comes from the pre 1.0 draft. If an agency questionnaire asks for L4, the honest answer is to say which current build level you meet, quote the spec version you are measuring against, and describe any extra controls (two person review on the release branch, pinned build dependencies, reproducible builds) as additional practices rather than as a level.

What a provenance document looks like

SLSA provenance is an in-toto attestation. The in-toto attestation framework, at version 1.2 of its specification, defines layers: an envelope that handles signing and serialisation, a statement that binds the attestation to one or more subjects (artifacts named by digest) and declares the predicate type, and a predicate that carries type specific metadata. SLSA provenance uses the predicate type https://slsa.dev/provenance/v1, and the SLSA spec says to always use that string even when the page URL shows a minor version.

A trimmed example of what the customer will see once the envelope is decoded:

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "acme-agent-linux-amd64",
      "digest": { "sha256": "9f2c...e41a" }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://example.com/build-types/ci-workflow@v1",
      "externalParameters": {
        "repository": "https://git.example.com/acme/agent",
        "ref": "refs/tags/v4.2.0"
      },
      "resolvedDependencies": [
        {
          "uri": "git+https://git.example.com/acme/agent@refs/tags/v4.2.0",
          "digest": { "gitCommit": "3b7d0c1..." }
        }
      ]
    },
    "runDetails": {
      "builder": { "id": "https://ci.example.com/hosted-runner/slsa3" },
      "metadata": {
        "invocationId": "https://ci.example.com/acme/agent/runs/88123",
        "startedOn": "2026-10-20T14:02:11Z",
        "finishedOn": "2026-10-20T14:09:47Z"
      }
    }
  }
}

The names and URLs are illustrative. The structure is the point: the subject digest ties the claim to one exact file, externalParameters says what the build was asked to do, resolvedDependencies records what the source reference actually resolved to, and builder.id names the platform whose trust level the verifier will look up.

The in-toto spec includes one rule that matters a great deal for federal policy writers: the monotonic principle. Ignoring an attestation, or a field inside one, should never turn a deny into an allow. Their example is to prefer "deny unless a 'no vulnerabilities' attestation exists" over "deny if a 'has vulnerabilities' attestation exists". When you help a customer write an intake rule, write it so that a missing attestation fails closed.

Which SSDF tasks and NIST SP 800-53 controls does provenance satisfy, and which does it not?

Federal reviewers rarely ask for "SLSA" by name. They ask about the SSDF, about EO 14028 section 4(e), and, if they run an authorization package, about the SR family in NIST SP 800-53 Revision 5. Here is how provenance lines up, read from the primary texts.

The policy backdrop after M-26-05

On 23 January 2026, OMB issued M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security". It rescinded M-22-18 and its companion M-23-16, which had required agencies to collect secure development attestations from software producers. The memo puts responsibility on each agency head and says there is "no universal, one-size-fits-all method" of assuring the software on agency networks.

The memo does not ban the old artifacts. It says agencies may choose to use the government-wide resources developed under M-22-18, such as the CISA Secure Software Development Attestation Form, and may adopt contract terms that require a producer to provide a current SBOM on request. It points agencies to NIST SP 800-218 for further reference. So in practice a contracting officer or agency CISO can still ask you for an attestation, an SBOM, or evidence of how your builds are protected, depending on what their agency's own policy now says. Provenance is the evidence that answers the build question directly.

EO 14028 itself was not rescinded by the memo. Section 4(e) still lists the practices the guidance was meant to cover, including 4(e)(vi), maintaining "accurate and up-to-date data, provenance (i.e., origin) of software code or components", 4(e)(vii), giving a purchaser an SBOM, and 4(e)(x), ensuring and attesting to the integrity and provenance of open source software used in a product.

SSDF tasks

NIST SP 800-218 version 1.1 remains the final SSDF. Three tasks in its Protect the Software group map directly to provenance:

• PS.2.1: make software integrity verification information available to software acquirers. NIST's examples include posting cryptographic hashes for release files and using an established certificate authority for code signing so consumers can confirm signatures before use. A signed provenance attestation that carries the artifact digest is integrity verification information.
• PS.3.1: securely archive the files and supporting data, naming integrity verification information and provenance data, for each release. One NIST example is to store provenance data separately from the release files or to sign it.
• PS.3.2: collect, safeguard, maintain and share provenance data for all components of each release, for example in an SBOM. NIST's examples include making provenance data available to acquirers in standards based formats and giving recipients a way to verify its integrity.

The SSDF's own mapping table ties EO 14028 4(e)(vi) to tasks including PS.3.1 and PS.3.2, 4(e)(vii) to PS.3.2, and 4(e)(x) to PS.2.1, PS.3.1 and PS.3.2. That is the paper trail a reviewer will follow.

Note the split in PS.3.2. SSDF "provenance data for all components" reads closer to an SBOM with origin details than to SLSA build provenance. SLSA build provenance tells the customer how your artifact was built. An SBOM tells them what went into it. You need both to answer PS.3.2 in full.

NIST SP 800-53 Revision 5 controls

SR-4 and SR-11 are controls the agency implements on its own systems. Your evidence feeds them; it does not satisfy them for the agency.

• SR-4 Provenance requires the organisation to document, monitor and maintain valid provenance of organisation defined systems, components and data. The discussion text defines provenance as the chronology of the origin, development, ownership, location and changes to a component. Its enhancements cover unique identification of supply chain elements and personnel (SR-4(1)), track and trace of critical components (SR-4(2)), validating that a component received is genuine and not altered (SR-4(3)), and validating internal composition and provenance of critical components (SR-4(4)).
• SR-11 Component Authenticity requires anti-counterfeit policy and procedures that detect and prevent counterfeit components from entering the system, and reporting of counterfeits.

A signed attestation bound to a digest is a direct input to SR-4(3): the agency can check that the file it received is the one your build platform produced. It supports SR-11 for software components in the same way, because a substituted or modified binary will not match the signed digest.

The mapping in one table

NIST SP 800-204D, published in February 2024, is the most practical federal text on this. It lists attestation, provenance and SLSA among its keywords and describes using a build attestation to demonstrate secure build processes at delivery time, gathered from a CI tool to create an evidence trail. Citing it alongside SLSA shows a reviewer that you are following a NIST document, not a vendor's idea of good practice.

How do keyless signing and transparency logs let a customer verify without your keys?

Signing is what turns a provenance file into evidence. There are two common models, and federal customers will meet both.

Key-based signing

You hold a private key, sign the attestation with it, and publish the public key. The customer verifies with the public key. It is simple and works offline. The cost is that the customer has to trust how you protect, rotate and revoke the key, and has to get your public key through a channel they trust. The SSDF's PS.2.1 examples say to review code signing processes, including renewal, rotation, revocation and protection, which is the same concern in NIST's words.

Keyless signing with a transparency log

Sigstore is an open source project under the OpenSSF that changes the model. Its documentation describes three steps: a client such as Cosign signs the artifact, Sigstore's certificate authority, Fulcio, associates the signature with an identity, and the signing event is recorded in Rekor, a public transparency log. Fulcio issues a short lived certificate bound to an OpenID Connect identity, which in CI is the workflow identity of the build job. The private key is discarded after a single signing, and the Sigstore docs say Sigstore services never obtain your private key.

For the customer, the practical result is that verification names an identity, not a key file. They check that the signature was made by a certificate issued to, for example, your release workflow on your repository, by the expected OIDC issuer, and that the signing event appears in the public log. Rekor's documentation describes the log as an immutable, tamper resistant ledger that other parties can query. That gives the agency an independent record that the signature existed at a point in time, even if your own systems were later compromised.

One trade-off to raise: a public log makes the signing identity public. Some federal programmes and air gapped deployments will prefer a private Sigstore instance or key-based signing. Ask before you choose.

What the customer checks either way

Whichever model you use, verification answers the same questions SLSA's verification guidance lists:

1. Is the signature valid, and does it come from a builder identity the customer trusts at a known SLSA build level?
2. Does the attestation's subject digest match the artifact they hold?
3. Do the provenance fields match their expectations: the right source repository, the right tag or branch, the right build type and parameters?

The SLSA verification guide frames expectations as something the consumer forms in advance. Its suggested root of trust is a map from builder identity to SLSA build level, defaulting to Build L1 when a builder is not recognised. In plain terms: the customer should decide which of your builders they trust before your release arrives, not after.

What should the customer receive?

A provenance handover that a reviewer can act on has five parts. Leave any one out and the reviewer has to come back with questions.

SLSA's distribution guidance says producers must publish attestations in at least one place and should publish them in more than one, for example alongside the release and in the package registry. For a federal customer, also include the files in the delivery itself, because many agency networks cannot reach public registries or transparency logs during intake.

A sample verification note

Keep the note short, specific and testable. For example:

Product:       Acme Agent 4.2.0 (linux/amd64)
Artifact:      acme-agent-linux-amd64
SHA-256:       9f2c...e41a
Provenance:    acme-agent-linux-amd64.intoto.jsonl (SLSA provenance v1)
SBOM:          acme-agent-4.2.0.cdx.json (CycloneDX)
Claimed level: SLSA Build L3, measured against SLSA v1.2 build track
Builder:       hosted CI, reusable SLSA generator workflow
Source:        git.example.com/acme/agent, tag v4.2.0, commit 3b7d0c1...
Verify:        see verify.sh in this bundle; expected exit code 0
Contact:       product-security@example.com

How does an agency or a prime verify provenance at intake or deployment?

There are two natural checkpoints: when the software arrives (intake) and when it is about to run (deployment). Primes often add a third, when they repackage your component into their own deliverable.

At intake: verify a release file

The OpenSSF slsa-verifier tool checks a provenance file against an artifact and against the customer's expectations. Its README shows this form for a binary built with the SLSA GitHub generator:

slsa-verifier verify-artifact acme-agent-linux-amd64 \
  --provenance-path acme-agent-linux-amd64.intoto.jsonl \
  --source-uri github.com/acme/agent \
  --source-tag v4.2.0

The tool verifies the signature, checks that the artifact digest matches the subject, and checks the source repository and tag. Its README notes that only GitHub source URIs are supported for that flag today, so a customer receiving builds from another CI system will need a different verifier or a policy engine that reads the in-toto statement directly.

At intake: verify a container image and its attestations

For container images signed keylessly with Cosign, the Sigstore docs show identity based verification. For provenance attached as an attestation, the equivalent is cosign verify-attestation with an attestation type and the same identity flags:

IMAGE=registry.example.com/acme/agent@sha256:DIGEST

# Signature on the image, bound to the release workflow identity
cosign verify "$IMAGE" \
  --certificate-identity-regexp '^https://github.com/acme/agent/.github/workflows/release.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

# SLSA provenance attestation attached to the same digest
cosign verify-attestation "$IMAGE" \
  --type slsaprovenance1 \
  --certificate-identity-regexp '^https://github.com/acme/agent/.github/workflows/release.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

If your organisation signs with a key instead, the Sigstore docs show the key based form:

cosign verify-attestation --key cosign.pub IMAGE

Cosign can also validate in-toto attestations against CUE or Rego policies, which is how an intake team turns "the source must be our approved repository and the tag must match the contract line item" into an automated check.

At deployment: admission control

Agencies and primes that run Kubernetes can enforce provenance at admission with an open admission policy controller, such as Sigstore's policy-controller, configured to require a valid signature and a provenance attestation from named identities before a pod is admitted. This is where the monotonic principle earns its keep: write the rule as "admit only if a valid attestation exists", never as "reject if a bad one exists".

Who verifies what

What breaks provenance?

Provenance is only as good as the build it describes. These are the common ways it stops meaning anything.

Manual or laptop builds

If a release is built on a developer's machine and uploaded, no hosted platform can sign for it, and you are at Build L1 at best. Federal releases should come only from the hosted pipeline, and the release process should refuse artifacts that lack platform signed provenance.

Mutable tags and unpinned references

Provenance records what a ref resolved to at build time. If the customer verifies against a tag, and someone moves that tag after release, the verification can still pass while pointing to different code. Record the commit digest in resolvedDependencies, verify against it, and protect release tags in your source control.

The same applies to container base images and CI actions or plugins referenced by tag. A base image tag can point to new content tomorrow; an action reference by branch can change under you. Pin by digest or full commit SHA.

Unpinned build dependencies

A build that fetches the latest version of a package during the build cannot be reproduced and is easy to poison. Use lock files, pin package versions and checksums, and record the dependencies you can in the provenance. SLSA Build L3 does not by itself require hermetic builds, but a reviewer will ask how you control what the build pulls in.

Signing secrets reachable from build steps

At Build L3 the provenance signing material must not be reachable from user defined build steps. A long lived signing key in a CI secret that every job can read fails that test, even on a hosted platform. Isolate signing in a separate, trusted job or use keyless signing bound to a workflow identity.

Rebuilding after the fact

Re-running a build to "regenerate" provenance for an old release produces provenance for a new artifact, which may not match the digest the customer already holds. Archive provenance at release time, per SSDF PS.3.1, and keep it for as long as you support the release.

What provenance does not prove

It is worth saying this to the customer before they assume it.

• Absence of vulnerabilities. A Build L3 artifact can contain a critical CVE. Provenance proves origin, not safety. You still need vulnerability scanning and a response process.
• Secure source code. If an attacker merges malicious code into your main branch, your hardened build platform will faithfully build and sign it. Source review and branch protection are separate controls; the SLSA Source track in v1.2 is the specification's attempt to address source.
• Trustworthy dependencies. Provenance can list resolved inputs, but it does not vouch for the integrity of each upstream package. Only their maintainers' own provenance, where it exists, can do that.
• Compliance by itself. No artifact satisfies an agency's authorization process alone. Provenance is evidence that feeds a reviewer's judgement.

How Safeguard does this job

Everything above can be done with open tooling and a disciplined pipeline. Safeguard's role is narrower than "generate federal provenance for you", and its docs are frank about what is and is not available today. This section sticks to what the docs and offering files support.

What Safeguard's docs say about attestation and signing today

Safeguard's Attestation and signing capability (GA) is described in its docs as producing in-toto v1 attestations with five predicate types: SLSA Provenance v1, a CycloneDX SBOM, an SPDX SBOM, a vulnerability scan snapshot at build time, and a Safeguard Review generated by Griffin describing what changed, what was patched and what was blocked.

The docs are specific about signing:

• Every attestation Safeguard produces is signed with Safeguard's own ECDSA P-256 key, held in a cloud key management service.
• Signatures are not written to a public transparency log, so there is no Rekor entry to look up.
• You verify Safeguard's signatures with Cosign against Safeguard's published public key, which is why the documented commands pass the flag that skips the transparency log check.
• There is no CLI command for signing yet, no CLI command for verifying or listing attestations yet, and no public attestation API yet.
• Attestation records for your projects, products and components appear on their Attestation tab in the Safeguard app.

Read that against the federal handover above. Safeguard's own signatures follow the key-based model, not the keyless one, and the docs name the trade-off directly: with key-based signing, you rely on Safeguard to protect the key. If your customer requires a public transparency log entry, or requires that the signature identity be your own build workflow, produce and sign your release provenance in your own pipeline with open tooling, as described earlier, and use Safeguard for the analysis and gating around it.

The docs publish verification commands for artifacts Safeguard has signed. For a file with a detached signature, it looks like this:

KEY=cosign.pub   # Safeguard's published public key, saved from the URL in the attestation docs

# Files: a detached signature next to the file
cosign verify-blob --key "$KEY" --insecure-ignore-tlog --signature <file>.sig <file>

Step by step: using Safeguard around your own provenance

1. Scan the repository you release from, in CI. Safeguard's CI/CD docs say there is no plugin, Action or Pipe to install; every system runs the CLI (GA) in a plain shell step. Create a secret key under Settings › Developer with the scopes scans:trigger and scans:read, store it as SAFEGUARD_API_KEY, and add the step. The GitHub Actions guide shows this workflow:

   name: Safeguard
   on:
     push:
       branches: [ main ]
     pull_request:
       branches: [ main ]
   jobs:
     scan:
       runs-on: ubuntu-latest
       steps:
         - name: Safeguard scan
           env:
             SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
             SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
           run: |
             set -eu
             curl -fsSL https://cli.safeguard.sh/install | bash
             "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical
   

   The docs list options on the same command, including a flag that fails the run on a policy gate and a flag that scans on the runner after a checkout step:

   safeguard ci scan --wait --fail-on critical --fail-on-gate all
   

   The first run creates the project.

2. Generate the SBOM that travels with the provenance. SBOM generation and analysis (GA) produces SPDX and CycloneDX. From a terminal, the CLI scans a directory, a container image or an existing SBOM file and writes results as JSON under ./output:

   safeguard scan --dir .
   safeguard scan --image IMAGE
   safeguard scan --sbom FILE
   

   Attach the SBOM for the exact release digest to your handover bundle, and sign it as an attestation in your own pipeline if your customer wants it bound to the artifact.

3. Read the Provenance and Attestation tabs. In the app, open a project and go to Explore SBOM. The docs describe a Provenance tab that shows source repository, build system, commit information and build timestamps for components, and an Attestation tab that shows each component's Safeguard Component Attestation Level (SCAL), the attestation type found (SLSA, Sigstore, in-toto and others), signature status and provenance details. Filter to "Unattested only" to see components rated SCAL 3 to 5.

4. Understand what SCAL means before you quote it. SCAL is part of Attestation and signing (GA). The docs rate components from 0 to 5, where lower is better: SCAL 0 is a fully attested chain including signatures and transparency logs, SCAL 1 has verified build provenance and source, SCAL 2 has basic attestation such as a signed package, SCAL 3 is known in registries but unattested, and SCAL 5 is unknown origin. SCAL is a Safeguard score, not a federal or SLSA level. Use it internally to find which of your dependencies lack upstream provenance; when you talk to an agency, talk in SLSA build levels and SSDF tasks. Package level LCAL scores appear in Open Source Manager.

5. Set a gate on attestation. Policies, gates and guardrails are GA. The attestation docs describe the flow: go to Policies & Gates, create a rule, set a maximum SCAL level, and choose warn or fail. The docs give examples such as "all components SCAL 2 or lower" for production. The Policies & Gates page also lists an SLSA Level 2 template for supply chain attestations. Gates are evaluated by the platform on the scans of connected repositories, and the gate flag on the CI step shown above makes a failing gate fail the build.

6. Use the remediation Provenance category, if you want help moving up. Autonomous remediation (GA) has an Attestation category and a Provenance category; the offering files describe the Provenance options as signed commits in CI, SLSA build provenance, or both. Autonomous remediation ships switched off, with every category set to Manual, so nothing changes in your pipeline unless you turn it on and approve the result.

7. Keep the evidence where the reviewer can find it. Archive the provenance, SBOM, signatures and verification note per release, in line with SSDF PS.3.1. Safeguard's Portal (GA, here meaning the SBOM publish and share product) is built for sharing SBOMs with customers; the Trust Center is GA. Neither replaces the signed files in your delivery bundle.

What about Kubernetes admission control?

The offering files list Kubernetes admission control under attestation and signing, and the attestation docs describe an admission controller that checks SBOM presence, signature validity, SLSA level and signer identity. The Guardrails & Enforcement docs are more recent and more specific: the Kubernetes admission controller is not published yet, so there is nothing to install, and earlier revisions of that page showed a Helm install for a chart that does not exist. Follow the newer page. If you or your customer need admission enforcement today, use an open admission policy controller and point it at your own signing identity or key.

Requirement vs what Safeguard does vs what you still own

What Safeguard does not do

Read this list before you put Safeguard in a federal proposal.

1. It does not make your pipeline hermetic, isolated or hardened. SLSA build levels describe the build platform. Safeguard does not run your release builds, so it cannot raise your build level by itself. Provenance quality depends on the build system you choose.
2. It does not write Safeguard signatures to a public transparency log. Its docs say attestations are signed with Safeguard's own key and there is no Rekor entry. If a customer wants keyless, publicly logged signatures, those must come from your own pipeline.
3. It has no attestation CLI command or public attestation API yet. The docs say there is no CLI command for signing, verifying or listing attestations, and the /v1 REST endpoints described on some docs pages return 404 today. Plan around the in-app Attestation tab and your own tooling.
4. It does not provide a published Kubernetes admission controller yet. The Guardrails docs say it is not published. Use an open admission controller in the meantime.
5. It does not satisfy federal authorization requirements on its own. Safeguard does not hold a federal authorization, and its compliance docs describe its architecture as designed for FedRAMP HIGH, not as authorised. Your agency customer's ATO process, the SR controls and any attestation form remain yours and theirs.
6. It does not tell you the code is secure because it has provenance. Provenance says nothing about vulnerabilities in the built code; vulnerability scanning, reachability and remediation are separate capabilities with their own limits.
7. It does not produce provenance for upstream open source packages. SCAL shows which components have attestations from their maintainers; it cannot create the maintainers' build provenance for them.

FAQ

What is SLSA build provenance in simple terms?

It is a signed record that names an artifact by its digest and says which build platform produced it, from which source and with which inputs. SLSA defines the format, using the predicate type https://slsa.dev/provenance/v1 inside an in-toto attestation.

Does a federal agency still require secure software attestations after M-26-05?

There is no longer a government-wide requirement. OMB M-26-05 rescinded M-22-18 and M-23-16 in January 2026. Each agency now sets its own risk-based assurance process, and the memo says agencies may still use the CISA attestation form and may contract for a current SBOM on request. Expect some agencies to ask for provenance as part of that.

What SLSA level should I target for a federal customer?

Build L3 for production releases, because that is where tampering during the build becomes hard. Build L2 is the minimum at which a reviewer gets a platform signature. Do not claim a level above Build L3; the current specification has none.

How does an agency verify provenance without my private key?

With keyless signing, the agency checks that the signature came from a certificate issued to your build workflow's identity and that the signing event is in a transparency log. With key-based signing, the agency uses your public key. In both cases the agency also checks that the attestation's digest matches the artifact it holds.

What files should I send with a federal software release?

The artifact and its digest, signed SLSA provenance, an SBOM for the same artifact, the verification material (identity and issuer, or a public key), and a short note with exact verification commands and your claimed build level.

Does build provenance satisfy NIST SP 800-53 SR-4?

No, not on its own. SR-4 is the agency's control over its own systems. Your provenance is evidence the agency uses to implement it, especially SR-4(3), validating that a component is genuine and not altered.

Does provenance prove my software has no vulnerabilities?

No. It proves where and how the software was built. A perfectly attested artifact can carry a known vulnerability. Pair provenance with an SBOM, vulnerability scanning and a remediation process.

Can Safeguard sign my release provenance with Sigstore keyless?

Not according to its current docs. Safeguard's docs say its attestations are signed with Safeguard's own key, are not written to a public transparency log, and that there is no CLI command or public API for attestations yet. Use open tooling in your pipeline for keyless release signing.

Where do I see dependency provenance in Safeguard?

In a project's Explore SBOM view, on the Provenance and Attestation tabs. The Attestation tab shows each component's SCAL rating, attestation type and signature status.

Common mistakes

• Promising "SLSA Level 4". It does not exist in the current specification. State your build level against a named spec version.
• Shipping unsigned L1 provenance as if it were evidence. It helps your release team catch mistakes. It does not help a reviewer who has to trust you.
• Verifying against a tag instead of a digest. Tags move. Digests do not.
• Leaving the customer to guess the expected identity. Keyless verification needs the certificate identity and OIDC issuer. Put them in the verification note.
• Writing deny-if rules. A missing attestation should fail closed. Follow in-toto's monotonic principle.
• Treating the SBOM and provenance as the same thing. One says what is in the artifact, the other says how it was built. SSDF PS.3.2 wants component provenance, which in practice means both.
• Regenerating provenance for an old release. Archive it at release time; a rebuild may produce a different digest.
• Assuming the agency can reach public services. Bundle everything needed to verify offline, including the transparency log inclusion proof if you use one.
• Quoting M-22-18 deadlines as current. M-26-05 rescinded it. Describe what the agency now asks for under its own risk-based policy.
• Calling a vendor score a federal level. SCAL and similar scores are internal signals. Agencies read SLSA levels, SSDF tasks and SP 800-53 controls.

Provenance tells your federal customer how your artifact was built, but the reviewer's next question is usually what is inside it and how quickly you fix what they find. The block below covers that second job: getting vulnerable dependencies out of the builds your provenance describes.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository; it reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. For a federal release, the same session is how you clear findings before you cut the build whose provenance you will hand over.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code and then scans from the terminal. Teams with release builds on isolated infrastructure can use the same pattern to keep scanning close to the build, and then attach the resulting SBOM to the provenance bundle.

Click through it at your own pace, or open it full screen.

To try it on your own code, download the apps and CLI at safeguard.sh/download and read the setup guides at docs.safeguard.sh.

For more on the controls behind this post, see NIST 800-53 SR-4 provenance, SR-11 component authenticity, archiving SBOMs and provenance for every release and whether a signed container image means it was scanned.

Quick check

Sources

• SLSA v1.0: Security levels
• SLSA v1.0: Requirements
• SLSA v1.0: Provenance
• SLSA v1.0: Verifying artifacts
• SLSA v1.0: Distributing provenance
• SLSA v1.2: Build track basics
• SLSA v1.2: What's new
• in-toto attestation framework specification v1
• in-toto project
• Sigstore: Overview
• Sigstore: Verifying signatures with Cosign
• Sigstore: In-toto attestations with Cosign
• Sigstore: Rekor
• slsa-verifier README
• slsa-github-generator README
• OMB M-26-05, Adopting a Risk-based Approach to Software and Hardware Security
• Executive Order 14028, Federal Register
• NIST SP 800-218, Secure Software Development Framework v1.1
• NIST SP 800-218 (PDF)
• NIST SP 800-204D
• NIST SP 800-53 Revision 5
• CISA Secure Software Development Attestation Form
• CISA 2026 Minimum Elements for a Software Bill of Materials
• Safeguard docs: Attestation and signing
• Safeguard docs: ESSCM Attestation
• Safeguard docs: OSM Attestation
• Safeguard docs: Explore SBOM
• Safeguard docs: Policies and gates
• Safeguard docs: Guardrails and enforcement
• Safeguard docs: CI/CD integration
• Safeguard docs: GitHub Actions
• Safeguard docs: CI/CD security
• Safeguard docs: Gold

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.