DEP-91 (3/5): attach SBOM and bundled-tool manifest to releases

• Add a release job that generates per-platform CycloneDX/SPDX SBOMs and a JSON manifest.
• Upload SBOMs/manifest as GitHub release assets, without blocking publishing on failures.
• Harden tooling/version reporting (AWS CLI pin; non-blocking Trivy report steps).

graph TD
  n1["GitHub Actions: release.yml"] --> n2["Job: sbom-and-manifest"] --> n3["generate-sbom-manifest.py"]
  n3 --> n5["buildx imagetools"] --> n4[("Docker Registry")]
  n3 --> n6["Trivy container"] --> n4
  n3 --> n7["dist/sbom artifacts"] --> n8(("GitHub Release assets"))

  subgraph Legend
    direction LR
    _wf["Workflow/Job"] ~~~ _ext[("External system")] ~~~ _out(("Published artifact"))
  end

The following are alternative approaches to this PR:

1. Use Trivy GitHub Action + built-in upload steps

• ➕ Less custom scripting/maintenance
• ➕ Standardized action inputs and caching patterns
• ➖ Harder to do digest-pinned, per-platform scans with consistent manifest semantics
• ➖ Less control over retry/skip behavior for lagging tags

2. Publish SBOMs as OCI artifacts (ORAS/Cosign attestations)

• ➕ Co-locates SBOM/attestations with images in the registry
• ➕ Better alignment with emerging supply-chain verification workflows
• ➖ More tooling and trust-policy complexity than simple GitHub release assets
• ➖ May be overkill if consumers primarily read GitHub releases

Recommendation: Current approach is a good fit for DEP-91’s goal: it’s release-artifact-only, digest-aware (so outputs match shipped bytes), and per-platform (so arm64 isn’t misrepresented). Keep the GitHub release attachments for accessibility; consider OCI-native attestations later if downstream verification workflows demand it.

Enhancement (1) +297 / -0

generate-sbom-manifest.pyGenerate per-platform SBOMs and release-manifest.json for published images +297/-0

Generate per-platform SBOMs and release-manifest.json for published images

• Adds a script that resolves multi-arch image digests (with retries), generates CycloneDX and SPDX SBOMs per platform via a digest-pinned Trivy container, and emits a compact manifest with index/child digests, base OS, component counts, and CRITICAL/HIGH vuln totals. Reads bundled-tool versions from Dockerfile.tools ARG defaults for the fat agent image and ensures outdir/cache paths are absolute for Docker bind mounts.

scripts/ci/generate-sbom-manifest.py

Bug fix (1) +1 / -1

Dockerfile.toolsDownload AWS CLI from versioned archive URL +1/-1

Download AWS CLI from versioned archive URL

• Updates the AWS CLI installer download URL to include the configured AWS_CLI_VERSION, preventing drift from the intended pinned version.

Dockerfile.tools

Other (2) +51 / -2

agent-tools-build.ymlPin AWS CLI version and make Trivy report steps truly non-blocking +5/-2

Pin AWS CLI version and make Trivy report steps truly non-blocking

• Adds an AWS_CLI_VERSION value to the tool-version outputs. Marks the report-only Trivy vuln steps continue-on-error and removes a pipefail hazard by slicing inside jq and guarding failures, preventing report JSON issues from blocking publishing.

.github/workflows/agent-tools-build.yml

release.ymlAdd non-blocking SBOM + manifest job and upload assets to release +46/-0

Add non-blocking SBOM + manifest job and upload assets to release

• Introduces a new sbom-and-manifest job gated behind publish-release (and minimal multiarch publishing) to generate SBOMs and a release-manifest.json. Logs into Docker Hub to avoid rate limits, runs the generator script, and uploads outputs to the GitHub release with clobber semantics.

.github/workflows/release.yml

Description

The new sbom-and-manifest job depends on docker-publish-hoopdev-minimal-multiarch; if that
upstream job fails, GitHub Actions can skip sbom-and-manifest, preventing SBOM/manifest upload for
all images even though the generator already tolerates missing tags.

Code

.github/workflows/release.yml[R1345-1348]

+    needs:
+      - publish-release
+      - docker-publish-hoopdev-minimal-multiarch
+    continue-on-error: true

Relevance

●●● Strong

Workflow reliability/robustness changes are typically accepted; always()-style gating is a small,
safe fix.

PR-#1031 PR-#1072 PR-#1595

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

sbom-and-manifest is configured with a hard needs dependency on the minimal multi-arch publish
job. That upstream job is marked continue-on-error: true (i.e., it may fail), and without an
explicit always()-style condition the SBOM job can be skipped when a needed job fails; this
bypasses the generator’s built-in “skip missing tags” behavior because the generator never runs.

.github/workflows/release.yml[1341-1377] .github/workflows/release.yml[979-1016]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`sbom-and-manifest` is intended to be best-effort and should run after a release is published, even if optional image-publish jobs fail. Currently it has a hard `needs` dependency on `docker-publish-hoopdev-minimal-multiarch`, so if that job fails, `sbom-and-manifest` can be skipped and no SBOM/manifest artifacts are attached.

### Issue Context
- The SBOM generator already retries registry visibility and skips missing image tags; the job being skipped prevents that logic from running at all.
- `publish-release` should remain the real gate (only run SBOM job when the release actually shipped).

### Fix Focus Areas
- .github/workflows/release.yml[1345-1348]

### Suggested fix
Adjust the job condition so it always runs when `publish-release` succeeded, regardless of the minimal-image job result.

Example:
```yaml
sbom-and-manifest:
 needs:
   - publish-release
   - docker-publish-hoopdev-minimal-multiarch
 if: ${{ always() && needs.publish-release.result == 'success' }}
```

Alternative: remove the minimal-image job from `needs` and rely on the generator's retry/skip behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The PR adds a non-trivial SBOM/manifest generator with parsing and retry logic but does not
add/modify any unit tests covering common and edge cases. This increases the risk of silent
release-artifact failures (e.g., registry lag, non-index manifests, missing ARGs) going undetected.

Code

scripts/ci/generate-sbom-manifest.py[R172-175]

+def bundled_tools() -> dict:
+    """Read bundled-CLI versions from Dockerfile.tools' ARG defaults.
+
+    Best-effort: an ARG that is renamed or removed is simply omitted (the SBOMs

Relevance

●● Moderate

They sometimes push back on adding broader tests; no close precedent for requiring unit tests for
new CI scripts.

PR-#1515

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1807237 requires unit tests for new/changed helpers/parsers. The PR introduces new
parsing helpers (e.g., Dockerfile ARG parsing in bundled_tools()), but the diff includes no added
or updated test files for this logic.

Rule 1807237: For new or changed helpers/parsers, add unit tests covering common and edge formats scripts/ci/generate-sbom-manifest.py[172-188]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new helper/parsing script (`scripts/ci/generate-sbom-manifest.py`) was added without accompanying unit tests, despite containing parsing/normalization and retry/branching logic.

## Issue Context
This script impacts release artifact generation (SBOMs + `release-manifest.json`). Unit tests should cover at least: multi-arch index vs single-manifest behavior, registry visibility retry/skip logic, Dockerfile ARG parsing, and Trivy JSON summarization.

## Fix Focus Areas
- scripts/ci/generate-sbom-manifest.py[75-115]
- scripts/ci/generate-sbom-manifest.py[117-131]
- scripts/ci/generate-sbom-manifest.py[147-165]
- scripts/ci/generate-sbom-manifest.py[172-188]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

💡 Did you know, you can enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗