[Bug]: Operator images not using OCI format for attestation #10600

Activity

1. sxd

   added this to the Now milestone on May 3, 2026
2. sxd

   self-assigned this

   on May 3, 2026
3. sxd

   added this to Security Mapand CloudNativePG operator developmenton May 3, 2026
4. sxd

   added

   bug 🐛Something isn't workingSomething isn't working

   on May 3, 2026
5. sxd

   added the

   Defect

   issue type on May 3, 2026
6. github-project-automation

   moved this to Todo in Security Mapon May 3, 2026
7. dosubot commented on May 3, 2026

   

   dosubotBot

   on May 3, 2026 – with DosuBot

   More actions

   This looks like a valid finding. Looking at the current docker-bake.hcl, the output and attestation configuration is:

   output = [
     "type=image,registry.insecure=${insecure}",
   ]
   
   attest = [
     "type=provenance,mode=max",
     "type=sbom"
   ]

   The output uses type=image without explicitly enabling OCI media types. Per the Docker documentation on OCI media types, when attestations are stored without oci-mediatypes=true, they use Docker-specific media types instead of standard OCI artifactType descriptors — which is what makes them invisible to tools like GUAC that look for the OCI referrers API / artifactType field.

   The fix would likely involve adding oci-mediatypes=true to the output configuration:

   output = [
     "type=image,registry.insecure=${insecure},oci-mediatypes=true",
   ]

   This should cause BuildKit to produce attestation manifests with the proper OCI artifactType set, making them discoverable by OCI-native tooling.

   To reply, just mention @dosu.

   ---

   Share context across your team and agents. Try Dosu.

   
8. gbartolini

   added a commit that references this issue on May 5, 2026

   chore: setup OCI types to true in docker-backe.hcl

   ...

   This issue will close once commit 984f4f2 is merged into the 'main' branch.

   984f4f2
9. mnencia

   added a commit that references this issue on May 5, 2026

   chore: enable OCI artifact type for attestation manifests (#10601)

   ...

   770e95c
10. cnpg-bot

    added 3 commits that reference this issue on May 5, 2026

    chore: enable OCI artifact type for attestation manifests (#10601)

    ...

    93f798b

    chore: enable OCI artifact type for attestation manifests (#10601)

    ...

    5752abd

    chore: enable OCI artifact type for attestation manifests (#10601)

    ...

    fdd8315
11. mnencia commented on May 5, 2026

    

    mnencia

    on May 5, 2026

    Member

    More actions

    Fixed by #10601.

    BuildKit's default image exporter does not set artifactType or an OCI 1.1 Referrers subject on attestation manifests. The PR adds oci-artifact=true, so SBOM and provenance attestations now carry both and are discoverable through the Referrers API.

    GUAC was the example mentioned here, but it has a separate limitation tracked upstream at guacsec/guac#1370: its OCI collector filters Referrers descriptors by an allowlist that does not include the BuildKit attestation manifest type, so it drops them regardless of how the manifest is shaped. That is for the GUAC project to fix; nothing on the cnpg side will help.
12. mnencia

    closed this as completedon May 5, 2026
13. github-project-automation

    moved this to Done in CloudNativePG operator developmenton May 5, 2026
14. github-project-automation

    moved this from Todo to Done in Security Mapon May 5, 2026
15. gbartolini commented on May 5, 2026

    

    gbartolini

    on May 5, 2026

    Contributor

    More actions

    Yes, in general it would be appreciated to have clearer issue descriptions, with ways to detect the current problem and how to determine the success of the PR. This fosters collaboration, facilitates buy-in, and reduces the effort in review and approval.