[software-development-practices:nist-ssdf] TARGET_REPO repository guidance

gh-aw-threat-detection already shows strong repository-level SSDF signals: pinned GitHub Actions in several workflows, documented security reporting, routine tests, license checks, release verification, and maintainer-owned security scanning targets. The most material repository-observable gap is the absence of automated dependency update intake, which leaves Go modules and action pins more likely to age until a human notices drift.

**Action:** Maintainers should add repository-managed dependency update automation for Go modules and GitHub Actions, then verify that Dependabot (or an equivalent native updater) opens update PRs for both ecosystems on a scheduled cadence.

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

- Target repository: `github/gh-aw-threat-detection`
- Analyzed commit: `df194f7a1398a8e913b588dddea11ee1d7718d86`
- Source verification date: `2026-09-16`
- Final publication assessed: `NIST SP 800-218 Version 1.1 (final)`
- Official project URL: `https://csrc.nist.gov/projects/ssdf`
- Official publication URL: `https://csrc.nist.gov/pubs/sp/800/218/final`
- DOI: `https://doi.org/10.6028/NIST.SP.800-218`

`[ssdf-assessment] target=github/gh-aw-threat-detection commit=df194f7a1398a8e913b588dddea11ee1d7718d86 publication=NIST-SP-800-218-v1.1-final verified=2026-09-16`

### Scope, assumptions, inaccessible evidence, and limitations

- Scope is limited to the checked-out `target/` repository snapshot plus bounded GitHub-readable metadata available in this run.
- NIST's SSDF project page and final publication page were fetched during this run and indicate that **SP 800-218 Version 1.1** remains the current final SSDF baseline. The project page also references **SP 800-218A** as a final **community profile** for generative AI and dual-use foundation models; it augments SP 800-218 and is **not** the baseline replacement for this review.
- Drafts were not used for scoring.
- Repository-only evidence cannot confirm organization-wide practices such as training, role separation in practice, enterprise asset inventory, production secret handling, incident operations, or out-of-band vulnerability response execution.
- Some GitHub API reads returned transient `502 resource labeling failed` errors during this run, so open-issue deduplication and some repository metadata queries were partially limited. Findings below rely on local repository evidence where possible.
- No private alerts, secret-scanning results, code-scanning alerts, branch-protection settings, environment protection rules, or unpublished operational records were assessed.

### PO / PS / PW / RV practice-to-evidence matrix

#### PO — Prepare the Organization

- **PO.1.1 / PO.1.2** — Define and use secure software development requirements
- Status: `PARTIAL`
- Evidence: `README.md` states the component analyzes prompt injection, secret leakage, and malicious patch risk before safe outputs proceed; `specs/threat-detection-spec.md` is a detailed normative specification; `DEVGUIDE.md` points maintainers to the spec as canonical behavior.
- Limitations: Repository evidence shows documented product and engineering expectations, but not whether broader organizational requirements are defined, approved, and enforced across the SDLC.
- Improvement: Keep repository security requirements traceable from spec to implementation and tests; this reduces ambiguity-driven security regressions.

- **PO.2.1 / PO.2.2** — Implement supporting toolchains and protect development environments
- Status: `PARTIAL`
- Evidence: `Makefile` includes `security-scan`, `license-check`, `sbom`, and maintainer validation targets; `.devcontainer/` is present; CI builds and tests on GitHub Actions; release workflows build reproducible binaries for a defined matrix in `release-targets.txt`.
- Limitations: Repository evidence cannot prove workstation hardening, access control, artifact retention policy, or enterprise tool governance.
- Improvement: Add automated dependency update intake so the toolchain itself receives timely updates; this reduces exposure to known vulnerabilities and stale action or module versions.

- **PO.3.1 / PO.3.2** — Define roles and review responsibilities
- Status: `PARTIAL`
- Evidence: `CODEOWNERS` names maintainers; `SECURITY.md`, `CONTRIBUTING.md`, and `DEVGUIDE.md` define maintainer and reporter surfaces.
- Limitations: Repository evidence cannot establish reviewer independence, training completion, or actual approval enforcement.
- Improvement: Preserve CODEOWNERS-backed ownership and pair it with protected-review settings outside the repo; this reduces unreviewed security-sensitive change risk.

#### PS — Protect the Software

- **PS.1.1** — Protect all forms of code from unauthorized access and tampering
- Status: `PARTIAL`
- Evidence: Workflows often pin third-party actions by commit SHA (for example `.github/workflows/gh-aw-version-check.yml`, `.github/workflows/license-check.yml`); release promotion re-verifies binary SHA-256 values before marking a release latest in `.github/workflows/promote-release.yml`.
- Limitations: Repository evidence does not show branch protection, signed commits, artifact attestations, or storage protections.
- Improvement: Extend tamper-resistance by generating and publishing signed provenance/attestations for release binaries; this reduces downstream supply-chain ambiguity.

- **PS.2.1** — Protect secrets used in software development
- Status: `PARTIAL`
- Evidence: `SECURITY.md` routes vulnerabilities to coordinated disclosure; `README.md` and `specs/threat-detection-spec.md` repeatedly emphasize masking secrets in detection reasons and avoiding publication of sensitive outputs; `.gitignore` excludes `.env` files.
- Limitations: Repository evidence cannot confirm secrets inventory, rotation, secret-scanning enablement, or environment policy enforcement. `aoai-endpoint-smoke-test.yml` consumes a repository secret but that alone does not prove lifecycle management.
- Improvement: Continue minimizing secret exposure in logs and artifacts and validate secret-scanning/rotation controls outside the repo; this reduces credential disclosure risk.

#### PW — Produce Well-Secured Software

- **PW.1.1 / PW.1.2** — Follow secure design and threat-informed implementation practices
- Status: `OBSERVED`
- Evidence: `README.md` and `specs/threat-detection-spec.md` document explicit security boundaries, fail-closed behavior, log neutralization, artifact eligibility rules, and threat categories; `pkg/logsafe/logsafe.go` exists specifically to neutralize GitHub Actions command injection in logs; `cmd/threat-detect/pathcheck.go` prevents output-path aliasing.
- Limitations: Repository evidence cannot show every design review performed, but the security intent is explicit and implemented.
- Improvement: Preserve the current spec-driven secure design review pattern; this reduces regressions in a security-sensitive control component.

- **PW.4.1 / PW.4.2 / PW.4.3** — Review code, test security-relevant behavior, and use automated analysis
- Status: `OBSERVED`
- Evidence: `.github/workflows/ci.yml` runs `go vet`, `go test -race`, build, and smoke steps; `Makefile` adds `gosec`, `govulncheck`, shell-script tests, and SBOM generation; repository contains focused tests under `cmd/threat-detect/`, `pkg/detector/`, `pkg/artifacts/`, and `pkg/engine/`.
- Limitations: The CI workflow currently does not show all local maintainer scans running on every PR.
- Improvement: Consider moving selected maintainer security scans into CI where cost is proportionate; this reduces reliance on local discipline.

- **PW.6.1 / PW.6.2 / PW.6.3** — Manage vulnerabilities in third-party components and generated artifacts
- Status: `PARTIAL`
- Evidence: `license-check.yml` checks dependency licenses; `Makefile` supports `govulncheck` and SBOM generation; `release.yml` and `promote-release.yml` verify release artifacts by recorded checksums.
- Limitations: No repository-managed dependency update configuration was found under `.github/dependabot.yml`, and no equivalent updater configuration was evident in the checked-in workflows.
- Improvement: **Add automated dependency update intake for Go modules and GitHub Actions** so vulnerable or outdated dependencies are surfaced continuously instead of waiting for manual review; this reduces time-to-remediation for upstream flaws.

#### RV — Respond to Vulnerabilities

- **RV.1.1 / RV.1.2 / RV.1.3** — Identify, report, triage, and address vulnerabilities
- Status: `PARTIAL`
- Evidence: `SECURITY.md` provides a coordinated disclosure path; the project mission is itself vulnerability/threat detection; `gh-aw-version-check.yml` opens or updates tracking issues automatically for workflow drift.
- Limitations: Repository evidence cannot confirm SLA-backed triage, severity assignment, fix validation, or post-incident learning loops.
- Improvement: Preserve a private intake and explicit remediation tracking process; this reduces delayed response risk when vulnerabilities are reported.

### Prioritized improvement backlog

1. **Add automated dependency update intake for Go modules and GitHub Actions**
- Priority: `P1`
- SSDF linkage: `PO.2`, `PW.6`, `RV.1`
- Status: `UNTRACKED_RECOMMENDATION`
- Evidence:
- No `.github/dependabot.yml` was present in the repository snapshot.
- Checked-in workflows consume GitHub Actions dependencies (`.github/workflows/*.yml`) and the repo depends on Go modules (`go.mod`).
- The repository already has compensating controls (`license-check.yml`, `Makefile` targets for `govulncheck`, `gosec`, SBOM generation), which shows dependency risk matters here.
- Risk rationale: This repository ships a security-sensitive binary and automation workflows. Without scheduled dependency update intake, vulnerable or deprecated modules and action versions can persist until maintainers manually notice them.
- Owner surface: Repository maintainers in `CODEOWNERS`.
- Dependencies: None beyond selecting the update mechanism and cadence.
- Proportionate implementation options:
- Add `.github/dependabot.yml` covering `gomod` and `github-actions`; or
- Adopt an equivalent repository-native updater with the same evidence trail.
- Acceptance checks:
- A checked-in updater configuration exists for both Go modules and GitHub Actions.
- The schedule and reviewer/labeling behavior are documented.
- The updater opens PRs against the default branch on schedule.
- Maintainers can point to at least one successful update PR for each ecosystem.

### Strengths worth preserving

- Strong security framing in `README.md` and the detailed normative `specs/threat-detection-spec.md`.
- Release promotion verifies published binary checksums before marking a release as Latest.
- Several workflows pin actions by immutable commit SHA instead of mutable tags.
- Maintainer workflow includes `gosec`, `govulncheck`, shell tests, and SBOM generation.
- Coordinated disclosure guidance is present in `SECURITY.md`.

### Human-review questions

- Are branch protections, required reviews, and environment approvals enforcing the maintainer responsibilities implied by `CODEOWNERS`?
- Are `gosec`, `govulncheck`, and SBOM outputs run in CI at the desired cadence, or only by maintainers locally?
- Is secret scanning, dependency review, and code scanning enabled at the repository or organization level?
- Should release binaries also carry signed provenance or attestations to strengthen downstream trust beyond checksums?

### Control Plane

- Correlation ID: `35079768722-316`
- Central repository: `githubnext/gh-aw-cao`
- Control plane run URL: `https://github.com/githubnext/gh-aw-cao/actions/runs/35079768722`

> Generated by [:shield: Dev Practices / NIST SSDF](https://github.com/githubnext/gh-aw-cao/actions/runs/35080420099) · pi · gpt54 · 32.5 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, 9:42 AM UTC

Start by reviewing go.mod and the dependency references in .github/workflows/*.yml, then confirm that .github/dependabot.yml is absent. Add repository-managed update configuration covering Go modules and GitHub Actions, with the intended schedule and reviewer or labeling behavior. Done means the configuration is checked in and the updater opens a successful update PR for each ecosystem.

Written by the indexing model from the issue text.