Answer build pipeline questions by covering five things: who can change the pipeline, whether builds run isolated on hosted infrastructure, how secrets are kept out of build steps, whether artifacts are signed, and whether you produce provenance. Use SLSA levels as shared vocabulary, and claim only the level you can demonstrate.
What the buyer is worried about
They want to know whether an attacker, or a careless insider, could change what you ship between source and customer. The pipeline is where that happens, so the questions focus on control and evidence.
Use SLSA as a ladder, not a badge
The SLSA v1.0 Build track describes levels like this:
| Level | Meaning in plain words |
|---|---|
| L0 | No guarantees |
| L1 | Provenance exists, describing how the package was built, but it can be incomplete, unsigned or easy to forge |
| L2 | Builds run on a hosted platform that generates and signs the provenance, which protects against tampering after the build |
| L3 | The platform isolates runs and keeps signing secrets away from user-defined build steps, protecting against tampering during the build |
The SLSA site now marks v1.0 as retired in favour of a later version, so check the current spec before you quote levels in a contract. If you say "we are at L2", be ready to show a provenance file for a real release.
The five-part answer
Access. Changes to pipeline definitions go through review like code. Few people can edit runners or secrets.
Isolation. Builds run on hosted or ephemeral runners rather than long-lived machines shared with other work.
Secrets. Credentials are injected at run time with narrow scope, not stored in repositories. Forked or untrusted pull requests cannot read them.
Signing. Release artifacts are signed, and consumers have a documented way to verify them.
Provenance. Each release has a record of source revision, builder and inputs. See signature vs provenance vs SBOM attestation.
What to offer as evidence
A redacted pipeline configuration, the list of roles with pipeline admin rights, and one provenance or signature verification output for a recent release. Evidence for a real artifact beats a diagram.
Mistakes
Describing the pipeline you want rather than the one you run. Saying "signed" when only the final installer is signed and the container images are not. Treating the build level as a vendor-wide statement when it applies to one product.
Keep the description current
Pipelines drift. A runner added for a one-off task, a secret created for a test and never removed, or a new deployment job copied from an old template can each weaken what you described. Review the pipeline description when major changes land and at least twice a year, and compare it with actual settings, not with last year's answer.
Quick check
Is SLSA required by buyers?
Not generally. It is a useful vocabulary, and some buyers ask about it. Describe your controls first and map to levels second.
What if our builds are not isolated?
Say so, name the compensating controls such as restricted access and review, and give a date for the change.
Safeguard offers policies and gates for pull requests and CI, with a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
