provenance slsa v1 #6005

crazy-max · 2025-06-02T11:17:35Z

Adds support for SLSA provenance v1. This is currently opt-in with a new version attribute:

# buildctl
buildctl build \
    --frontend=dockerfile.v0 \
    --local context=. \
    --local dockerfile=. \
    --opt attest:provenance=version=v1

# buildx
docker buildx build --provenance version=v1 .

If version is not set it defaults to v0.2.

Examples

docker buildx build --tag crazymax/buildkit:slsa02-min --push --provenance version=v0.2,mode=min .

docker buildx build --tag crazymax/buildkit:slsa02-max --push --provenance version=v0.2,mode=max .

docker buildx build --tag crazymax/buildkit:slsa1-min --push --provenance version=v1,mode=min .

docker buildx build --tag crazymax/buildkit:slsa1-max --push --provenance version=v1,mode=max .

cc @mlieberman85 @lehors @cdupuis

crazy-max · 2025-06-02T12:59:54Z

solver/llbsolver/provenance/types/types.go

+				// TODO: handle builder components versions
+				// Version: map[string]string{
+				// 	"buildkit": version.Version,
+				// },


Didn't set the builder components versions. I can't find any real use cases in the wild atm. Maybe setting BuildKit version would be fine but as BuildKit has backward compatibility guarantee, it should not affect reproducibility.

crazy-max · 2025-06-02T13:00:24Z

solver/llbsolver/solver.go

+			// TODO: use provenance slsa v1 for build history?
+			pc, err := NewProvenanceCreator(ctx2, provenancetypes.ProvenanceSLSA02, cap, res, attrs, j, usage)


For backward compatiblity with tools using v0.2.

@tonistiigi As discussed offline we would want an opt-in to enable SLSA v1 for provenance in build history. I guess this would not be through the new version attribute but a builtin-var like BUILDKIT_HISTORY_PROVENANCE_SLSA that takes the version as value?

Added opt-in for provenance slsa v1 for build record history

crazy-max · 2025-06-03T08:48:00Z

solver/llbsolver/provenance/types/types.go

+	BuildKitMetadata BuildKitMetadata `json:"https://mobyproject.org/buildkit@v1#metadata,omitempty"`
+	Hermetic         bool             `json:"https://mobyproject.org/buildkit@v1#hermetic,omitempty"`
+	// since v1 completeness and reproducible are marked implicit from
+	// builder.id, but we still keep them for better accuracy and compatibility
+	Completeness BuildKitComplete `json:"https://mobyproject.org/buildkit@v1#completeness,omitempty"`
+	Reproducible bool             `json:"https://mobyproject.org/buildkit@v1#reproducible,omitempty"`


Don't think we care much about it but found in the spec that extension fields should have a specific format: https://slsa.dev/spec/v1.1/provenance#extension-fields

Extension fields SHOULD use names of the form <vendor>_<fieldname>, e.g. examplebuilder_isCodeReviewed. This practice avoids field name collisions by namespacing each vendor. Non-extension field names never contain an underscore.

crazy-max · 2025-06-03T10:10:09Z

Updated docs and examples with pushed images.

AkihiroSuda · 2025-06-05T23:48:13Z

docs/attestations/slsa-provenance.md

+| `filename`     | String         | `provenance.json` | Set filename for provenance attestation when exported with `local` or `tar` exporter              |
+| `reproducible` | `true`,`false` | `false`           | Explicitly marked as reproducible. See [reproducible](#reproducible)                              |
+| `inline-only`  | `true`,`false` | `false`           | Only embed provenance into exporters that support inline content. See [inline-only](#inline-only) |
+| `version`      | String         | `v0.2`            | SLSA provenance version to use (`v0.2` or `v1`)                                                   |


Any reason to still stick to v0.2 by default?

For backwards compatibility with existing tools. We need to give the tools some time to upgrade their compatibility and test, then we can switch the default.

tonistiigi

"_type": "https://in-toto.io/Statement/v0.1",
"predicateType": ["https://slsa.dev/provenance/v1"](https://slsa.dev/provenance/v1),

Spec seems to use "_type": "https://in-toto.io/Statement/v1", although I don't see constant in library.

I don't think digestMapping and llbDefinition should be in externalParameters. Afaics this is things that resembles build request from user. I think they could be in internalParameters iiuc or completely separate extension field.

Because the builder.id is more important now, I wonder if we should fill in some generic one (linking to our docs). Maybe even different ones depending on if build is complete, hermetic. I think we also need to add a way to set version, not sure if there is ever any need to builderDependencies.

Extension fields SHOULD use names of the form _, e.g. examplebuilder_isCodeReviewed. This practice avoids field name collisions by namespacing each vendor. Non-extension field names never contain an underscore.

So maybe buildkit_completeness, buildkit_layers would be enough?

byproducts

This can be follow-up but should also think how we can create links to logs etc (eg. in Github actions) here.

"environment": {
"platform": "linux/amd64"
}

I'm not sure if we need nesting in here. Just nativePlatform/systemPlatform etc. unless we think we will have more properties for environment. "environment" was field in v0.2 afaics. Similar for configSource but don't have better naming ideas there.

tonistiigi · 2025-06-09T06:47:28Z

solver/llbsolver/provenance/types/types.go

+	Materials   bool `json:"materials"`
+}
+
+func ConvertSLSA02ToSLSA1(p02 *ProvenancePredicateSLSA02) *ProvenancePredicateSLSA1 {


We can create a tracking issue to revert this and convert from 1 to 02, as eventually we want to remove 02.

tonistiigi · 2025-06-09T06:51:15Z

solver/llbsolver/provenance/types/types.go

+
+	buildDef := ProvenanceBuildDefinitionSLSA1{
+		ProvenanceBuildDefinition: slsa1.ProvenanceBuildDefinition{
+			BuildType:            p02.BuildType,


This should be actual URL iiuc. We can point it to docs file of github I think as it probably isn't very easy for us to update mobyproject.org

Updated to https://github.com/moby/buildkit/blob/master/docs/attestations/slsa-definitions.md. I looked at others buildType in the wild such as https://cloud.google.com/build/gcb-buildtypes/google-worker/v1. Maybe a dedicated page for v1 would be better.

tonistiigi · 2025-06-09T06:57:20Z

solver/llbsolver/provenance/types/types.go

+
+type ProvenanceExternalParametersSLSA1 struct {
+	ConfigSource ProvenanceConfigSourceSLSA1 `json:"configSource,omitempty"`
+	Parameters   Parameters                  `json:"parameters,omitempty"`


does this make more sense as "request"?

Yes request looks more aligned, will change that.

tonistiigi · 2025-06-09T07:14:12Z

@mlieberman85 @Forrin @pjbgf @MarkLodato @patricklawsongoogle PTAL

crazy-max · 2025-06-10T08:22:16Z

"_type": "https://in-toto.io/Statement/v0.1",
"predicateType": ["https://slsa.dev/provenance/v1"](https://slsa.dev/provenance/v1),
Spec seems to use "_type": "https://in-toto.io/Statement/v1", although I don't see constant in library.

Yes I didn't set the in-toto statement header to v1 here. Was thinking it could be a follow-up as I don't think the underlying provenance v1 predicate requires a specific in-toto version but I agree that we should consider updating to v1 (#4269). cc @cdupuis

I don't think digestMapping and llbDefinition should be in externalParameters. Afaics this is things that resembles build request from user. I think they could be in internalParameters iiuc or completely separate extension field.

Oh indeed, buildConfig should definitely be in internalParameters.

So maybe buildkit_completeness, buildkit_layers would be enough?

Yes this is what I was thinking but that's not a requirement from the spec. Happy to change it if we want to.

I'm not sure if we need nesting in here. Just nativePlatform/systemPlatform etc. unless we think we will have more properties for environment. "environment" was field in v0.2 afaics.

I kept environment on purpose so it matches completness.environment: https://github.com/moby/buildkit/pull/6005/files#diff-8a8a99742261bb2be81ed3891c4978554577af9c45acc5b642148f69489045afR190

Similar for configSource but don't have better naming ideas there.

I looked at the Google's buildType: https://cloud.google.com/build/gcb-buildtypes/google-worker/v1. They name it buildConfigSource.

byproducts

This can be follow-up but should also think how we can create links to logs etc (eg. in Github actions) here.

Yes for GHA logs it could be this kind of URI https://github.com/docker/buildx/suites/39847479240/logs?attempt=1 but need to think about how we can pass byproducts in the build request (name + uri + digest).

tonistiigi · 2025-06-11T03:53:54Z

Yes this is what I was thinking but that's not a requirement from the spec. Happy to change it if we want to.

If the old format is based on v0.2 requirements that don't exist anymore then I think we should change it. Does it mean mixing snake and camelcase though?

I kept environment on purpose so it matches completness.environment:

But that doesn't exist anymore after v0.2.

Could you push new images after updates.

crazy-max · 2025-06-11T07:46:24Z

If the old format is based on v0.2 requirements that don't exist anymore then I think we should change it.

Yes old format of field names for extension fields are URIs.

Does it mean mixing snake and camelcase though?

Yes looks like it: https://slsa.dev/spec/v1.1/provenance#extension-fields

But that doesn't exist anymore after v0.2.

True, I just wanted to keep Completeness struct as there is no equivalent in v1. I'm revisiting that to be aligned with v1.

Signed-off-by: CrazyMax <[email protected]>

moby/buildkit#6005 Signed-off-by: Brandon Mitchell <[email protected]>

github-actions bot added area/dockerfile area/testing area/dependencies Pull requests that update a dependency file area/frontend area/solver labels Jun 2, 2025

github-actions bot assigned crazy-max Jun 2, 2025

crazy-max force-pushed the slsa-v1 branch 3 times, most recently from 67c0095 to 5e1fdbf Compare June 2, 2025 11:49

github-actions bot added the area/docs label Jun 2, 2025

crazy-max commented Jun 2, 2025

View reviewed changes

crazy-max mentioned this pull request Jun 2, 2025

SLSA 1.0 Spec support #3684

Closed

crazy-max requested review from tonistiigi and jedevc June 2, 2025 13:12

crazy-max marked this pull request as ready for review June 2, 2025 13:13

crazy-max added the needs/docs-follow-up label Jun 2, 2025

thompson-shaun modified the milestones: v0.24.0, v0.23.0 Jun 2, 2025

crazy-max force-pushed the slsa-v1 branch from 5e1fdbf to f54c88d Compare June 3, 2025 08:44

crazy-max commented Jun 3, 2025

View reviewed changes

crazy-max force-pushed the slsa-v1 branch from f54c88d to 2936950 Compare June 3, 2025 09:12

crazy-max removed the needs/docs-follow-up label Jun 3, 2025

crazy-max force-pushed the slsa-v1 branch from 2936950 to 53a8696 Compare June 4, 2025 05:51

AkihiroSuda reviewed Jun 5, 2025

View reviewed changes

tonistiigi reviewed Jun 9, 2025

View reviewed changes

crazy-max force-pushed the slsa-v1 branch from 53a8696 to 2080b0e Compare June 10, 2025 08:37

provenance slsa v1

a58f93e

Signed-off-by: CrazyMax <[email protected]>

crazy-max force-pushed the slsa-v1 branch from 2080b0e to 3d2936f Compare June 11, 2025 09:14

crazy-max added 2 commits June 11, 2025 11:16

docs: provenance slsa v1

10e725d

Signed-off-by: CrazyMax <[email protected]>

history: build arg to opt-in for provenance slsa v1

d36487b

Signed-off-by: CrazyMax <[email protected]>

crazy-max force-pushed the slsa-v1 branch from 3d2936f to d36487b Compare June 11, 2025 09:16

crazy-max added needs/follow-up needs/docs-follow-up labels Jun 11, 2025

tonistiigi approved these changes Jun 11, 2025

View reviewed changes

tonistiigi merged commit 5606f26 into moby:master Jun 11, 2025
169 of 170 checks passed

crazy-max deleted the slsa-v1 branch June 11, 2025 16:04

crazy-max mentioned this pull request Jun 16, 2025

history: slsa v1 support docker/buildx#3245

Merged

sudo-bmitch added a commit to sudo-bmitch/regclient that referenced this pull request Jul 26, 2025

Chore: Update to SLSA v1 provenance

df820a6

moby/buildkit#6005 Signed-off-by: Brandon Mitchell <[email protected]>

sudo-bmitch mentioned this pull request Jul 26, 2025

Chore: Update to SLSA v1 provenance regclient/regclient#968

Merged

4 tasks

		// TODO: use provenance slsa v1 for build history?
		pc, err := NewProvenanceCreator(ctx2, provenancetypes.ProvenanceSLSA02, cap, res, attrs, j, usage)

provenance slsa v1 #6005

provenance slsa v1 #6005

Uh oh!

Conversation

crazy-max commented Jun 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Examples

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

crazy-max Jun 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

crazy-max commented Jun 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tonistiigi left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

crazy-max Jun 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tonistiigi commented Jun 9, 2025

Uh oh!

crazy-max commented Jun 10, 2025

Uh oh!

tonistiigi commented Jun 11, 2025

Uh oh!

crazy-max commented Jun 11, 2025

Uh oh!

Uh oh!

Uh oh!

crazy-max commented Jun 2, 2025 •

edited

Loading

crazy-max Jun 2, 2025 •

edited

Loading

tonistiigi left a comment •

edited

Loading

crazy-max Jun 10, 2025 •

edited

Loading