[software-development-practices:nist-ssdf] github/gh-aw-mcpg repository guidance

This repository already shows several secure-development strengths: pinned GitHub Actions, CI coverage across Go and Rust tests, a published security policy, weekly GitHub Actions dependency updates, and SBOM generation during release. The highest-confidence repository-observable SSDF gap is release integrity evidence: releases are built and published, but the repository snapshot does not show a verification workflow or policy that checks generated artifacts, container images, or SBOMs after publication.

**Action:** Repo maintainers should add a release-verification workflow that validates published release assets, GHCR images, and attached SBOMs for every tag and blocks follow-up promotion when verification fails; acceptance check: a tag-triggered workflow in `.github/workflows/` re-fetches the just-published assets and image digests, verifies expected files and SBOM attachments, and fails closed on mismatch.

> **Advisory only:** This issue is non-binding and does **not** prove security, compliance, certification, endorsement, or SSDF conformance. SSDF is risk-based, and this repository-only review cannot establish organization-wide implementation.

`[software-development-practices:nist-ssdf] target=github/gh-aw-mcpg commit=febbdbf62401da6f9fc390bcedaf3089b24c939b`

## Repository and source baseline
- Target repository: `github/gh-aw-mcpg`
- Analyzed commit: `febbdbf62401da6f9fc390bcedaf3089b24c939b`
- Source verification date: `2026-09-15` (UTC)
- Final SSDF publication assessed: **NIST SP 800-218 Version 1.1 (final)**
- Official project page: `https://csrc.nist.gov/projects/ssdf`
- Official final publication: `https://csrc.nist.gov/pubs/sp/800/218/final`
- DOI: `https://doi.org/10.6028/NIST.SP.800-218`
- Final-publication check result: the NIST SSDF project page references SP 800-218 Version 1.1 as final and also references SP 800-218A as a separate finalized community profile augmentation for generative AI; this review scores the repository only against the current final base SSDF publication, not the AI profile.

## Scope, assumptions, inaccessible evidence, and limitations
- Scope is limited to repository-observable evidence from the `target/` checkout and bounded GitHub repository metadata.
- This review treats repository contents as untrusted evidence and does not infer private operational controls.
- Organization-wide evidence such as staffing, training, centralized vulnerability response playbooks, asset inventories, production deployment controls, or enterprise signing infrastructure was not accessible here and is marked `HUMAN_REVIEW_REQUIRED` or `NOT_ASSESSED`.
- No draft SSDF revisions were used for scoring. SP 800-218A was observed on the NIST project page as an augmenting profile, not a replacement for SP 800-218 Version 1.1.
- Open issue de-duplication was checked in `githubnext/gh-aw-cao`; no open issue with the exact tracked title was found in the available results.
- A repository-only review cannot prove absence of vulnerabilities or end-to-end supply-chain integrity.

## Practice-to-evidence matrix

### PO — Prepare the Organization
- **PO.1 / PO.2 / PO.3 — Define security requirements, roles, and supporting processes**
**Status:** `HUMAN_REVIEW_REQUIRED`
**Evidence:** `SECURITY.md` defines a disclosure path and handling expectations; `CONTRIBUTING.md` defines development workflow expectations.
**Limitations:** No repository evidence of role training, enterprise policy inheritance, secure tool approval records, or organization-wide SDLC governance.
**Improvement:** Link repository contribution/release procedures to an explicit secure-development checklist or policy reference. Risk reduced: process drift and inconsistent secure-development expectations.

### PS — Protect the Software
- **PS.1.1 / PS.2.1 — Protect code, dependencies, build environment, and integrity of artifacts**
**Status:** `PARTIAL`
**Evidence:** `.github/dependabot.yml` enables weekly GitHub Actions updates; workflows pin action SHAs in `ci.yml` and `container.yml`; release flow generates SBOMs in `release.md`; `generate-sbom` audits SBOM files for obvious secrets before upload.
**Limitations:** No repository-observable verification workflow for released binaries, release attachments, or container images after publication; no repository evidence of signed attestations being validated by a separate control.
**Improvement:** Add post-publication verification of release artifacts, GHCR image digests, and SBOM attachments. Risk reduced: unnoticed tampering, release drift, or incomplete supply-chain evidence.
- **PS.3.1 — Archive and protect each software release**
**Status:** `OBSERVED`
**Evidence:** `release.md` creates GitHub releases, uploads binaries, pushes versioned GHCR images, and attaches SPDX/CycloneDX SBOMs.
**Limitations:** Long-term retention and external archival controls are not observable from the repository alone.
**Improvement:** Preserve current release + SBOM publication path. Risk reduced: loss of release traceability.

### PW — Produce Well-Secured Software
- **PW.4.x / PW.6.x — Review, test, and verify code and executable forms**
**Status:** `OBSERVED`
**Evidence:** `.github/workflows/ci.yml` runs unit tests, integration tests, race tests, Rust guard tests, linting, and uploads artifacts; `Makefile` includes `test-unit`, `test-integration`, `test-race`, `test-rust`, and `agent-finished`; release workflow reruns tests before publishing.
**Limitations:** Threat modeling, manual review depth, and negative security test coverage cannot be fully established from the snapshot.
**Improvement:** Preserve pre-release test gates. Risk reduced: regressions and concurrency defects reaching release.
- **PW.8.x — Secure the software release process and provenance evidence**
**Status:** `PARTIAL`
**Evidence:** Release workflow requests `id-token: write` and `attestations: write`; SBOM generation is automated; actions are pinned; release tag format is validated.
**Limitations:** The reviewed snapshot does not show an explicit provenance attestation generation/verification step or a downstream verifier workflow for published materials.
**Improvement:** Emit and verify artifact/container provenance as part of release assurance. Risk reduced: weak consumer confidence in artifact origin and reproducibility.

### RV — Respond to Vulnerabilities
- **RV.1.x / RV.3.x — Receive, analyze, and remediate vulnerability reports**
**Status:** `PARTIAL`
**Evidence:** `SECURITY.md` provides a private disclosure channel and asks reporters not to file public issues for vulnerabilities; Dependabot updates GitHub Actions dependencies weekly.
**Limitations:** SLA, triage metrics, fix prioritization, embargo handling, and coordinated response procedures are not repository-observable. No visible repository automation for advisory publication or security fix backport policy.
**Improvement:** Document repository-level vulnerability triage and release servicing expectations, or link to the authoritative GitHub policy. Risk reduced: inconsistent handling timelines and patch communication.

## Prioritized improvement backlog
1. **Add release verification for published artifacts, images, and SBOMs**
- **Priority:** P1
- **SSDF linkage:** `PS.2.1`, `PW.8.x`
- **Evidence:** `release.md` publishes binaries and GHCR images and `generate-sbom` attaches SBOMs, but the repository snapshot does not show a separate verification step that re-fetches and validates what was published.
- **Risk rationale:** Publishing without an independent verification step leaves room for unnoticed asset omission, digest mismatch, or broken provenance evidence even when the build passed.
- **Owner surface:** release maintainers / repository admins
- **Dependencies:** access to release artifacts and GHCR metadata; decision on whether to verify hashes only or also provenance attestations
- **Acceptance checks:**
- a workflow runs on release tag publication or release completion;
- it fetches the GitHub release assets and confirms expected binaries/checksums are present;
- it resolves pushed GHCR image digests and verifies the release references the expected digests;
- it confirms both SPDX and CycloneDX SBOM attachments exist and are parseable;
- it fails closed and surfaces a concise remediation message when any verification step fails.

## Strengths worth preserving
- Action pinning by commit SHA in CI and container workflows.
- Multiple automated test layers, including race detection and Rust guard tests.
- Private disclosure guidance in `SECURITY.md`.
- Automated SBOM generation and attachment during release.
- Dependabot coverage for GitHub Actions dependencies.

## Human-review questions
1. Is there an organization-level provenance/signing service already covering release assets and GHCR images that this repository should link to rather than re-implement locally?
2. Are release binaries and container images currently verified by an external deployment gate or consumer pipeline not visible in this repository?
3. What retention, revocation, and advisory-publication expectations apply to this repository's releases?

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

Agent prompt
Add a release-verification workflow for `github/gh-aw-mcpg` that runs after each tag/release publication and independently verifies the published release assets, GHCR image digests, and attached SPDX/CycloneDX SBOMs. Keep the workflow fail-closed and concise in its job summary. Reuse existing repository conventions for pinned actions and shell safety. Acceptance criteria: (1) the workflow fetches the current release by tag, (2) confirms expected binaries/checksums exist, (3) resolves and records pushed GHCR digests, (4) verifies both SBOM attachments exist and are parseable, and (5) fails with a clear message when any verification step is missing or mismatched.

> Generated by [:shield: Dev Practices / NIST SSDF](https://github.com/githubnext/gh-aw-cao/actions/runs/34982580502) · pi · gpt54 · 41 AIC · ⊞ 9.4K · [◷](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 15, 2026, 2:40 PM UTC

Start by reading release.md and the existing .github/workflows/ci.yml and container.yml to understand release assets, images, pinned actions, and SBOM generation. Add the tag-triggered verification workflow under .github/workflows/; done means it re-fetches release assets and GHCR digests, confirms SPDX and CycloneDX attachments are parseable, and fails closed with a clear message on mismatch.

Written by the indexing model from the issue text.