SLSA Build L1 means your build generates provenance that identifies the output package by its cryptographic digest. Completeness is best effort and there is no authenticity requirement. It gives you a consistent record for inventory, debugging and later comparison, but it does not protect against someone forging the record.
L1 is often dismissed as trivial. It is modest, but it is a real starting line, and many teams have not crossed it.
What the requirement says
The v1.1 requirements page, now marked retired in favor of v1.2, states that the build process must generate provenance that unambiguously identifies the output package by cryptographic digest. It says the provenance may be incomplete as long as it is a best effort, and it sets no requirement for authenticity or accuracy at this level.
Producers also have jobs at every level. They select a platform capable of reaching their target level, build consistently so verifiers can form expectations, and distribute provenance to consumers or delegate that to the package ecosystem.
What you gain
A digest to name each release. You can answer "which build produced this file?" by matching the digest.
A habit of recording builds. Deciding what to include in provenance forces the team to describe its builder, its source and its parameters.
A baseline for comparison. When you later move to a hosted, signed setup, you can compare new records with old ones and spot unexplained changes.
Material for questionnaires. You can say provenance exists, at L1, and describe what it covers, without overstating.
What you do not gain
| Claim | Does L1 support it? |
|---|---|
| This record is authentic | No, no authenticity bar |
| This build ran on a hosted platform | No, that is L2 |
| Tenants cannot forge the record | No, that is L3 |
| The record lists every input | No, best effort |
| The software is free of vulnerabilities | Never a provenance claim |
Be careful with wording. "We produce SLSA provenance" is fine. Avoid "SLSA certified". Say which Build level you meet, under which version of the spec, and how you assessed it.
A one week plan to reach L1
- Day one: pick your release artifacts and list them.
- Day two: choose the fields to record. Start with the artifact digest, source repository and commit, builder name, and the parameters used.
- Day three: generate the record in the release pipeline, in a format other tools can read.
- Day four: store the record next to each artifact and name it by digest.
- Day five: write a short note describing how a consumer can find and read it.
Use the standard provenance format where you can, rather than inventing your own, so tooling can read it later.
Moving up
From L1, the next steps are a hosted platform for L2, and unforgeable provenance with isolated, ephemeral builds for L3. Each step makes the record harder to fake. Do not wait until everything is perfect to start recording. Records you have are better than records you wish you had when an incident happens.
Safeguard offers SBOM generation and dependency scanning to go with provenance, and the free scan at https://gold.safeguard.sh/scan gives a quick look at your current components.
Quick check
Is L1 provenance trustworthy?
It is useful as a record, but the spec sets no authenticity or accuracy requirement at L1.
Should a team say it is SLSA certified at L1?
Avoid the word certified. State the Build level, the spec version and how you assessed it.
Sources
Last reviewed: 19 October 2026.
