Added sbom

[bluvulture]

This pull request enhances the release workflow by generating, extracting, and attaching SBOMs (Software Bill of Materials) for Docker images. The changes improve supply chain transparency and automate SBOM handling throughout the build and release process.

SBOM Generation and Extraction:

• The Docker build step now enables SBOM generation by passing the --sbom=true flag, ensuring SBOMs are included in the image build output.
• After pushing an image, the workflow extracts the CycloneDX SBOM from the image attestation and saves it as a JSON file in the sboms/ directory.

SBOM Artifact Management:

• The workflow uploads the generated SBOM files as build artifacts, making them available for later workflow steps.

[Copilot]

Pull request overview

Adds SBOM generation to the Docker release workflow: enables --sbom=true during docker build, extracts the CycloneDX SBOM from the pushed image via docker buildx imagetools inspect, and uploads the resulting JSON files as a build artifact per matrix entry.

Changes:

• Enable SBOM attestations in the docker build step.
• Extract the CycloneDX SBOM from the pushed image into sboms/sbom-<TAG>.cdx.json.
• Add an actions/upload-artifact@v7 step to publish the sboms/ directory.

Comments suppressed due to low confidence (2)

.github/workflows/release.yml:140

• docker buildx imagetools inspect ${IMAGE_NAME}:${TAG} inspects the multi-arch manifest list at the registry. At this point in the loop, only the current architecture (linux/${ARCH_TAG}) has been pushed to that tag — the other architecture is pushed by a separate matrix job. Depending on timing/ordering between the two arch runners, the .SBOM.CycloneDX field for ${TAG} (which already contains -${ARCH_TAG}) should be a single-platform SBOM, but the --format '{{ json .SBOM.CycloneDX }}' output for a single-platform image is keyed by platform (e.g. {"linux/amd64": {...}}), not a bare CycloneDX document. The resulting sbom-*.cdx.json will therefore not be a valid CycloneDX file consumable by standard tooling. Consider using --format '{{ json (index .SBOM "linux/<arch>").SPDX }}'-style indexing, or docker buildx imagetools inspect --raw plus extraction, to produce a real CycloneDX document.

                            docker buildx imagetools inspect "${IMAGE_NAME}:${TAG}" \
                                --format '{{ json .SBOM.CycloneDX }}' > "sboms/sbom-${TAG}.cdx.json" || \
                                echo "Warning: Could not extract SBOM for ${TAG}"

.github/workflows/release.yml:171

• The "Upload SBOMs" step has no if: condition, unlike the immediately preceding "Upload aggregated tags" step (line 160) which is gated on github.event_name != 'workflow_dispatch' || inputs.publish. When a user triggers the workflow via workflow_dispatch with publish: false, PUSH will be false, the SBOM extraction block at line 136 is skipped, and sboms/ will not exist — if-no-files-found: ignore will avoid a hard failure, but the step still runs unnecessarily and clutters the run with an empty/skipped artifact. For consistency with the adjacent upload step, consider adding the same if: guard.

            -   name: Upload SBOMs
                uses: actions/upload-artifact@v7
                with:
                    name: sboms_${{ matrix.runner }}_${{ matrix.build.tag }}_${{ matrix.build.php }}_${{ matrix.build.distro }}_${{ matrix.build.version-override }}_${{ matrix.build.latest-tag }}
                    path: sboms/
                    if-no-files-found: ignore

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.