[eu-cra-compliance:supply-chain-sbom-auditor] github/gh-aw-firewall CRA supply-chain and SBOM audit

`target_repo: github/gh-aw-firewall`
`target_head_sha: 42cf8f65ee3a3cc6387cd23c2ac20dcc84f458b0`

Build and release workflows show good provenance intent and shipped assets include digests and some SBOM/provenance files, but the repository does not provide a commonly used machine-readable SBOM for the overall released software surface from the checkout, and several registry- or alert-backed controls could not be verified with available access.

**Action:** Repository maintainers should publish and retain a repository/release-level SBOM covering at least top-level components across npm, Go, containers, binaries, and release artifacts, then verify that each supported release links back to source, build, and published artifact evidence. Acceptance check: a reviewer can trace the latest release from source manifests to shipped artifacts and inspect an accessible SBOM record for the released product surface.

### Component surface summary
- **EVIDENCE_SUFFICIENT:** Multiple component surfaces are visible in `target/`: root npm package, docs-site npm package, containerized Node sidecars, multiple Dockerfiles, Go guest component, compiled binaries, npm tarball, and container/image release assets.
- **GAP_FOUND:** No repository-level SBOM file was found in the checkout for the overall product or release bundle; local scan found no `sbom`, SPDX, or CycloneDX files in source.
- **HUMAN_REVIEW_REQUIRED:** Determine which released outputs are in CRA-relevant product scope for this repository (CLI, containers, guest artifacts, docs excluded or included as applicable).

### SBOM evidence matrix

| Item | Status | Evidence / limitation | Requirement / topic |
| --- | --- | --- | --- |
| Machine-readable SBOM for repository checkout | GAP_FOUND | No SBOM/SPDX/CycloneDX file found in `target/` by bounded file inventory. | Annex I, Part II(1) software bill of materials minimum |
| Machine-readable SBOM generation in release workflow | EVIDENCE_SUFFICIENT | `target/.github/workflows/release.yml` generates SPDX JSON SBOMs for several container images via `anchore/sbom-action` and attests them with cosign. | Annex I, Part II(1) evidence mechanism |
| Public release attachment of SBOMs for latest release | GAP_FOUND | Latest release `v0.28.18` includes `cloud-hypervisor-test-x86_64.sbom.spdx.json`, but no visible release assets for main container image SBOMs or a consolidated product SBOM. | Release-to-component traceability / SBOM availability |
| Dependency-graph exported SBOM | INCOMPLETE | GitHub API `repos/github/gh-aw-firewall/dependency-graph/sbom` returned HTTP 500 timeout. | Machine-readable SBOM availability |
| Top-level dependencies captured in manifests/lockfiles | EVIDENCE_SUFFICIENT | `package.json` + `package-lock.json`, docs-site `package.json` + lockfile, sidecar `package.json` + lockfiles, and `guest/microvm-supervisor/go.mod` are present. | Annex I, Part II(1) minimum component inventory support |
| Confidential/non-public SBOM handling process | NOT_ASSESSED | No decisive evidence read from checkout for authority-only SBOM supply procedure or retention location. | Authority supply / confidential evidence handling |

### Release-to-component traceability

| Claim | Status | Evidence / limitation | Requirement / topic |
| --- | --- | --- | --- |
| Latest release assets carry integrity digests | EVIDENCE_SUFFICIENT | `gh release view v0.28.18` reports SHA-256 digests for each uploaded asset; release also ships `checksums.txt`. | Annex I integrity / traceability support |
| Release workflow ties versioned source tag to built outputs | EVIDENCE_SUFFICIENT | `release.yml` derives version from tags, builds artifacts from checked-out tag, and uploads binaries, tarball, schemas, container list, and guest test assets. | Traceability from released version to source/build |
| Release includes complete mapping from all released artifacts to SBOMs | GAP_FOUND | `containers.txt` maps image names/digests, but latest visible release assets do not show per-image SBOM attachments for agent, api-proxy, cli-proxy, enclave, build-tools, or gh-aw-node. | Release-to-component traceability |
| Registry publication/signature state for containers | NOT_ASSESSED | Workflow intends GHCR push, cosign sign, and attest, but registry metadata was not queried successfully; configuration alone does not prove publication state. | Provenance/signature verification |

### Vulnerability-management integration

| Claim | Status | Evidence / limitation | Requirement / topic |
| --- | --- | --- | --- |
| Automated dependency update intake exists | EVIDENCE_SUFFICIENT | `target/.github/dependabot.yml` covers npm, docs-site npm, Docker, and GitHub Actions ecosystems on weekly cadence. | Vulnerability identification / update intake |
| Automated dependency vulnerability scanning exists | EVIDENCE_SUFFICIENT | `dependency-audit.yml` runs `npm audit`, converts output to SARIF, uploads to Security tab, and enforces no high/critical findings for main/docs packages when service is available. | Vulnerability identification and triage workflow |
| Container vulnerability and license scanning exists | EVIDENCE_SUFFICIENT | `supply-chain-scan.yml` uses Syft/Grype/Grant, with blocking PR scans for rebuilt first-party images and report-only scans for immutable published/third-party images. | Component vulnerability identification |
| Code scanning alert state | INCOMPLETE | Code scanning alerts API returned HTTP 403 `Resource not accessible by integration`. | Triage/remediation status |
| Dependabot/vulnerability alerts enablement and current queue | INCOMPLETE | Vulnerability alerts API returned HTTP 403 `Resource not accessible by integration`. | Advisory intake / remediation tracking |

### Provenance findings

| Claim | Status | Evidence / limitation | Requirement / topic |
| --- | --- | --- | --- |
| Build/release workflow requests signing and attestation permissions | EVIDENCE_SUFFICIENT | `release.yml` requests `id-token: write` and `attestations: write`. | Provenance and attestation capability |
| Container signing and SBOM attestation steps are defined | EVIDENCE_SUFFICIENT | `release.yml` runs `cosign sign` and `cosign attest` for multiple images. | Artifact provenance evidence |
| Guest artifact provenance attestation is defined | EVIDENCE_SUFFICIENT | `release.yml` uses `actions/attest-build-provenance` and bundles a Sigstore JSONL manifest for cloud-hypervisor preview test assets. | Build provenance evidence |
| Verification instructions for consumers | HUMAN_REVIEW_REQUIRED | Some artifacts imply verification inputs (`checksums.txt`, sigstore bundle), but a decisive, consolidated verification procedure was not established in bounded evidence. | Verifiability by downstream users |

### Prioritized gaps
1. **GAP_FOUND:** Publish one commonly used machine-readable SBOM for each supported release, covering at least top-level released components across source packages, containers, binaries, and bundled artifacts.
2. **GAP_FOUND:** Close the traceability gap between release assets and image/container SBOMs by attaching or clearly referencing per-image SBOM/provenance records for released containers.
3. **INCOMPLETE:** Confirm accessible evidence retention and authority-supply process for confidential SBOM/provenance material.
4. **INCOMPLETE:** Verify live security alert and registry attestation state with credentials that can read those resources.

### Human-review questions
- Which outputs are the supported released products for CRA evidence purposes: npm package, standalone binaries, containers, guest preview artifacts, or all of them?
- Are container SBOMs and attestations retained only in GHCR/Sigstore, and if so, where is the documented retrieval path for authorities and customers?
- Is there a maintained mapping from each supported release to all third-party/runtime components, including base images and bundled binaries?
- Do maintainers consider the cloud-hypervisor preview artifacts production-relevant, preview-only, or outside intended supported scope?

### What's working
The release workflow already does more than many projects by generating digests, signing multiple images, and shipping a Sigstore bundle for guest preview artifacts; that gives a solid base for a fuller CRA evidence record.

### Regulatory findings
- Annex I, Part II(1) requires manufacturers to identify vulnerabilities and components, including by drawing up an SBOM in a commonly used and machine-readable format that at minimum covers top-level dependencies.

source:
instrument: "Regulation (EU) 2024/2847"
provision: "Annex I, Part II, point (1)"
authority: "binding"
Official URL: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
Verification date: 2026-09-16
- The CRA entered into force on 10 December 2024; application dates and related guidance MUST be verified from official sources before any legal or program decision. This record could confirm the Commission guidance page references 27 July 2026 guidance, but did not extract decisive date text from the regulation page in bounded time.

source:
instrument: "Regulation (EU) 2024/2847"
provision: "entry into force and application provisions"
authority: "binding"
Official URL: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
Verification date: 2026-09-16
- Commission CRA guidance is non-binding and MAY support interpretation, but does not replace the regulation or any delegated/implementing acts.

source:
instrument: "European Commission CRA guidance page"
provision: "guidance status"
authority: "non-binding"
Official URL: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Verification date: 2026-09-16

### Human Acceptance
A non-bot reviewer should add a thumbs-up reaction only after reviewing the complete component surface, SBOM matrix, release traceability, vulnerability-management, provenance, gap, and human-review record.

### Control Plane
- Correlation ID: `35111435260-322`
- Central repository: `githubnext/gh-aw-cao`
- Control plane run URL: https://github.com/githubnext/gh-aw-cao/actions/runs/35111435260

> Generated by [:package: EU CRA / Supply Chain](https://github.com/githubnext/gh-aw-cao/actions/runs/35112072406) · pi · gpt54 · 23.6 AIC · ⊞ 10K · [◷](https://github.com/search?q=repo%3Agithubnext%2Fgh-aw-cao+is%3Aissue+%22gh-aw-workflow-call-id%3A+githubnext%2Fgh-aw-cao%2Feu-cra-compliance-supply-chain-sbom-auditor%22&type=issues)
> - [x] expires on Oct 16, 2026, 3:03 PM UTC

Start by reading .github/workflows/release.yml and the release assets for v0.28.18, then compare the component manifests and Dockerfiles mentioned in the audit. Confirm which outputs are in supported product scope before designing the SBOM and release mapping. Done means each supported release has an accessible machine-readable SBOM and traceable source, build, and artifact evidence.

Written by the indexing model from the issue text.