[software-development-practices:nist-ssdf] SSDF: document release-provenance verification for all published artifacts in github/gh-aw-firewall

## Summary
The repository already demonstrates strong SSDF-aligned practices for vulnerability detection and release integrity, including CodeQL analysis, dependency auditing with SARIF upload, Dependabot updates, pinned GitHub Actions SHAs, and signed container images with SBOM attestations. However, the repository-observable release verification guidance appears narrower than the release surface it publishes.

## Why this matters (NIST SP 800-218 v1.1)
NIST SSDF v1.1 emphasizes protecting software releases and maintaining integrity of release artifacts and provenance. Repository-observable controls here already sign container images and publish attestations for some artifacts, but consumers and maintainers benefit when the official verification path is documented comprehensively for every published release artifact type. That makes it easier to verify integrity consistently and fail closed during release consumption.

## Evidence observed at commit `42cf8f65ee3a3cc6387cd23c2ac20dcc84f458b0`
- `.github/workflows/release.yml` signs multiple GHCR images with cosign keyless signing and generates SBOM attestations.
- `.github/workflows/release.yml` also uses `actions/attest-build-provenance` for guest artifacts / Cloud Hypervisor manifest provenance.
- `docs/image-verification.md` documents how to verify image signatures and SBOM attestations for published Docker images.
- `docs/releasing.md` documents a broad release surface including binaries, tarballs, checksums, containers, JSON schemas, and other release assets.

## Observed gap
The repository-observable verification documentation is clear for container images, but I did not find equally explicit maintainer/consumer guidance for verifying non-container release assets such as binaries, tarballs, checksums, JSON schema assets, and any provenance bundles produced by the release workflow. This can leave users relying on implicit trust in the GitHub release page instead of a documented verification path tied to attested provenance.

## Suggested improvement
Add a release-verification document (or extend `docs/releasing.md`) that, for each published artifact class, states:
- whether provenance/attestation is produced
- where the attestation or bundle is published
- the exact verification command(s) to run
- expected identity constraints (issuer, workflow identity, repository, tag)
- what to do if an attestation is unavailable or verification fails

A practical minimum would be:
1. Cover non-container GitHub Release assets alongside the existing container verification guidance.
2. Link from `README.md` and `docs/releasing.md` to the verification instructions.
3. Make the guidance fail-closed: if a required artifact or attestation is missing, document that consumers should not trust the release.

## SSDF mapping
- **PS.3 / integrity protection**: strengthen documented integrity checks around released artifacts.
- **PW.4 / reproducible, well-protected build outputs**: make provenance verification operational for consumers.
- **RV.1 / release verification**: improve consistent validation of release artifacts before adoption.

## Notes
This suggestion is evidence-backed but limited to repository-observable signals only. Org-level release controls, branch protection, environment approvals, and external distribution assurances were not assessed here.

> Generated by [:shield: Dev Practices / NIST SSDF](https://github.com/githubnext/gh-aw-cao/actions/runs/35109403099) · pi · gpt54 · 67.9 AIC · ⊞ 9.5K · [◷](https://github.com/search?q=repo%3Agithubnext%2Fgh-aw-cao+is%3Aissue+%22gh-aw-workflow-call-id%3A+githubnext%2Fgh-aw-cao%2Fsoftware-development-practices-nist-ssdf%22&type=issues)
> - [x] expires on Oct 16, 2026, 2:40 PM UTC

Start by reading .github/workflows/release.yml, docs/image-verification.md, docs/releasing.md, and README.md to inventory each published artifact and the verification guidance already documented for container images. Add verification instructions for non-container assets, including provenance locations, commands, identity constraints, and fail-closed behavior, then link the guidance from README.md and docs/releasing.md.

Written by the indexing model from the issue text.