The SLSA v1.2 guidance for verifying artifacts is direct: provenance has no effect unless somebody inspects it. The consumer must establish that the attestation belongs to the artifact being accepted and that the builder, source and build inputs match a policy it trusts. A signed statement in a registry is evidence to evaluate, not a deployment decision by itself.
Quick answer. An artifact provenance acceptance check should verify the attestation signature, match the statement's
subjectdigest to the exact artifact, accept only a trusted builder identity, and compare source,buildTypeandexternalParameterswith the consumer's expectations. Record each result against a named policy and reject or escalate a mismatch before the artifact enters the approved release path. The matrix below is Stingrai's synthesis of SLSA v1.2 verification guidance, not an official SLSA checklist.
This is a practical issue for an enterprise that buys software, deploys open-source packages or runs its own CI pipelines. Teams often ask a supplier for an SBOM or an attestation and then file the document without linking it to the binary under review. The more useful question is whether a specific digest can be traced to a permitted build path under a policy that the consuming organization actually controls. The answer needs an evidence record that a release approver, security reviewer or procurement owner can read later.
The approved SLSA v1.2 specification has Build and Source tracks. Its Build track overview describes Build L1 as provenance showing how a package was built, Build L2 as signed provenance generated by a hosted build platform, and Build L3 as a hardened build platform. The Source track covers a different question: the trustworthiness and completeness of how a source revision was created. A buyer should say which track and claim it is evaluating, rather than treating a level label as a universal security grade.
Why a signed attestation still needs a consumer decision
An attestation is a statement about an artifact. Signature verification establishes that the statement was issued through an accepted signing mechanism. It does not decide whether the identified builder is trusted for this release, whether the source repository is the one the buyer expected, or whether the artifact digest matches the binary in hand. SLSA's consumer guidance puts those checks into the verification process. The same guidance says unrecognized external parameters should fail the check, because a parameter the policy does not understand can change what was built.
That separation matters for procurement. A vendor might supply an attestation that is cryptographically valid but refers to a test build, a different repository or a different package version. A release pipeline might verify a signature and then deploy a different digest selected by a mutable tag. The accepted object should be the digest, not a human-readable name that can move. The evidence record should identify what was inspected and where the matching artifact came from.
GitHub's artifact attestation documentation makes a similar point for its own implementation: generating an attestation alone provides no security benefit until it is verified, and an attestation does not guarantee that the artifact is secure. GitHub describes information such as workflow, repository, organization, environment, commit SHA and triggering event in its attestations. Those fields can help a consumer judge origin, but the buyer still needs an explicit policy for which combinations are permitted.
Figure 1: Each gate tests a different claim about the same artifact digest. The gate sequence is Stingrai's acceptance design, based on SLSA v1.2 verifying artifacts. A failed or absent gate needs an explicit disposition rather than an implied pass.
The policy can be narrow. For example, a particular internal service may accept artifacts from a named repository and builder workflow, while an acquired product may temporarily use a different approved build path. The consumer should record those exceptions with owners and expiration dates. A global rule such as “all signed attestations are acceptable” is too broad to tell a release approver what to do.
The original artifact provenance acceptance matrix
Use this table as a buyer acceptance worksheet for a single artifact digest. Each row answers a separate question, identifies evidence and states the default disposition. The required checks in the first column are grounded in SLSA's verification guidance. The particular record format, gates and procurement disposition are Stingrai's editorial design; SLSA does not prescribe this table or a penetration test for each artifact.
Consumer gate | What to compare | Evidence to retain | Default disposition when absent or mismatched |
|---|---|---|---|
Artifact identity | Local or registry artifact digest against attestation | Digest calculated from accepted bytes and statement subject | Reject: the statement is about another object |
Envelope signature | Signature and verification result using the approved trust root | Verifier output and trust-root version | Reject unless the verification failure is resolved |
Provenance type | Statement's SLSA provenance predicate type against the expected type | Predicate type and parser result | Reject or route to a separately defined policy |
Builder identity | Attested builder ID against the consumer's trusted builder map | Builder ID, policy version and allowed scope | Reject or approved exception review |
Source origin | Canonical source repository and revision against the expected source | Repository identity, revision and immutable reference | Reject or investigate source substitution |
Build definition |
| Build type, approved procedure and version | Reject or approved change review |
External parameters | Every declared parameter against expected values and allowed keys | Parameter set with sensitive values redacted | Reject unknown or unapproved values |
Release context | Workflow, environment and event against the organization's release rule | Relevant identity fields and policy decision | Hold for review if the context is outside policy |
Source track claim | Separate source attestation against its declared Source track claim, if used | Source revision and source policy evaluation | Do not infer a Source claim from Build evidence |
Final decision | All applicable gate outcomes for the same digest | Pass, reject or exception; owner, time and policy version | Do not mark accepted until required gates pass |
The first seven rows explain the core SLSA consumer logic. SLSA specifically calls for a trusted builder ID, signature verification, matching the subject digest, and checking expected source, buildType and externalParameters. The release-context row is a consumer policy extension that uses fields a platform may provide. The Source track row prevents a common category error: Build provenance tells the consumer about an artifact's build path, while a Source track claim concerns how the source revision was created. Only claim the latter when the corresponding source evidence has been checked.
The default dispositions in the final column are deliberately explicit. A missing attestation is not equivalent to a passing check. Neither is an attestation for another digest, even if the package name looks right. Some organizations may allow temporary exceptions, but those need a separate business and security decision. The acceptance matrix makes the boundary visible without pretending that every organization has the same policy.
Define the trusted builder map first
SLSA tells consumers to ensure that the builder identity is in a map of trusted builder IDs. That map is the heart of a usable policy. A consumer should identify the build platforms it accepts, the repositories each builder may build, the workflows allowed for production, and the person who can approve a new entry. The map should be versioned. Otherwise a verifier may produce a green signature result while the real trust decision remains undocumented.
Keep the map specific to the artifact's risk and deployment context. A documentation site, a customer-facing authentication service and a privileged agent may use different release rules. The policy should state which source organizations and branches are acceptable, whether a pull request build can be used as a release, and what environment or workflow identity must appear when the attestation platform supplies it. Those are consumer choices, not universal claims made by SLSA.
The builder map also needs a change path. Build systems migrate, repository names change and workflows are refactored. When that happens, the owner should approve the new identity before it is admitted to the production policy. Capture the old and new values, the reason for the change, and a sample verification result. A silent wildcard inserted to avoid broken deployments removes the evidence the map was intended to provide.
The policy should be tested with negative controls. A valid attestation from a builder that is not on the trusted list should fail. So should a valid attestation for a different source revision. These are safe consumer checks against test artifacts or synthetic records; they do not require modifying a supplier's production pipeline. They show that the verifier enforces the rule rather than merely parsing a file.
Bind the statement to the bytes being deployed
The digest comparison is the most direct gate. The SLSA verification text says to verify that the statement's subject matches the digest of the artifact in question. In an internal release, calculate the digest from the bytes handed to deployment and compare it to the attested subject. In a supplier review, ask for the digest of the exact package or container image the organization will ingest. Keep the result together with the attestation and verification output.
A mutable version label can assist humans but cannot replace that link. An image tag may be updated. A download page may serve a new build under a familiar filename. A procurement attachment may refer to a release candidate rather than the signed production artifact. The acceptance record should carry both the familiar name and the immutable digest, with the digest controlling the decision.
Record the point in the process where the digest was measured. If a package is repacked, mirrored or transformed after verification, the consumer must determine whether the new bytes are the same artifact. If they are not, the old result cannot automatically be applied to the new object. This is a practical chain-of-custody question, not a request for more paperwork. A single digest field often resolves an otherwise vague argument about which release was reviewed.
The same principle applies to post-deployment review. When an incident responder asks what ran in an environment, the accepted digest should map back to the recorded attestation and policy decision. That link is more valuable than a statement that “the vendor uses SLSA,” because it supports a specific investigation and a specific remediation decision.
Compare source and build inputs with the approved release path
SLSA's verification guidance includes the expected canonical source repository and the expected buildType and externalParameters. These are separate checks. A build from the right repository can still use a different build procedure. A familiar procedure can be run with an unapproved input. The consumer should record what was expected before looking at the attestation, so a reviewer does not adjust the policy after seeing a convenient value.
The expected source can be defined at different levels of strictness. Some policies accept any release tag in a controlled repository; others require a pinned revision or a signed release workflow. The important point is that the accepted rule be explicit. If the attested source is a fork, a personal namespace or an unrecognized repository, the result should be held for review even when the code appears similar. The provenance is telling the consumer where the bytes came from, not whether a human has inspected every line.
Treat external parameters as inputs that can alter the build. SLSA says that unrecognized parameters should fail verification. A policy may permit an architecture selector or a documented release mode, while rejecting a new unreviewed flag. Record parameter names and approved values, taking care to redact any sensitive material. If the attestation format or platform omits a value the policy requires, record the limitation. Do not fill the gap with an assumption that the build was normal.
The Source track needs its own acceptance question. SLSA v1.2 Source requirements explain that consumers can inspect source attestations against their standards for how a revision was created. That evidence may be useful for a supplier with strong repository protections, but a Build track result should not silently become a Source track claim. Keep separate rows and separate verdicts when both are requested.
Use platform attestations without overstating them
GitHub provides a concrete implementation path. Its artifact attestation documentation describes signed attestations for artifacts built by Actions and notes the repository, workflow and commit information they can contain. GitHub's verification guide documents gh attestation verify for checking them. A consumer can use that command as part of an evidence workflow, then apply its own allowed signer, repository and workflow policy.
Do not translate a platform marketing statement into a claim about every release. GitHub's documentation discusses SLSA Build levels in the context of its own attestation mechanisms and workflows, but the consumer still has to check the specific artifact and the conditions of its build. The SLSA v1.2 levels describe evidence properties; they do not mean that any package built on a named platform automatically satisfies the buyer's policy. Use the version of the standard and the version of the attestation format that were actually evaluated.
The same discipline applies when a registry or deployment service performs some verification upstream. SLSA guidance allows consumers to verify independently. For high-impact artifacts, the consuming team should understand what the upstream service checked and what remains its own decision. “The registry accepted it” is a useful event only when the registry's trust policy matches the consumer's intended rule.
An SBOM can complement this evidence by listing components, but it answers a different question. Provenance identifies the claimed build origin and process; an SBOM describes contents. A vulnerable dependency can exist in a correctly attested build, and an artifact with a complete SBOM can still have an unverified build origin. A procurement request that asks for both should state how each will be reviewed.
Record a decision a buyer can audit
A useful acceptance record is short enough for a release approver to read but precise enough for a reviewer to reproduce. The following fields are Stingrai's proposed record, not a mandated SLSA form.
Record field | Entry to preserve |
|---|---|
Artifact | Package or image name, version and immutable digest |
Policy | Consumer policy ID, version, owner and applicable environment |
Attestation | Statement reference, predicate type, signature verification result |
Origin | Builder ID, source repository and source revision |
Inputs | Build type and accepted external parameters |
Decision | Pass, reject or exception with a clear reason |
Exception | Approver, scope, expiry and compensating review when used |
Recheck | Time, verifier version and result for the deployed digest |
The record should be reproducible from retained evidence. Keep verifier output, the attestation reference and the policy snapshot together. If a field contains a secret, retain only the minimum redacted form needed to explain the result. The goal is to preserve the decision logic, not to copy credentials into an audit packet.
For a pass, each required gate must be satisfied for the same digest. For a reject, the record should identify which expectation failed: subject mismatch, invalid signature, unknown builder, unexpected source, build procedure or parameter. For an exception, state the specific release and expiration. An exception should not quietly amend the global trusted builder map. These distinctions let a procurement or risk committee approve a time-bound decision without diluting the standard path.
Retest after a material change. A new artifact digest, builder migration, repository move or workflow change can invalidate an earlier result. Re-running verification is inexpensive compared with asking a later reviewer to infer that a previous sign-off covered a different build. A retest record should point to the new digest and policy version, even if the human-readable product version did not change.
Procurement and assessment questions
A buyer can ask a supplier for the exact artifact digest, its SLSA provenance, the statement format and predicate version, the builder identity, the source repository and revision, and the documented verification procedure. Ask whether attestations are produced for the release artifacts actually delivered, rather than only for internal CI samples. Ask what changes when a release is rebuilt, repackaged or mirrored. The answer should let the buyer perform or independently reproduce the acceptance checks.
In an RFP or security schedule, request a sample evidence pack for one current release and specify that the buyer will evaluate it against a named policy. Useful acceptance language is: “For each in-scope production artifact, provide a digest-bound provenance statement and a verification method. The buyer will check signature validity, trusted builder identity, expected source and build inputs, and the match between statement subject and delivered bytes.” This is suggested procurement language from Stingrai, not a quotation from SLSA.
A penetration test can complement that review by examining whether the CI/CD identity, secrets, artifact permissions and deployment gates can be misused within the authorized scope. It does not replace provenance verification, and provenance verification does not determine whether a deployed application has an authorization flaw. A buyer should scope those as separate questions and ask the assessor to show observed evidence for each. Stingrai's cloud penetration testing includes credential and secret exposure across code, CI/CD and container images, which is relevant to the build environment around an attestation.
For a regulated enterprise, the evidence package can support a software supply chain control discussion. It should not be labeled a certification of the supplier's entire development process. The report should say what artifact was inspected, which policy was applied, what passed, what failed and what was outside the review. That scope statement makes the result useful to an auditor and prevents a broad claim from being built on one passing release.
Where Stingrai fits
Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified pentesters, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.
For this problem, a human-led cloud penetration test can examine the CI identities, build permissions, secrets and artifact access that surround the provenance statement. Stingrai's work supports a customer's compliance program and produces evidence for its audit. A provenance consumer should still apply its own artifact acceptance policy to each release. Where the delivered software is a web application or API, an application penetration test addresses runtime authorization and business logic that build provenance cannot establish. Request an engagement scope through Get a Quote.
Frequently Asked Questions
What should a consumer verify in SLSA artifact provenance?
A consumer should verify the attestation signature, match its subject digest to the exact artifact, accept the builder identity under a trusted policy, and compare source, build type and external parameters with expected values. SLSA v1.2 describes these checks in its artifact verification guidance.
Does a valid provenance signature mean the artifact is safe?
No. A valid signature supports the authenticity of an attestation under the chosen trust root. It does not establish that the builder is approved for the release, the source is expected, the artifact has no vulnerabilities or the deployed bytes match the attested subject.
Is an SBOM the same as build provenance?
No. An SBOM describes components in an artifact, while build provenance describes the claimed origin and build process for a specific artifact. A buyer can request both and evaluate each against a separate policy.
What is the first check when accepting an attested artifact?
Identify the immutable digest of the artifact being delivered, then confirm that the provenance statement's subject matches it. Without that binding, the rest of the attestation may concern a different build.
What does SLSA Build L3 prove?
SLSA v1.2 describes Build L3 as a hardened build platform. Its verification guidance also says Build L3 does not cover compromise of the build platform itself. A consumer still has to verify the specific artifact and apply its own trusted builder and input policy.
Should an unknown external parameter fail provenance verification?
Yes. SLSA's verifier guidance says unrecognized external parameters should fail verification. The consumer should document allowed parameter names and values rather than silently accepting a new input that might change the build.
Can GitHub artifact attestations be used as acceptance evidence?
Yes, if the buyer verifies an attestation for the exact delivered artifact and applies a policy for acceptable repository, workflow, environment and signer identity. GitHub provides a verification command, but says attestation generation alone provides no security benefit until verification occurs.
When is a penetration test useful alongside provenance verification?
A penetration test is useful when the buyer needs observed evidence about CI/CD permissions, credentials, artifact access or the deployed application's security. It complements digest-bound provenance checks and should be scoped to the systems and controls the buyer wants assessed.
Related reading
References
SLSA. Specification v1.2. https://slsa.dev/spec/v1.2/. Approved specification and track scope, read 16 October 2026.
SLSA. Build track basics v1.2. https://slsa.dev/spec/v1.2/build-track-basics. Build level descriptions, read 16 October 2026.
SLSA. Build: Verifying artifacts v1.2. https://slsa.dev/spec/v1.2/verifying-artifacts. Consumer verification requirements, read 16 October 2026.
SLSA. Source requirements v1.2. https://slsa.dev/spec/v1.2/source-requirements. Source track purpose, read 16 October 2026.
GitHub. Artifact attestations. https://docs.github.com/en/actions/concepts/security/artifact-attestations. Product attestation behavior, read 16 October 2026.
GitHub. Using artifact attestations and reusable workflows. https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating. Verification command, read 16 October 2026.
Talk to Stingrai
For a human-led assessment of CI/CD permissions, build identities, artifact access and the deployed application, get a scope and quote from Stingrai. The outcome should be a report with observed findings, remediation guidance and retest evidence that your team can use beside its artifact acceptance records.
