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

Implement the first item in this issue for github/gh-aw-mcpg. Add a required, least-privilege GitHub Actions job that runs a pinned gosec release and govulncheck against the relevant Go packages. Keep findings actionable, document narrowly justified suppressions, and avoid uploading sensitive source or findings to third parties. Add a harmless regression fixture or focused test that proves the checks fail on representative unsafe code without weakening existing tests. Update contributor documentation with local commands. Run the existing lint, unit, integration, Rust-guard, and race checks that are practical in CI. Do not change release permissions or unrelated workflows.

Acceptance check: pull requests run both tools; a known fixture is detected; the clean tree passes; suppressions are specific and documented; existing CI remains green.

• Target: github/gh-aw-mcpg
• Analyzed commit: 575559468c82f8e83740b6bcaff4bd8bfdbf86e6
• Verification date: 2026-10-22 UTC
• Current final baseline: NIST SP 800-218, SSDF Version 1.1
• Official project page checked on this run: https://csrc.nist.gov/projects/ssdf
• Final publication: https://csrc.nist.gov/pubs/sp/800/218/final
• DOI: https://doi.org/10.6028/NIST.SP.800-218
• Publication PDF: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf

The NIST project page also identifies SP 800-218A, a generative-AI and dual-use foundation-model community profile. It is not a newer revision of the general SSDF baseline, so this review remains against final SP 800-218 Version 1.1. Draft material was not scored.

Evidence was limited to the supplied target snapshot and bounded repository metadata. Organization policy, personnel, training, private operational evidence, private alert contents, incident records, deployment configuration, and control effectiveness were not assessed. An active repository ruleset surface was observable, but detailed organization-level enforcement was not used to claim conformance. No open GitHub Well-Architected issue for this target was found in the review repository, so no remediation was omitted as duplicate.

GAP_FOUND is limited to PW.7 because the applicable task and explicit contradictory configuration are both observable. Organization-only uncertainty is marked NOT_ASSESSED or HUMAN_REVIEW_REQUIRED, not scored as failure.

1. Require Go security analysis — PW.7.2, RV.1.2 (high risk reduction, high confidence, low/medium effort). Evidence: gosec and errcheck are disabled and no govulncheck invocation is present. Owner surface: maintainers with security reviewer. Dependencies: agree on severity threshold and narrow suppression policy. Acceptance: required PR job runs pinned gosec and govulncheck; a regression fixture proves detection; clean code passes; suppressions include rationale and scope.
2. Attest release binaries and container images — PS.2.1, PS.3.2, PW.6.1 (high risk reduction, high confidence, medium effort). Evidence: checksums and SBOMs exist, but no attestation-generation step is present; declared release id-token/attestations permissions are not used for an attestation. Owner surface: release engineering and security. Dependencies: choose supported GitHub artifact/container attestation and verification path. Acceptance: every tagged binary and image digest has verifiable provenance bound to the workflow, commit, and subject digest; verification commands are documented; least-privilege permissions are retained.
3. Define security-check and recurrence criteria — PO.4.1-PO.4.2, RV.3.1-RV.3.4 (medium risk reduction, medium confidence, low effort). Evidence: broad CI and coordinated disclosure exist, but security severity/suppression and root-cause triggers are not documented. Owner surface: security owner and maintainers. Dependencies: human decision on thresholds and confidential record location. Acceptance: a short policy identifies blocking levels, exception approver/expiry, root-cause trigger, recurrence search, and how resulting tests or tool changes are tracked without exposing confidential vulnerability details.

These are alternatives-compatible outcomes, not a prescribed SDLC. Recommendation 1 should precede 2 and 3 because it closes the only verified practice-level gap with the smallest implementation surface.

Strengths worth preserving:

• SHA-pinned Actions in CI and digest/checksum-pinned build inputs.
• Unit, integration, race, and Rust guard tests with read-scoped CI permissions.
• Explicit threat assumptions and layered trust boundaries in docs/aw-security.md.
• Coordinated vulnerability reporting, weekly dependency updates, and dual-format release SBOMs.
• Release checksums and multiple immutable release/container identifiers.

Human reviewers should decide:

• Which security finding severities block merge, and who can approve a time-bounded exception?
• Which trust-boundary changes require a qualified security design review?
• Are release artifacts and container images already attested by an external organization-level system not visible here?
• Where are confidential triage, remediation SLA, training, and root-cause records maintained, and how is completion evidenced without disclosing sensitive details?