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

This advisory review found strong repository-level controls already in place for `github/gh-aw-actions`, but one high-confidence gap remains: the repository snapshot shows no Dependabot configuration or dependency-review workflow despite shipping JavaScript action code and npm dependencies. That leaves dependency update intake and pull-request dependency change review largely manual, increasing the chance that vulnerable or risky transitive updates are missed.

**Action:** The `github/gh-aw-actions` maintainers should add automated dependency update coverage and pull-request dependency review for the action runtime dependencies; accept when a checked-in `.github/dependabot.yml` covers the npm ecosystem in `setup/js/` and CI enforces dependency review on pull requests.

> **Advisory only:** This issue is non-binding and does not prove security, compliance, certification, endorsement, or SSDF conformance. It reflects a repository-observable review only; SSDF is organization-wide and risk-based, so human review is still required.

- Target repository: `github/gh-aw-actions`
- Analyzed commit: `c9a91649fa6263a455ef783f7c06a96940052fec`
- Source verification date: `2026-09-11`
- Final publication version used: `NIST SP 800-218 Version 1.1 (final)`
- Official SSDF project page: `https://csrc.nist.gov/projects/ssdf`
- Official publication landing page: `https://csrc.nist.gov/pubs/sp/800/218/final`
- Official DOI: `https://doi.org/10.6028/NIST.SP.800-218`
- Newer final revision detected: `none observed from the NIST SSDF project page fetched on 2026-09-11`

`[software-development-practices:nist-ssdf] target=github/gh-aw-actions commit=c9a91649fa6263a455ef783f7c06a96940052fec publication=NIST-SP-800-218-v1.1-final`

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

## Scope, assumptions, inaccessible evidence, and limitations

- Scope is limited to the checked-out `target/` repository snapshot and bounded GitHub-readable metadata available during this run.
- The authoritative target snapshot was `target/` at commit `c9a91649fa6263a455ef783f7c06a96940052fec`.
- The NIST SSDF project page was fetched during this run and used to confirm that SP 800-218 Version 1.1 remains the applicable final baseline. The page also references SP 800-218A as a final community profile for generative AI; it augments SSDF but does not replace SP 800-218 for this repository-level review.
- This review does not establish organization-wide implementation of training, separation of duties, incident response execution, environment hardening, private scanning results, release signing operations, or supplier management practices.
- GitHub API reads for some repository metadata were intermittently unavailable in this environment due to `HTTP 502 resource labeling failed`; where direct metadata confirmation was unavailable, conclusions rely on repository-observable files only.
- Missing private or organization-level evidence is marked `HUMAN_REVIEW_REQUIRED` or `NOT_ASSESSED`, not treated as repository failure.
- No non-final draft was used for scoring.

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

### PO — Prepare the Organization

- **PO.1 / PO.1.1–PO.1.2 — Define and document secure software development requirements**
Status: `PARTIAL`
Evidence: `README.md` explains repository purpose; `SECURITY.md` defines vulnerability reporting; `.github/workflows/ci.yml` enforces CI validation; `.github/workflows/daily-runtime-threat-scan.md` documents runtime threat scanning intent.
Evidence limitations: no repository-local secure development standard, threat model, or explicit security requirements traceability document was visible.
Improvement: add a concise repository security-development policy or link to one that states required controls for action runtime code and dependency changes. Risk reduced: drift in expected secure-development controls.

- **PO.2 / PO.2.1–PO.2.2 — Implement roles and responsibilities**
Status: `PARTIAL`
Evidence: `CODEOWNERS` names maintainers; workflow `sync-actions.yml` requires admin or maintainer role for sync operations.
Evidence limitations: repository evidence cannot prove broader secure SDLC role separation or approval responsibilities.
Improvement: document which owners approve security-sensitive runtime, workflow, and release changes. Risk reduced: unclear accountability for high-impact changes.

- **PO.3 / PO.3.1–PO.3.2 — Provide security training and awareness**
Status: `HUMAN_REVIEW_REQUIRED`
Evidence: none repository-observable.
Evidence limitations: training is usually outside repository scope.
Improvement: maintain internal secure GitHub Action development training for contributors. Risk reduced: avoidable implementation flaws.

- **PO.4 / PO.4.1 — Define and use criteria for software security checks**
Status: `PARTIAL`
Evidence: `.github/workflows/ci.yml` runs `zizmor` and validates `compat.json`; threat-scan workflow exists; version pinning is used in workflow actions.
Evidence limitations: repository does not expose a single documented quality gate describing required security checks and pass criteria.
Improvement: publish explicit required security checks for PRs and releases. Risk reduced: inconsistent control application.

- **PO.5 / PO.5.1–PO.5.3 — Implement and maintain secure development environments**
Status: `PARTIAL`
Evidence: workflows use pinned action SHAs; many checkout steps set `persist-credentials: false`; `setup.sh` validates writable temp locations and fails closed on unsafe path collapse; maintenance and runtime workflows use restricted permissions blocks.
Evidence limitations: repository-only evidence cannot confirm runner hardening, credential isolation effectiveness, or environment monitoring outside checked-in automation.
Improvement: human review the self-hosted or hosted runner baseline and document the expected hardening assumptions near the workflows. Risk reduced: environment misuse or unsafe drift.

### PS — Protect the Software

- **PS.1 / PS.1.1–PS.1.2 — Separate and protect code, data, and secrets**
Status: `OBSERVED`
Evidence: `SECURITY.md` gives private reporting guidance; workflows widely set `persist-credentials: false`; `ci.yml` uses least-privilege job permissions; setup scripts include credential-cleaning and secret-redaction helpers in `setup/sh/` and `setup/js/`.
Evidence limitations: cannot prove all secrets management outside visible workflows.
Improvement: preserve this least-privilege pattern as workflows evolve. Risk reduced: accidental credential exposure.

- **PS.2 / PS.2.1–PS.2.2 — Archive and protect each software release**
Status: `PARTIAL`
Evidence: `SECURITY.md` states SBOMs are generated on every release and attached as release assets; `sync-actions.yml` creates release tags for synced versions.
Evidence limitations: the checked-out snapshot does not include a visible release workflow that proves release integrity protections, attestation, or archival settings.
Improvement: expose release generation and verification workflow definitions in-repo, or link to the authoritative process. Risk reduced: unverifiable release handling.

- **PS.3 / PS.3.1–PS.3.2 — Maintain provenance for software components**
Status: `PARTIAL`
Evidence: workflows pin actions by full commit SHA; `SECURITY.md` documents SBOM generation in SPDX and CycloneDX formats.
Evidence limitations: no visible dependency-update automation, no visible provenance/attestation workflow, and no checked-in dependency lockfile for `setup/js/package.json`.
Improvement: add automated dependency intake/review and, when feasible, publish build provenance or attestations for releases. Risk reduced: supply-chain tampering or unreviewed dependency drift.

### PW — Produce Well-Secured Software

- **PW.1 / PW.1.1–PW.1.3 — Define security requirements for software development tasks**
Status: `PARTIAL`
Evidence: threat-scan workflow documents suspicious runtime behaviors; CI validates compatibility data and runs `zizmor`; action metadata clearly constrains intended runtime purpose.
Evidence limitations: explicit security requirement tracking or design-decision traceability was not visible.
Improvement: document required security invariants for setup/setup-cli runtime code and track exceptions. Risk reduced: regression of security expectations.

- **PW.2 / PW.2.1–PW.2.2 — Review the software design to identify and evaluate security risks**
Status: `HUMAN_REVIEW_REQUIRED`
Evidence: no repository-local architecture review or threat model was visible.
Evidence limitations: design review may happen elsewhere.
Improvement: keep a lightweight threat model for the action runtime, especially credential handling and remote download paths. Risk reduced: overlooked design-level attack paths.

- **PW.4 / PW.4.1–PW.4.4 — Reuse existing, well-secured software components**
Status: `GAP_FOUND`
Evidence: `setup/js/package.json` declares npm dependencies; repository snapshot shows no `.github/dependabot.yml`; no dependency-review workflow was present under `.github/workflows/`; no `package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml` was present in the snapshot.
Evidence limitations: external automation might exist outside the repository, but no repository-observable evidence supports that.
Improvement: add Dependabot for npm dependencies in `setup/js/` and enforce dependency-review on pull requests. Risk reduced: vulnerable or malicious dependency changes landing without consistent review.

- **PW.5 / PW.5.1–PW.5.3 — Create source code in a manner that minimizes vulnerabilities**
Status: `PARTIAL`
Evidence: `ci.yml` includes static workflow analysis via `zizmor`; scripts implement checksum verification and pinned download behavior in `setup-cli/install.sh` and `install.ps1`; setup code includes path safety checks.
Evidence limitations: no repository-observable SAST coverage beyond workflow linting; no CodeQL workflow visible.
Improvement: evaluate adding CodeQL or equivalent JavaScript/script-focused static analysis if not already run centrally. Risk reduced: latent implementation flaws.

- **PW.6 / PW.6.1–PW.6.3 — Configure tools to check code for vulnerabilities and verify remediation**
Status: `PARTIAL`
Evidence: `ci.yml` runs `zizmor`; test scripts exist in `setup/js/package.json`; threat scan workflow reviews runtime files for suspicious content.
Evidence limitations: dependency review and broader code scanning were not visible in this repository snapshot.
Improvement: expand automated security checks to include dependency review and, if appropriate, code scanning for JavaScript and shell content. Risk reduced: missed vulnerable changes.

- **PW.7 / PW.7.1–PW.7.3 — Review and/or test to identify vulnerabilities in releases**
Status: `PARTIAL`
Evidence: `ci.yml` runs validation and `zizmor`; `setup/js/package.json` includes typecheck and Vitest commands; `SECURITY.md` describes SBOM generation on release.
Evidence limitations: no visible release-gating workflow for security scans was present.
Improvement: document release security gates and keep them enforced in automation. Risk reduced: weak or inconsistent pre-release checks.

- **PW.8 / PW.8.1–PW.8.4 — Protect the release integrity and provenance**
Status: `PARTIAL`
Evidence: full-SHA pinning for workflow dependencies; checksum validation in installer scripts; tagged release flow in `sync-actions.yml`.
Evidence limitations: no explicit artifact attestation or signed release evidence was visible.
Improvement: consider release attestations or another verifiable provenance mechanism. Risk reduced: disputed or unverifiable release origin.

### RV — Respond to Vulnerabilities

- **RV.1 / RV.1.1–RV.1.3 — Identify and confirm vulnerabilities on an ongoing basis**
Status: `PARTIAL`
Evidence: `SECURITY.md` provides coordinated disclosure guidance; `daily-runtime-threat-scan.md` defines a scheduled suspicious-runtime review; `ci.yml` includes `zizmor`.
Evidence limitations: no visible Dependabot alerts workflow, code scanning workflow, or public triage SLA.
Improvement: automate dependency update and review signals to strengthen continuous vulnerability identification. Risk reduced: delayed detection of dependency risk.

- **RV.2 / RV.2.1–RV.2.3 — Assess, prioritize, and remediate vulnerabilities**
Status: `HUMAN_REVIEW_REQUIRED`
Evidence: `SECURITY.md` provides reporting channel; maintainers listed in `CODEOWNERS`.
Evidence limitations: repository cannot prove vulnerability triage process, SLA, or remediation governance.
Improvement: document maintainer triage expectations for reported vulnerabilities. Risk reduced: inconsistent remediation handling.

- **RV.3 / RV.3.1–RV.3.2 — Analyze root causes and improve processes**
Status: `HUMAN_REVIEW_REQUIRED`
Evidence: no repository-observable post-incident or lessons-learned process.
Evidence limitations: such processes are commonly private.
Improvement: maintain a lightweight retrospective practice for security incidents affecting runtime or releases. Risk reduced: repeat failures.

## Prioritized improvement backlog

1. **Add Dependabot and dependency-review coverage for `setup/js/` dependencies**
- Priority: `P1`
- SSDF provenance: `PW.4`, `PW.6`, `RV.1`, `PS.3`
- Evidence: `target/setup/js/package.json` exists; no `.github/dependabot.yml`; no dependency-review workflow found; no package manager lockfile found in the repository snapshot.
- Risk rationale: runtime actions install and execute JavaScript dependencies; without automated update intake and PR dependency analysis, vulnerable or risky packages can remain stale or change without consistent scrutiny.
- Owner surface: repository maintainers / release engineering.
- Dependencies: none; can be introduced incrementally.
- Acceptance checks: `.github/dependabot.yml` exists and targets the npm ecosystem for `setup/js/`; pull requests receive automated dependency review; maintainers can point to the enforced workflow in branch protection or required checks.

Agent prompt
Add repository-level dependency supply-chain guardrails for `github/gh-aw-actions` without changing runtime behavior.

Requirements:
1. Create `.github/dependabot.yml` that enables npm update checks for the `setup/js/` package on a reasonable cadence.
2. Add a GitHub Actions workflow that runs dependency review on pull requests affecting the repository.
3. Keep workflow permissions least-privilege and pin third-party actions by full commit SHA where appropriate.
4. If the repository intentionally avoids a lockfile, document that choice briefly in the issue or workflow comments; otherwise add the appropriate lockfile generation/update path.
5. Update any relevant docs briefly so maintainers know these checks are expected.

Acceptance:
- `.github/dependabot.yml` is present and valid.
- PRs trigger dependency review.
- Changes pass existing CI structure and keep the repo’s security posture aligned with NIST SSDF PW.4/PW.6/RV.1 intent.

## Strengths worth preserving

- Widespread least-privilege workflow permissions and frequent `persist-credentials: false` usage.
- Full-SHA pinning of GitHub Actions dependencies in checked-in workflows.
- Installer scripts verify checksums before accepting downloaded binaries.
- `SECURITY.md` gives a clear coordinated disclosure path and documents SBOM generation intent.
- The repository includes a dedicated runtime threat scan workflow focused on suspicious code that does not belong in action runtimes.

## Human-review questions

- Are dependency updates, dependency review, CodeQL, or secret scanning enforced centrally outside this repository? If yes, can maintainers link that evidence from this repo?
- Is there an authoritative release workflow or provenance/attestation process that is intentionally maintained elsewhere?
- Is the absence of a checked-in JavaScript lockfile intentional for this repository, and if so, what compensating controls govern reproducible dependency resolution?
- What branch protection and required-check settings apply on `main`, and do they currently enforce the intended security gates?

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

Start with setup/js/package.json to confirm the npm dependency location, then inspect the existing files under .github/workflows/ for CI conventions. Add the checked-in .github/dependabot.yml and a pull-request dependency-review workflow, and verify that the configuration covers setup/js/ and runs successfully in CI.

Written by the indexing model from the issue text.