Attestation and Provenance in Safeguard: SLSA, Sigstore and SCAL Scores

Safeguard checks whether each component in your software carries build provenance, in-toto attestations and valid signatures, then rates it on the Safeguard Component Attestation Level (SCAL), a 0 to 5 scale where lower is better. You read the result on a project's Attestation and Provenance tabs, verify Safeguard's own signed artifacts yourself with cosign, and use policies and gates to block components that fall below the level you set.

That is the short answer. The rest of this post explains what SLSA, in-toto and Sigstore each prove, what the CISA attestation form asks a producer to sign, how SCAL and the package level score LCAL relate to SLSA, how the product flow works step by step, and where provenance stops being useful. Attestation and signing is generally available (GA) in Safeguard. A few pieces around it are not, and we say which.

Key takeaways

• Attestation and signing (GA): Safeguard reads SLSA provenance, in-toto attestations, Sigstore signatures and traditional package signatures on the components it finds, and produces in-toto attestations for artifacts your pipelines build.
• SCAL and LCAL scores (GA): SCAL rates a component in your project from 0 (fully attested) to 5 (unknown origin). LCAL is the package level attestation score in the Open Source Manager, on a 0 to 4 scale.
• Attestation and Provenance remediation categories (GA, ships off): autonomous remediation has an Attestation category ("move up one level" is the recommended strategy) and a Provenance category (signed commits in CI, SLSA build provenance, or both). Autonomous remediation ships switched off, with every category set to Manual.
• Policies, gates and guardrails (GA): you can set a maximum SCAL level per environment and choose warn or fail.
• Compliance and GRC suite (GA) and Portal (GA): provenance and SBOM data feed EO 14028 checks, an SLSA framework view and attestation letter templates.
• OSM and Gold Open Source, Gold Registry (GA): Gold Registry artifacts carry SLSA provenance and a signature you can check against Safeguard's published public key. Fork and patch is early access.
• Not available yet, per the docs: Safeguard's own Kubernetes admission controller, a CLI command to sign images or packages, a CLI command to verify or list attestations, and a public attestation API.
• The hard limit: provenance proves where and how an artifact was built. It does not prove the code is safe.

The problem: you cannot see how most of your software was built

A modern application is mostly other people's code. You pull packages from public registries and base images from container registries, and your own build system stitches them together. For each of those artifacts you usually know a name and a version. You rarely know where it was built, from which source revision, by which build system, and whether the file you downloaded is the same file that build produced.

That gap matters because several attacks never touch the source code you would review. Someone can tamper with a build server, upload a package built from a private fork, swap an artifact in a registry after release, or publish a release from a laptop that was never part of the official pipeline. A vulnerability scanner will not catch any of these, because the version number is correct and no CVE exists yet.

Provenance and attestation are the industry's answer. Provenance is a record of how an artifact was built. An attestation is a signed, machine readable statement about an artifact, and provenance is the most common kind. A signature ties the statement to an identity so that a consumer can tell whether it was forged. Three open specifications do most of the work: SLSA, in-toto and Sigstore. On top of them sit the government rules that turned the practice into a procurement question.

What SLSA build levels prove

SLSA (Supply chain Levels for Software Artifacts) is a specification from the Open Source Security Foundation (OpenSSF). The current version on slsa.dev is v1.2. Version 1.0 introduced the idea of tracks, and its Build track has four levels, L0 to L3. According to the SLSA v1.0 levels page, each level adds protection against a specific class of tampering:

Two details trip people up. First, SLSA describes L1 provenance as something that "can be used to prevent mistakes but is trivial to bypass or forge." L1 is a starting point, not tamper protection. Second, there is no Build L4. The SLSA v1.0 levels page notes that the earlier draft used a single track numbered 1 to 4 and that v1.0 removed the source aspects to focus on the build. Version 1.2 adds a separate Source track with its own levels, from Source L1 (version controlled) to Source L4 (two party review). When you see "SLSA 4" in older material, including some Safeguard docs pages, read it as the pre 1.0 numbering that bundled hermetic builds with two person review.

SLSA provenance itself is an in-toto attestation with the predicate type https://slsa.dev/provenance/v1. It records a build definition (what was asked for, including resolved dependencies) and run details (which builder ran it, identified by builder.id). A verifier compares that provenance against expectations: the right source repository, the right builder, the right digest.

What in-toto attestations prove

The in-toto Attestation Framework defines the envelope that SLSA provenance, SBOMs and scan results travel in. Its spec describes an attestation as authenticated metadata about one or more software artifacts, built from four layers:

• Predicate: the actual claim, with a type specific schema (SLSA provenance, a CycloneDX SBOM, a vulnerability scan).
• Statement: binds the predicate to a subject artifact, identified by digest, and names the predicate type.
• Envelope: handles signing and serialization.
• Bundle: groups several attestations together.

The point of the layering is that a policy engine can check the same structure whatever the claim is. The current tagged release of the framework is v1.2, and the statement type is still https://in-toto.io/Statement/v1. in-toto proves that a named signer made a specific claim about a specific digest. It does not prove the claim is true; that depends on who signed and how much you trust them.

What Sigstore proves

Sigstore is an OpenSSF project for signing and verifying artifacts such as release files, container images and SBOMs. Its overview describes three parts working together. The cosign client signs the artifact. Fulcio, a free code signing certificate authority, issues an X.509 certificate tied to an OpenID Connect identity, valid for 10 minutes. Rekor, a transparency log, records the artifact digest, signature and certificate in an append only ledger that anyone can audit.

This is "keyless" signing: the signer never manages a long lived private key, and a verifier checks the identity in the certificate plus proof that the signature was logged in Rekor. Sigstore also supports traditional key based signing, where you verify with a public key, optionally held in a cloud key management service. The cosign docs show both forms: cosign verify with a key for key based verification, and cosign verify with an expected certificate identity and OIDC issuer for keyless verification.

What Sigstore proves is identity and integrity: this digest was signed by this identity (or this key), and it has not changed since. It says nothing about how the artifact was built unless the signed payload is a provenance attestation, and nothing about whether the code is safe.

What the CISA attestation form asks a producer to attest

The Secure Software Development Attestation Form, released by CISA on 11 March 2024, is a different kind of attestation: a legal statement by a company, not a cryptographic statement about a file. Section III of the common form asks the producer to attest that it consistently uses four groups of practices derived from NIST SP 800-218, the Secure Software Development Framework (SSDF):

1. The software is developed and built in secure environments, including separated and protected environments, logged and audited trust relationships, multi factor authentication, minimised use of risky software in the build environment, encryption of sensitive data such as credentials, and continuous monitoring.
2. The producer makes a good faith effort to maintain trusted source code supply chains with automated tools or comparable processes.
3. The producer maintains provenance for internal code and third party components "to the greatest extent feasible."
4. The producer uses automated tools to check for vulnerabilities, before releases and on an ongoing basis, with a policy to address them and a vulnerability disclosure program.

The form must be signed by the CEO or a designee with authority to bind the company, or replaced by an assessment from a FedRAMP certified or agency approved third party assessor organization. The form's OMB control number, 1670-0052, carries an expiration date of 31 March 2027.

The policy around the form changed this year. On 23 January 2026, OMB memorandum M-26-05 rescinded M-22-18 and its companion M-23-16, the memos that had required agencies to collect the form. M-26-05 says agencies may still choose to use the form and may contract for a current SBOM on request. CISA's form page is now marked as archived content. In practice, item 3 (provenance) has not gone away; it has moved from a blanket requirement to something agencies and commercial buyers ask for case by case.

The rules behind provenance

Three primary texts set the expectations most buyers quote:

• Executive Order 14028, section 4(e). Subsection (vi) calls for maintaining accurate, up to date data and provenance (origin) of software code or components. Subsection (x) calls for "ensuring and attesting, to the extent practicable" to the integrity and provenance of open source software used in a product.
• NIST SP 800-218 (SSDF v1.1). Practice PS.2 asks producers to provide a way to verify software release integrity; task PS.2.1 is making integrity verification information available to acquirers, with code signing as an example. Task PS.3.1 covers archiving release files with their integrity and provenance data. Task PS.3.2 asks producers to collect, safeguard, maintain and share provenance data for all components of each release, for example in an SBOM, and to protect the integrity of that data. The SSDF's own mapping ties EO 14028 4(e)(vii) to PS.3.2 and 4(e)(x) to PS.2.1, PS.3.1 and PS.3.2.
• NIST SP 800-204D (February 2024). Strategies for integrating software supply chain security into DevSecOps CI/CD pipelines, with attestation, provenance, SBOM and SLSA among its keywords.

What each layer proves, side by side

How Safeguard models attestation: SCAL, LCAL and the Risk Score

Safeguard turns these signals into scores so that you can sort and gate on them. There are three that matter here, and they do not all run in the same direction.

SCAL: Safeguard Component Attestation Level (GA)

SCAL rates each component in a project's SBOM from 0 to 5. Lower is better. The ESSCM Attestation docs define the levels as follows:

The docs also map SLSA levels onto SCAL. In that table, SLSA 1 (documented build process) maps to SCAL 2, SLSA 2 (hosted build, signed provenance) to SCAL 1, SLSA 3 (hardened build platform) to SCAL 0 or 1, and "SLSA 4" (two party review, hermetic builds) to SCAL 0. As noted above, the last row uses the older SLSA numbering; under SLSA v1.0 and later, those properties are split between Build L3 and the Source track. The practical reading is simple: a component with signed provenance from a hosted builder lands around SCAL 1, a component with only a package signature lands around SCAL 2, and anything with no attestation at all starts at SCAL 3.

LCAL: the package level attestation score (GA)

In the Open Source Manager, each package page shows an attestation score called LCAL on a 0 to 4 scale, next to its risk score, vulnerability count and license. The OSM package Attestation tab lists provenance verification status, build attestation, signature verification and SLSA level.

The public docs we read do not define each LCAL level the way they define SCAL. One hint about direction: the OSM user guide lists "LCAL 3+ attestation" as a Gold Directory criterion, which suggests LCAL counts upward (higher is better), the opposite of SCAL. Treat that as an inference and check the package page legend in your tenant before you write a policy around LCAL.

The Risk Score and why direction matters

SCAL also feeds the component Risk Score (RS), which runs 0 to 10, lower is better. The Risk Score docs weight attestation (SCAL) at 30% and provenance verification at 25% of the score, with package health, behavioural and historical signals making up the rest. Provenance factors listed in the docs include whether the build came from an official CI/CD system, whether signatures verify, whether the signature appears in a public transparency log and whether the build is reproducible.

Here is the direction problem that confuses first time users:

If you build dashboards or gates across these, label the direction on every chart. A "3" is acceptable on one scale and poor on another.

Where attestation shows up in the product

Safeguard's flagship product, the Enterprise Software Supply Chain Manager (ESSCM, GA), gives every project an SBOM explorer with a row of tabs. Two of them carry the attestation story.

The Attestation tab

Per the ESSCM Attestation docs, you reach it from Projects, then a project, then Explore SBOM, then Attestation. The table lists each component with:

• Component: package name and version.
• SCAL Level: 0 to 5.
• Attestation Type: SLSA, Sigstore, in-toto and so on.
• Signature Status: Verified, Unverified or None.
• Provenance: build origin information.

You can filter by SCAL level, by attestation type, or with Unattested Only, which shows SCAL 3 to 5. Clicking a component opens a detail view with four blocks: a summary (SCAL level, attestation type, last verified time, Pass, Fail or Partial status), provenance information (build platform, source repository, build trigger, timestamp, builder identity), signature details (signature type such as PGP or Sigstore, signer identity, Valid, Invalid or Expired status, certificate chain) and transparency log details (log entry, entry ID and inclusion proof when one exists).

The Explore SBOM docs also describe an attestation score shown alongside the risk score on this tab, with sections for SLSA provenance, Sigstore signatures and build reproducibility.

The Provenance tab

The Provenance tab tracks where components came from: source repository, build system and commit information. Use it when the question is "which revision and which builder" rather than "is there a signature."

How Safeguard decides a component's level

The ESSCM docs describe a five step process each time Safeguard analyses a component: fetch attestations from registries and transparency logs, verify the cryptographic signatures, check that the claims match the component, check for revocation, then assign the SCAL level. The project dashboard also plots risk against attestation, so you can see which projects combine high risk with low attestation coverage.

Step by step: read a component's attestation, then verify the artifact yourself

This walkthrough uses only what the docs show. Where the docs show no screen or command, we describe the outcome instead.

1. Get an SBOM into Safeguard. Connect a repository, container registry or SBOM upload in the app, or scan locally with the Safeguard CLI (GA). The CLI docs show one target per run:

   safeguard scan --dir .
   safeguard scan --image nginx:latest
   safeguard scan --sbom sbom.json
   

   Results land under ./output by default. Note that safeguard scan reports findings and exits 0 when the scan ran; it does not fail the build on its own.

2. Open the Attestation tab. Go to Projects, open the project, choose Explore SBOM, then Attestation. Sort by SCAL level so the red and orange rows sit on top.

3. Filter to the gaps. Turn on Unattested Only to list SCAL 3 to 5 components. These are the components where Safeguard found no attestation it could verify. Expect this list to be long for most real projects; see the limits section for why.

4. Open one component. Read the summary first. A Partial verification status means some checks passed and others did not, so read the blocks below it to see which. Then check the provenance block: does the source repository match the project you expected, and is the builder identity the official CI system for that project?

5. Check the signature block. Compare the signer identity with what the project publishes. For a keyless Sigstore signature, the identity is the OIDC subject in the Fulcio certificate, often a CI workflow. For a key based signature, it is the key holder.

6. Verify a Safeguard signed artifact yourself. For artifacts Safeguard signs, such as Gold Registry images, you do not have to trust the app's checkmark. The Attestation and Signing docs publish the commands. Safeguard signs with its own ECDSA P-256 key held in a cloud key management service and publishes the public key:

   KEY=https://registry.safeguard.sh/_gold/keys/cosign.pub
   # Container images: signature and SLSA provenance
   cosign verify --key "$KEY" --insecure-ignore-tlog registry.safeguard.sh/library/python@sha256:<digest>
   cosign verify-attestation --key "$KEY" --insecure-ignore-tlog --type slsaprovenance registry.safeguard.sh/library/python@sha256:<digest>
   # Files: a detached signature next to the file
   cosign verify-blob --key "$KEY" --insecure-ignore-tlog --signature <file>.sig <file>
   

   The insecure-ignore-tlog flag is there because Safeguard does not write its signatures to a public transparency log, so there is no Rekor entry to check. Verify by digest, not by tag, so that you are checking the exact bytes you will run.

7. Verify an upstream artifact signed with Sigstore keyless signing. For third party images that use keyless signing, follow the Sigstore docs and pin the expected identity and issuer:

   cosign verify <image URI> --certificate-identity=name@example.com \
     --certificate-oidc-issuer=https://accounts.example.com
   

   If the identity you expect is a release workflow, use that workflow's identity rather than any identity that happens to verify. A signature from the wrong identity is still a valid signature.

8. Decide and record. If your own check agrees with Safeguard's SCAL level, record it with the project version. If it disagrees, trust the cryptographic check, then raise it with Safeguard support so the score can be corrected.

There is no CLI command for verifying or listing attestations yet, and no public attestation API. Several docs pages show /v1 REST calls for attestation data, but those pages carry a banner saying every path under the /v1 API returns 404 today. Use the app, or cosign directly, for now.

Producing attestations for your own builds

Reading other people's attestations is half the job. The other half is raising the level of what you ship, because your customers will run the same checks on you.

What Safeguard attests

The Attestation and Signing docs list five attestation types, all in in-toto v1 format: SLSA Provenance v1, a CycloneDX SBOM, an SPDX SBOM, a vulnerability scan snapshot at build time, and a Safeguard Review, a Griffin generated summary of what changed, what was patched and what was blocked. Every attestation carries the artifact's SHA-256 digest and a signature made with Safeguard's key, so any change to the artifact invalidates every attestation attached to it.

Adding the attest step in CI

The docs show the attest step for GitHub Actions and say the same step runs in other CI systems and in Safeguard's runner:

- name: Attest build
  uses: safeguard/attest@v2
  with:
    artifact: ./dist/app.tar.gz
    predicates:
      - slsa-provenance
      - sbom-cyclonedx
      - vuln-scan

The docs are explicit that there is no CLI command for signing container images or packages yet. For those, the ESSCM docs point to open tooling: cosign for signing, and the SLSA project's GitHub generator workflow for Build L3 provenance on GitHub. Our walkthrough of attesting build provenance for a container image on GitHub covers that route in detail, and build provenance explained covers the concepts.

Which SLSA level you can reach

The docs are honest that the level depends on your build environment, not on the attest step. Their table says any build system using the attest step reaches L1; GitHub Actions, GitLab CI or the Safeguard runner can reach L2; L3 needs an isolated, parameter free build, such as GitHub reusable workflows or the Safeguard runner on a dedicated VM. The docs also list an "L4" row (hermetic builds plus two person review) using the older numbering. If you need that, scope it with Safeguard in a demo before you commit to it, and map it to SLSA Build L3 plus a Source track level in anything you write for a customer.

The key trade-off

Safeguard's own signatures are key based. The docs state the trade-off plainly: a public transparency log gives an independent public record of every signature, while key based signing means you rely on Safeguard to protect the key, which is held in a cloud key management service and never leaves it. Some buyers will accept that; others require Rekor entries. Know which your customers are before you promise anything.

Attestation and provenance remediation strategies

Autonomous remediation (GA, ships off) covers eight categories, and two of them target this topic directly. The offering documentation lists these strategies:

"Move up one level" is the conservative choice: improve each project's attestation by one step rather than jumping to the highest level, which usually needs build platform changes that a pull request alone cannot make. "Aim for highest" pushes further. "Smart" lets the model pick per item based on context, risk and impact. In the Provenance category, the recommended setting does both: require signed commits in CI and add SLSA build provenance to the pipeline.

Three things to know before you switch these on:

• Off by default. Autonomous remediation ships switched off. Every category starts at Manual, and strategy choices are saved but not applied until the master Autonomous Remediation toggle is on. Nothing changes in your repositories until you decide it should.
• Pull requests, not silent changes. Fixes arrive as pull requests that your normal review applies to. Pipeline changes deserve a careful human review, because a provenance step that signs the wrong artifact is worse than none.
• The platform has to support it. A pull request can add an attest step or require signed commits. It cannot turn a self hosted build server into a hardened, isolated build platform. Reaching SLSA Build L3 is an infrastructure decision.

The docs also list manual ways to raise a component's SCAL level, which are worth following even with automation off. For SCAL 5 components: find attested alternatives, ask maintainers to add attestation, document the risk, or build your own attested version. For SCAL 3 and 4: check whether newer versions carry attestation, use the Gold Directory for pre verified alternatives, and watch for attestation being added. For more on the eight categories, see our post on autonomous remediation in Safeguard.

Policies, gates and Kubernetes admission control

Scores are only useful if something acts on them. Safeguard's policies, gates and guardrails (GA) are where that happens.

SCAL rules in Policies and Gates

The ESSCM docs describe the flow: go to Policies & Gates, create a new rule, set a maximum SCAL level, and choose warn or fail. Their examples are a sensible starting point:

The Risk Score docs add an RS threshold, for example fail if any component scores above 6, and a critical systems rule requiring SCAL 0 to 1. Start with warn. Most teams discover that a strict production rule fails on day one because so much upstream software carries no attestation, and a gate that always fails gets bypassed.

You can also write policies in plain English and let Safeguard draft the rule; our post on plain English security policies to release gates covers that flow.

Guardrails that consume attestations

The Guardrails and Enforcement docs show policies defined in YAML, evaluated against a document that combines SBOM, vulnerability, license, signature, provenance and reachability data. Two of the rules in the docs example touch attestation directly:

    - id: requires-sbom-attestation
      condition: attestations.sbom == null
      effect: BLOCK
    - id: requires-slsa-l3
      condition: slsa.level < 3
      effect: WARN

The docs also list built in guardrails you can enable, including "EO 14028 SBOM required" (a CycloneDX SBOM attestation signed in the last 90 days), "SLSA level 3 provenance" (a Sigstore verifiable provenance attestation) and "Unsigned container" (block pods pulling images without a valid cosign or Notation signature). Every blocking guardrail supports time boxed exceptions, and the docs say every guardrail decision produces a signed audit record.

Gating in CI

Gates are evaluated by the platform on the scans it runs for connected repositories. The GitHub Actions docs show how a pipeline can fail on a gate:

      - 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' options table says to add the fail-on-gate option (with the value all) to that command to fail on a policy gate, so a SCAL rule set to fail can stop the merge.

Kubernetes admission: what the docs say today

This is the part to read carefully. The Attestation and Signing docs describe an admission controller that checks SBOM presence, signature validity, a minimum SLSA level (default Level 3) and an allow list of signer identities on every pod admission. The Guardrails and Enforcement docs, updated more recently, say plainly that the Kubernetes admission controller is not published yet and there is nothing to install. They warn not to install any chart claiming to be Safeguard's admission controller. Safeguard's own Helm chart is for Guard, its runtime protection product, which is early access.

So, for now, enforce at admission with open tooling and keep Safeguard for scoring and gating earlier in the pipeline:

• Sigstore policy-controller validates signatures and attestations on container images at admission and can apply CUE or Rego policies to attestations. Per the Sigstore docs, enforcement is opt in per namespace:

  kubectl label namespace my-secure-namespace policy.sigstore.dev/include=true
  

  A ClusterImagePolicy can name a key authority with a PEM public key, which is how you would trust an image signed with a published key such as Safeguard's. The controller also supports a warn mode, which is the right place to start.

• Kubernetes ValidatingAdmissionPolicy, stable since Kubernetes v1.30, is an in process alternative to admission webhooks that uses CEL expressions. It is well suited to checks on the request itself, such as allowed registries or requiring digests rather than tags. Signature verification still needs a controller built for it.

Our post on pinning, signing and verifying base images covers the container side in more depth.

How provenance evidence feeds EO 14028 checks and compliance

Provenance is also evidence. Safeguard routes it into three places.

EO 14028 checks in ESSCM

The EO 14028 Compliance Checks docs describe automatic validation of each project's SBOM against the NTIA minimum elements (supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data and timestamp) plus machine readable format. Each project gets a compliance score built from data completeness, format compliance, component coverage and SBOM freshness, with a Compliant, Partially Compliant or Non-Compliant status. You see it on the project's Compliance tab and in the organisation level EO 14028 widget on the Dashboard. To export, open the project and choose Export, then EO 14028 Compliance Report, in PDF, HTML or JSON.

The same page describes attestation letters for federal customers: go to Compliance, then Attestations, select the project and version, choose an attestation template, review and sign, and export the signed attestation. Treat the output as a draft that your officer reviews. Under the CISA form, the person who signs is your CEO or a designee who can bind the company, and the statement covers your practices, not a scan result.

EO 14028 verification in Portal

Portal (GA) is the publish, share and SBOM management side of Safeguard (the same name also covers the free entry tier). The Portal Compliance docs list automated SBOM checks for NTIA minimum fields, unique component identifiers, supplier information, version information, dependency relationships and hash values, with a percentage score and a gap analysis on the SBOM's Compliance tab. Hash values matter here: provenance and signatures identify artifacts by digest, so an SBOM without hashes cannot be tied back to the attested artifact.

The SLSA framework in the compliance suite

The compliance and GRC suite (GA) includes SLSA as a framework, switched on by default in a workspace. The framework page lists six requirements a scan decides, each tied to a SLSA v1.0 clause: provenance exists, machine readable attestation, artifact digests, resolved dependencies recorded, unambiguous artifact identity (for example a PURL) and pinned, specific versions. It also lists controls from Safeguard's catalog that you evidence yourself, such as two person review for protected branches, hermetic and parameterless builds, and restricting access to signing keys, plus policy templates including an "SLSA Build Provenance Policy." That split is useful: the scan can see digests and identifiers in your SBOM, but it cannot see whether your build platform is isolated, so those controls need evidence from you.

Requirement versus Safeguard versus you

What provenance cannot tell you

Provenance is easy to oversell, so it is worth being precise about its blind spots.

• Malicious or careless maintainers. If the person with commit rights writes harmful code and pushes it through the official pipeline, every attestation will be valid. Provenance proves the official process ran. It does not judge what the process was given.
• Source compromise before the build. The SLSA v1.0 threats page says directly that v1.0 does not address source threats, including unauthorised changes submitted through the normal interface and compromise of the source repository. The Source track in v1.2 begins to address this, but adoption is early.
• Compromised build dependencies. SLSA v1.0 lists a compromised build dependency as out of scope, noting that provenance may list dependencies only on a best effort basis. Pinning dependencies by digest is the mitigation SLSA suggests.
• A stolen signing key. Key based signatures are only as strong as the key's protection. Keyless signing narrows this with short lived certificates and a public log, but a compromised CI identity can still sign.
• Absence is not evidence of attack. Most packages on public registries ship without provenance. A SCAL 3 component is usually just an unattested package, not a tampered one.

Provenance reduces one class of risk, artifact and build tampering, very well. Pair it with code review, vulnerability management and runtime controls for the rest.

What Safeguard does not do

Be clear about these before you put attestation in a contract or an RFP answer:

1. It does not prove code is safe. A SCAL 0 component can still contain vulnerabilities or harmful logic. SCAL measures the trustworthiness of origin and build, not the content.
2. It does not publish a Kubernetes admission controller yet. The Guardrails and Enforcement docs say it is not available and there is nothing to install. Use an open admission controller in the meantime.
3. It has no CLI or API path for attestation yet. The docs say there is no CLI command to sign container images or packages, no CLI command to verify or list attestations, and no public attestation API. The /v1 endpoints on the attestation, risk score and EO 14028 pages return 404 today.
4. Its own signatures are not in a public transparency log. Safeguard signs with a key in a cloud key management service and you verify with its published public key. If your policy requires Rekor inclusion proofs for every signature, Safeguard signed artifacts will not meet it.
5. It cannot make upstream projects publish attestations. Many components will sit at SCAL 3 or higher until their maintainers adopt provenance. Safeguard can show the gap, suggest alternatives and point you to Gold equivalents; it cannot fill the gap for a package it does not build.
6. It does not sign your CISA attestation form or make you compliant. It produces evidence, reports and letter templates. The legal attestation, and the practices behind it, are yours.
7. It does not turn on remediation by itself. The Attestation and Provenance categories ship off, set to Manual, and the pull requests they open still need review. They cannot harden your build infrastructure.
8. It does not publish a full LCAL level definition in the docs we read. If you plan to gate on LCAL, confirm the scale and direction in your tenant first.

Common mistakes

• Treating SLSA L1 as tamper protection. L1 provenance can be forged. Ask for L2 or L3 when tampering is the worry.
• Quoting "SLSA Level 4." The current spec has Build L0 to L3 and a separate Source track. Older material, including some vendor docs, still uses the old numbering.
• Verifying by tag. Tags move. Verify signatures and attestations against the image digest.
• Accepting any valid signature. With keyless signing, check the certificate identity and issuer you expect. A valid signature from an unexpected identity should fail your policy.
• Mixing score directions. SCAL and the Risk Score are better when lower; the TPRM vendor score is better when higher. Label every chart.
• Gating production on day one. A hard "SCAL 2 or lower" rule will likely block most builds at first. Start in warn mode, measure, then tighten.
• Treating the CISA form as a scan output. It is a signed statement about company practices. A tool can support it with evidence; it cannot sign it.
• Showing /v1 API calls in internal runbooks. They do not work today. Use the app, cosign or the CI steps the docs show.

FAQ

What is a SCAL score in Safeguard?

SCAL, the Safeguard Component Attestation Level, rates each component in a project from 0 to 5 based on the attestations Safeguard can verify. 0 means a complete chain including signatures, transparency log entries and reproducible builds; 5 means the origin cannot be verified. Lower is better.

How does SCAL map to SLSA levels?

Per Safeguard's docs, SLSA 1 maps roughly to SCAL 2, SLSA 2 to SCAL 1, SLSA 3 to SCAL 0 or 1, and the old "SLSA 4" to SCAL 0. Current SLSA has Build levels up to L3, so read the last row as the pre 1.0 numbering.

What is the difference between SCAL and LCAL?

SCAL scores a component inside your project's SBOM in ESSCM. LCAL is the attestation score for a package in the Open Source Manager, on a 0 to 4 scale. Both are part of attestation and signing (GA).

Can I verify Safeguard's signatures without trusting Safeguard's UI?

Yes. Safeguard publishes its cosign public key at registry.safeguard.sh, and the docs show cosign verify, cosign verify-attestation and cosign verify-blob commands. Because Safeguard does not log its signatures in Rekor, the commands skip the transparency log check.

Does Safeguard use Sigstore keyless signing?

Safeguard reads and verifies Sigstore signatures, including keyless ones, on the components it analyses. For artifacts it signs itself, the docs say it uses its own key and cosign rather than writing to the public Rekor log.

Does SLSA provenance prove a package is not malicious?

No. It proves which build platform built which digest from which source. If harmful code was committed to the source, valid provenance will describe the build faithfully.

Is the CISA secure software attestation form still required?

OMB M-26-05, dated 23 January 2026, rescinded M-22-18 and M-23-16, which had required agencies to collect it. Agencies may still choose to use the form, and some contracts still ask for it, so check each buyer's terms.

Can Safeguard block unsigned images in Kubernetes?

Not with its own admission controller yet; the docs say it is not published. You can gate on SCAL and SLSA level in CI with Safeguard, and enforce signatures at admission with an open controller such as Sigstore policy-controller.

How do I raise my own software's SLSA level with Safeguard?

Add the attest step to your pipeline, move builds to a hosted or isolated build platform, and consider the Provenance remediation category (GA, ships off), whose recommended strategy adds signed commits and SLSA build provenance through pull requests.

Why do so many of my dependencies show SCAL 3 or higher?

Because most open source packages are published without provenance or signatures. A high SCAL means "unverified," not "compromised." Prioritise the components on critical paths, look for attested versions or Gold equivalents, and accept the rest with a documented reason.

From provenance to fixes

Attestation tells you how a component was built; it does not fix the vulnerable versions you find while you are looking. The same SBOM that drives your SCAL view also drives remediation, and Gold Registry artifacts come with the signed provenance this post 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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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: install, open the interactive terminal with safeguard, ask it to fix the lodash CVE in a repo, and watch it read the finding and advisory, ask before each command, edit package.json to lodash 4.17.21, run npm install and npm test with your approval, print a summary and push nothing. It ends with /permissions, /model and /scan. The demo does not show attestation, but /scan is how the SBOM behind a project's Attestation tab gets built from your working copy.

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, then scans from the terminal. This is the route for teams that will not grant Safeguard repository access: the scan runs locally, and the resulting SBOM is what Safeguard uses to show provenance and SCAL levels.

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

To try it yourself, download Safeguard at safeguard.sh/download and read the setup guides at docs.safeguard.sh/docs. For the evidence side of Gold artifacts, see how the Gold Registry works and our guide to reading a Gold Registry evidence page. For SBOM basics, see SBOM generation and analysis in Safeguard, and for how supplier scores differ from component scores, see supplier software risk with Safeguard TPRM.

Quick check

Sources

• Safeguard docs: Attestation and Signing
• Safeguard docs: ESSCM Attestation (SCAL)
• Safeguard docs: ESSCM Risk Score
• Safeguard docs: ESSCM Explore SBOM
• Safeguard docs: ESSCM EO 14028 Compliance Checks
• Safeguard docs: OSM Attestation
• Safeguard docs: OSM User Guide (LCAL)
• Safeguard docs: Guardrails and Enforcement
• Safeguard docs: Portal Compliance
• Safeguard docs: SLSA framework coverage
• Safeguard docs: GitHub Actions integration
• Safeguard docs: CLI usage
• Safeguard docs: Auto-Fix
• Safeguard Gold cosign public key
• SLSA v1.0: Security levels
• SLSA v1.0: Provenance
• SLSA v1.0: Threats and mitigations
• SLSA v1.2: Source track requirements
• in-toto Attestation Framework spec
• Sigstore: Overview
• Sigstore: Fulcio
• Sigstore: Rekor
• Sigstore: Verifying signatures with cosign
• Sigstore: Verifying in-toto attestations
• Sigstore: Kubernetes policy-controller
• Kubernetes: Validating Admission Policy
• CISA: Secure Software Development Attestation Form
• CISA: Secure Software Development Attestation Common Form (PDF)
• OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security
• Executive Order 14028, Federal Register text (govinfo)
• NIST SP 800-218, Secure Software Development Framework v1.1
• NIST SP 800-204D

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