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

• Target: github/gh-aw-threat-detection
• Analyzed commit: 5eaa1a3507863133b1ea584e86be19ee2708e156
• Source verification date: 2026-10-22 UTC
• Baseline: NIST SP 800-218, Secure Software Development Framework (SSDF) 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
• Official SSDF table used to verify task identifiers: https://csrc.nist.gov/files/pubs/sp/800/218/final/docs/nist.sp.800-218.ssdf-table.xlsx
• Baseline decision: the official pages still identify SP 800-218 v1.1 as the current final SSDF. SP 800-218A is a final community profile for generative AI and dual-use foundation models, not a replacement revision of SP 800-218; it was not used to change this repository baseline. Draft and historical draft material was identified separately and not scored.
• Scope: checked-out repository files plus bounded GitHub metadata for repository identity, releases, and active ruleset names. No private alert details, secret-scanning results, exploit information, or confidential evidence was requested or exposed.
• NOT_ASSESSED/human-review surfaces: organization policy, personnel and role training, management commitment, developer endpoint hardening, private infrastructure, environment controls, private vulnerability intake/triage, incident exercises, and internal remediation records.
• Assumptions: checked-in workflows represent intended CI/release behavior at the assessed commit; an absent repository artifact is not evidence that an organization-level process is absent. Every conclusion requires maintainer review.

Status totals: OBSERVED 2, PARTIAL 9, GAP_FOUND 2, HUMAN_REVIEW_REQUIRED 3, NOT_ASSESSED 1. The remaining two matrix rows represented above are also bounded within these counts: 17 practice rows total (PO 5, PS 3, PW 6, RV 3).

1. Make existing Go security analysis a required CI gate — SSDF PO.3.1, PO.3.3, PO.4.1, PW.7.2, RV.1.2. Evidence: Makefile pins and runs gosec v2.23.0 and govulncheck v1.1.4; .github/workflows/ci.yml does not invoke either. Risk rationale: highest confidence and low/medium effort; closes the continuous detection gap using existing project choices. Owner surface: maintainers / CI. Dependencies: decide bounded result retention and false-positive exception ownership. Acceptance: pull requests and main run both tools with pinned versions; actionable findings fail the check; exceptions are documented and reviewed; DEVGUIDE and CI use the same command.
2. Attach component and build provenance to releases — SSDF PS.3.1, PS.3.2, PW.4.4. Evidence: checksums are generated and validated, and make sbom exists, but releases contain no SBOM/provenance step. Risk rationale: medium confidence/effort; improves acquirer verification and incident response. Owner surface: release maintainers. Dependencies: choose SPDX or CycloneDX and an attestation/signing mechanism compatible with project policy. Acceptance: each stable release includes a machine-readable SBOM tied to the tag/assets and verifiable provenance; promotion verifies identity and integrity.
3. Create a concise security-criteria and risk-decision index — SSDF PO.1.1, PO.4.1, PW.1.1, PW.1.2, PW.2.1. Evidence: strong normative product spec and one focused review exist, but repository-wide security gate criteria, review triggers, and exception expiry are not consolidated. Risk rationale: medium confidence, low effort; reduces drift without prescribing a heavyweight SDLC. Owner surface: security/design maintainers. Dependencies: identify accountable reviewer. Acceptance: checked-in guidance links requirements to checks, identifies security-sensitive review triggers, records risk acceptance with owner/expiry, and names reevaluation events.

Strengths

• Pinned third-party Action SHAs and least-privilege contents: read in CI.
• Race-tested Go tests, script tests, build/smoke checks, and extensive security-behavior tests.
• Explicit fail-closed requirements, bounded inputs/results, trust-boundary discussion, and safe-log tests.
• Coordinated vulnerability reporting that keeps reports out of public issues.
• Two-stage release/promotion process with checksum generation and revalidation.
• Active branch/tag rulesets and CODEOWNERS metadata.

Human-review questions

• Which team owns security-scan exceptions, vulnerability triage, and remediation deadlines?
• Do active rulesets require independent approval and prevent bypass for security-sensitive paths?
• What organization-level controls cover developer endpoints, build environments, role-based training, incident exercises, and management commitment?
• Which release consumers require SBOM, provenance, or artifact signing, and in which standard format?
• Which threat-model changes trigger independent design review and risk reacceptance?

Implement backlog item 1 in github/gh-aw-threat-detection at the current default branch. Read AGENTS.md if present, DEVGUIDE.md, Makefile, and .github/workflows/ci.yml. Add a least-privilege CI job that runs the project-owned gosec and govulncheck checks on pull requests and pushes to main. Keep tool versions pinned in one maintainable source, avoid @latest, preserve existing CI behavior, do not expose scanner output containing sensitive source context as a public artifact, and make actionable scanner findings fail the job. Update maintainer documentation so local and CI commands agree. Add or update workflow-contract tests if the repository has them. Run the narrowest relevant formatting, tests, workflow validation, and security checks. In the pull request, explain any accepted scanner exclusions and how maintainers review them. Acceptance: both scanners execute in CI, versions are pinned, findings fail closed, permissions remain minimal, and documentation matches the implementation.