moby / moby/buildkit

ECR security scanning fails on images built using BuildKit v0.11

Open
#3,499 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
10.3k
Forks
1.5k
Avg merge
1d 23h
Merged PRs (30d)
48

Description

🐛 Originally reported by @farvour in https://github.com/docker/build-push-action/pull/746#issuecomment-1377806123, tracking here since the original issue is about adding attestations fields in docker/build-push-action.

cc @crazy-max @tonistiigi

With the release of Buildkit v0.11, by default, a minimal provenance attestation is created and pushed alongside the image, using the attestation storage. This apparently causes ECR image scans to fail.

https://github.com/docker/build-push-action/pull/746#issuecomment-1377806123:

I am using this action in our workflows to build. I am discovering that ECR does not like the attestation layers pushed when security scanning is enabled on a repository. It results in a Failed on the image UI state. Not a major issue, but sounds like this new feature to this action will let me turn these off with the newer docker buildx (0.10.0+) if my understanding is correct?

While the layers for the attestation storage cannot be unpacked, the OCI image-spec explicitly declares:

This descriptor property has additional restrictions for layers[]. Implementations MUST support at least the following media types:
...
Manifests concerned with portability SHOULD use one of the above media types. An encountered mediaType that is unknown to the implementation MUST be ignored.

Ideally, scanners should either:

  • Skip over layers with unknown media types, as mentioned in the OCI spec
  • Ignore manifests with unknown platform types

I don't think there's anything we can do buildkit side? As far as I'm aware, the attestation manifests generated by buildkit are compliant with OCI artifacts.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked build-push-action report and the BuildKit v0.11 attestation-storage documentation. Reproduce an image build with the default provenance attestation, inspect its OCI manifests and layers, and test the resulting image with an ECR security scan. Done means the failure is reproduced and either a supported fix or a clearly documented BuildKit-side limitation is established.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, docker
Domain
cloud, devops, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.