A Buyer Asks for SLSA Provenance—Which Service Are They Requesting?
A buyer names SLSA provenance during onboarding without naming the artifact, platform, level, or acceptance test. Use a five-field record to route the request to the right service.
Not necessarily the provenance you would build first. When a buyer asks for SLSA provenance during onboarding, they are usually naming a compliance target rather than a deliverable, and four services could satisfy that sentence — provenance generation, build-system hardening, verification-policy implementation, and evidence review — none of them interchangeable. The request routes to the right one only after you pin down five fields: the artifact and its digest, the build platform, the target SLSA level, signer-builder or verifier, and the buyer acceptance test.
The short answer: route by what the request leaves out
Supply-chain Levels for Software Artifacts (SLSA) v1.2 — the specification published by the SLSA project and accessed 3 August 2026 at slsa.dev/spec/v1.2/ — describes incrementally stronger software-supply-chain security guarantees organized into tracks and levels. Provenance, as SLSA v1.2 defines it on the SLSA project’s provenance page (accessed 3 August 2026), is verifiable information that tracks an artifact through the supply chain to where, when, and how it was produced. An attestation is the signed statement that carries that information; SLSA recommends attestation formats including provenance.
Why this matters to a software-supply-chain security sales lead: a buyer who names SLSA has named a target standard, not a service. The same sentence can honestly precede four different statements of work. Route by what the request leaves out:
- Artifact, digest, and build platform named, but nothing attests to the build → provenance generation.
- The platform cannot honestly record inputs, commands, and outputs → build-system hardening, before any attestation can be honest.
- An attestation exists, but no verification rule maps the buyer’s acceptance test → verification-policy implementation.
- An attestation was already submitted and rejected → evidence review.
- Two or more fields unknown → send a clarifying record, then route.
The v1.2 facts that anchor the conversation
The v1.2 build-provenance schema (published by the SLSA project, accessed 3 August 2026) requires two top-level fields for SLSA Build Level 1: buildDefinition and runDetails, and runDetails in turn requires a builder. Concretely:
- buildDefinition describes what was built and how, including the external parameters the build started from.
- runDetails records how the build ran and names the builder — the identity of the system that produced the artifact.
- The schema also keeps the artifact subject (the produced artifact and its digest), invocation metadata, and verification rules as distinct parts.
The point to hold onto: producing a document with these fields does not grant a SLSA level. The fields are a formatting requirement; whether their content is trustworthy depends on the build platform and on the signer behind the builder identity. That is why the five-field record decides between services — generation fills the fields in, hardening makes the platform able to fill them honestly, verification policy decides what a verifier should check, and evidence review checks what was already produced.
Four services, five criteria
Compare the four services against the same five criteria, using one shared record per buyer.
| Service | Artifact and digest | Build platform | Target level | Signer-builder or verifier | Buyer acceptance test |
|---|---|---|---|---|---|
| Provenance generation | Needed up front as the attestation subject | Assumed able to record the build | Decides which fields the attestation carries | You sign as the builder | Produces evidence the test can accept |
| Build-system hardening | Produces a reproducible artifact and digest first | The object of the work | Decides which build guarantees the platform must add | You change what the builder runs on | Makes acceptable evidence possible |
| Verification-policy implementation | Needs an attestation with a checkable subject | Relevant only where the policy references it | Decides which verification rules apply | You configure the verifier | Defines how the test is evaluated |
| Evidence review | Re-checks the digest in an existing attestation | Read from existing records | Compared against the level the buyer claims | You review; you do not sign | Maps rejected evidence to the test |
Decision matrix
A compact routing matrix on the same fields:
| If the request… | …and | Route |
|---|---|---|
| Names an artifact, digest, and platform | no attestation exists | provenance generation |
| Names a level the platform cannot honestly record | the buyer expects real fields | build-system hardening |
| Cites an attestation | no verification rule maps to the acceptance test | verification-policy implementation |
| Reports a rejected attestation | without saying which field failed | evidence review |
| Leaves most fields open | expects a service name today | clarifying record first |
Where the buyer’s acceptance test reads like a SOC 2 evidence request — a named evidence type with no further detail — the pattern from our look at SOC 2 onboarding evidence requests applies: the request names an evidence type, not the fields needed to evaluate it.
Worked example: a composite onboarding request
Illustrative composite Telegram message — not a customer record; no real buyer, quote, or deadline:
“For onboarding we need SLSA provenance for the artifacts you ship. Our security team will validate it against our acceptance criteria before we approve the vendor. Can you confirm you provide this?”
Run the five-field check:
- Artifact and digest: not named.
- Build platform: not named.
- Target level: not named.
- Signer-builder or verifier: the buyer’s team “will validate”, which implies you would act as signer-builder — an inference, not a stated fact.
- Buyer acceptance test: named as “acceptance criteria” with no content.
Two or more fields are missing, so the correct response today is the clarifying record, not a service promise: ask for the artifact and digest, the build platform, the target level, any existing attestation, and the exact acceptance test — who verifies, with what rule, against which level.
Illustrative follow-up (still composite): if the buyer then names a container image and its digest, a hosted CI platform, target Build Level 1, and no existing attestation, the route is provenance generation. If they instead name a target level while confirming the platform cannot record build inputs, the route is hardening. The method does not resolve the ambiguity; the buyer’s answers do.
Why it matters: promising the wrong service wastes the buyer’s cycle and your credibility. If you quote provenance generation and the real blocker is that the platform cannot record the build, the deliverable fails on arrival. The five-field record also gives you a defensible reason to ask questions: you are completing the record the buyer’s own acceptance test will need, not stalling.
What remains unknown, and who must verify it: the target level and the acceptance test belong to the buyer’s security team; the platform’s ability to record builds must be verified by your engineering team rather than assumed from a product page; and the existence of any prior attestation must be checked against the artifact registry. None of these can be confirmed from the onboarding message alone.
If the buyer’s channel itself is a monitored Telegram group, the same discipline applies that we cover in our look at Telegram monitoring vendor DPA checks: the channel shows what was said; it does not certify it. Telegram’s own privacy policy (accessed 3 August 2026) states that bots are independent third-party services, that message access is optional and the interface shows which mode applies, and that third-party bot developers should ask permission before accessing data. TOP Prospect applies that boundary in practice: it processes only Telegram groups the user intentionally connects and is authorized to access, produces candidates for human review rather than fact certification, leaves the decision to a person, and does not contact group members automatically. For how channel review stays separate from artifact evidence, see the Telegram business signal intelligence pillar.
Key facts: dates, numbers, and what they do not prove
- SLSA v1.2 specification — published by the SLSA project, accessed 3 August 2026 (slsa.dev/spec/v1.2/); SHA-256 46edf6…e7e3ae. Describes incrementally stronger supply-chain security guarantees in tracks and levels.
- Provenance, v1.2 — accessed 3 August 2026 (slsa.dev/spec/v1.2/provenance); SHA-256 9a176a…0e51e44. Verifiable information tracking an artifact to where, when, and how it was produced; build provenance traces build output to source code, source provenance traces source revisions and change management.
- Build provenance, v1.2 — accessed 3 August 2026 (slsa.dev/spec/v1.2/build-provenance); SHA-256 04a97c…170f647. Build Level 1 requires buildDefinition and runDetails; runDetails requires a builder.
- Telegram privacy policy — current policy page accessed 3 August 2026 (telegram.org/privacy); SHA-256 9ae1e9…253786b. Bots are independent third-party services; message access is optional and shown in the interface; third-party bot developers should ask permission.
Measurement context: the SHA-256 values are content fingerprints for confirming that a quoted page matches the version retrieved on the access date. Versions and dates anchor the evidence; they do not measure buyer intent, and an access date is not a compliance deadline on the buyer’s side.
FAQ
Does a buyer naming SLSA mean they need provenance generation? No. Naming SLSA names a target standard, and provenance generation is only one of four routes. Route by the five-field record — artifact and digest, build platform, target level, signer-builder or verifier, acceptance test — and send a clarifying record first when most fields are missing.
Can a document alone earn a SLSA level? No. The v1.2 build-provenance schema requires buildDefinition and runDetails, with a builder, for Build Level 1, but those fields are formatting requirements. Trustworthiness depends on the build platform and the signer behind the builder identity: a document describes a level, it does not grant one.
What should I send back before promising a service? A short clarifying record listing the five fields: artifact and digest, build platform, target SLSA level, any existing attestation, and the exact acceptance test — who verifies, with what rule, against which level.
Next step worth doing this week: turn the five-field record into a one-page template with a copy-paste clarifying message, so the next onboarding request that names SLSA routes in one exchange instead of three.
Frequently asked questions
Does a buyer naming SLSA mean they need provenance generation?
No. Naming SLSA names a target standard, and provenance generation is only one of four routes. Route by the five-field record — artifact and digest, build platform, target level, signer-builder or verifier, acceptance test — and send a clarifying record first when most fields are missing.
Can a document alone earn a SLSA level?
No. The v1.2 build-provenance schema requires buildDefinition and runDetails, with a builder, for Build Level 1, but those fields are formatting requirements. Trustworthiness depends on the build platform and the signer behind the builder identity: a document describes a level, it does not grant one.
What should I send back before promising a service?
A short clarifying record listing the five fields: artifact and digest, build platform, target SLSA level, any existing attestation, and the exact acceptance test — who verifies, with what rule, against which level. Next step worth doing this week: turn the five-field record into a one-page template with a copy-paste clarifying message, so the next onboarding request that names SLSA routes in one exchange instead of three.
