[eu-cra-compliance:security-requirements-auditor] github/gh-aw CRA security requirements audit

github/gh-aw has good security scaffolding for a CRA-style review, but the evidence is incomplete for product risk assessment, secure-default/update behavior, and user-facing resilience controls. The repository shows documented security architecture, daily static/vulnerability scans, SBOM generation, pinned-action controls, and safe-output isolation; however, several Annex I evidence areas remain GAP_FOUND or HUMAN_REVIEW_REQUIRED because the checkout does not establish product scope, market-placement assumptions, reset/update UX, or current alert state.

**Action:** A `github/gh-aw` maintainer SHOULD review the matrix below, confirm CRA scope/classification assumptions, and either assign the remediation backlog to Copilot or record why each gap is not applicable. Acceptance check: a human reviewer can trace every open gap to an owner, decision, or linked evidence artifact.

`gh-aw-target: github/gh-aw@b1c86bd47e35ad9a575318e54dcdebcdc0a33e40`

### Verified baseline
- Verification date: 2026-09-16.
- Official baseline confirmed from the European Commission CRA page: CRA entered into force on 10 December 2024; main obligations apply from 11 December 2027; Article 14 reporting obligations apply from 11 September 2026; Commission guidance published 27 July 2026. URL: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
- The direct Eur-Lex regulation page could not be fetched from this worker because the site returned an anti-bot challenge (`202 Accepted`, WAF challenge). Binding conclusions below therefore cite the Regulation by instrument and provision but remain partially `INCOMPLETE` pending human verification against the official text at https://eur-lex.europa.eu/eli/reg/2024/2847/oj .

### Assessed product assumptions
- Product under review: `github/gh-aw`, an open-source GitHub CLI extension and workflow compiler for AI-powered GitHub Actions automation.
- Evidence suggests a software product with digital elements, but CRA scope exclusion status, economic-operator role, non-commercial FOSS treatment, substantial modification, and any important/critical classification are **HUMAN_REVIEW_REQUIRED**.
- Review mode limitation: the worker analyzed only the checked-out repository snapshot and accessible public metadata; repository security-alert state and some Actions settings were inaccessible with this token.

### Requirement matrix

| Requirement / topic | Status | Repository evidence | Missing evidence / limitation | Provenance |
| --- | --- | --- | --- | --- |
| Security-by-design tied to risk assessment | HUMAN_REVIEW_REQUIRED | `docs/src/content/docs/introduction/architecture.mdx` documents layered threat model, AWF isolation, safe outputs, network allowlists, and permission separation. | No repository-level product cybersecurity risk assessment, misuse-case register, or traceability from threats to release gates was found in decisive evidence. | source: { instrument: "Regulation (EU) 2024/2847", provision: "Annex I Part I (1), (2), (7)", authority: "binding" } · https://eur-lex.europa.eu/eli/reg/2024/2847/oj |
| Security by default / least privilege | EVIDENCE_SUFFICIENT | README and architecture docs state agent jobs are read-only and sandboxed by default; workflows commonly set `contents: read`; safe outputs separate writes from agent execution. | Sufficiency applies to repository evidence for platform defaults, not final market-placement conformity. | source: { instrument: "Regulation (EU) 2024/2847", provision: "Annex I Part I (2), (5), (8)", authority: "binding" } · https://eur-lex.europa.eu/eli/reg/2024/2847/oj |
| Known exploitable vulnerabilities absent at placement | INCOMPLETE | `security-scan.yml` runs daily `gosec` and `govulncheck`; `codeql.yml` runs daily CodeQL; `SECURITY.md` defines coordinated disclosure. | Current code-scanning alerts and vulnerability alerts were inaccessible (`403 Resource not accessible by integration`), and a checked-in `docs/security-findings-2026-01-19.md` records unresolved medium findings in archive form rather than current release evidence. | source: { instrument: "Regulation (EU) 2024/2847", provision: "Annex I Part I (1)", authority: "binding" } · https://eur-lex.europa.eu/eli/reg/2024/2847/oj |
| Unauthorized access / authentication / authorization | EVIDENCE_SUFFICIENT | Architecture doc describes explicit token distribution, MCP isolation, proxy separation, and scoped safe-output permissions; `safe_outputs_step_token_validation.go` validates same-job token-step ordering; `permissions.yml` demonstrates permission boundaries. | Demo workflows are not equivalent to production assurance, but core control intent is evidenced. | source: { instrument: "Regulation (EU) 2024/2847", provision: "Annex I Part I (3), (5)", authority: "binding" } · https://eur-lex.europa.eu/eli/reg/2024/2847/oj |
| Confidentiality and integrity of stored/transmitted data | HUMAN_REVIEW_REQUIRED | Architecture doc describes proxy-mediated egress allowlists, secret sanitization, staged outputs, and token isolation. Container pin validation in `ci.yml` and release validation in `release.md` support integrity controls. | No decisive end-to-end data-classification, encryption-at-rest policy, or integrity-control mapping for all persisted artifacts/logs was found in the checked evidence. | source: { instrument: "Regulation (EU) 2024/2847", provision: "Annex I Part I (3), (4), (6)", authority: "binding" } · https://eur-lex.europa.eu/eli/reg/2024/2847/oj |
| Data minimization | EVIDENCE_SUFFICIENT | Architecture docs describe scoped token distribution, read-only agent jobs, output filtering, and domain allowlists that constrain externalized data. | Human review still needed on whether shipped defaults and telemetry match intended deployment claims. | source: { instrument: "Regulation (EU) 2024/2847", provision: "Annex I Part I (3), (8)", authority: "binding" } · https://eur-lex.europa.eu/eli/reg/2024/2847/oj |
| Availability, resilience, restoration | GAP_FOUND | Some docs discuss failure handling and restore mechanics for caches/workflows; CI contains broad automated test coverage. | No decisive product-level resilience objectives, secure backup/restore guidance, or user-facing restoration capability evidence was found for the product as placed on the market. | source: { instrument: "Regulation (EU) 2024/2847", provision: "Annex I Part I (4), (7)", authority: "binding" } · https://eur-lex.europa.eu/eli/reg/2024/2847/oj |
| Attack-surface reduction / impact limitation / propagation control | EVIDENCE_SUFFICIENT | Architecture doc documents AWF network allowlists, sandboxing, safe outputs, staged execution, and minimal permissions; `safe_outputs_*` validation tests show deny-by-default patterns. | Evidence is implementation-oriented and should be tied to a formal release risk assessment. | source: { instrument: "Regulation (EU) 2024/2847", provision: "Annex I Part I (5), (7), (8)", authority: "binding" } · https://eur-lex.europa.eu/eli/reg/2024/2847/oj |
| Logging, monitoring, user visibility | HUMAN_REVIEW_REQUIRED | Extensive repository logging guidance exists (`pkg/logger`, `DEVGUIDE.md`, architecture docs); SARIF upload and CI monitoring are present. | The checked evidence does not show product-level security event logging requirements, operator-facing visibility commitments, retention, or user documentation for security-relevant events. | source: { instrument: "Regulation (EU) 2024/2847", provision: "Annex I Part I (2), (4) and Part II where applicable", authority: "binding" } · https://eur-lex.europa.eu/eli/reg/2024/2847/oj |
| Security updates by design | GAP_FOUND | `SECURITY.md` covers disclosure; Dependabot monitors Go, npm, pip, docker, and GitHub Actions dependencies; release workflows validate pins and generate SBOMs. | No decisive evidence of product support periods, update policy, automatic installation by default where applicable, opt-out/temporary postponement behavior, or user notification UX for security updates. | source: { instrument: "Regulation (EU) 2024/2847", provision: "Annex I Part II (1)–(4)", authority: "binding" } · https://eur-lex.europa.eu/eli/reg/2024/2847/oj |
| Security architecture, tests, scanning, release checks, remediation | EVIDENCE_SUFFICIENT | Threat model and architecture docs exist; `Makefile` includes `test-security`, fuzz seeds, `security-scan`, `govulncheck`, `gosec`; CI validates pinned container digests; release flow validates SHA-pinned containers and generates SBOMs. | Current open findings still need live review before release decisions. | source: { instrument: "Regulation (EU) 2024/2847", provision: "Annex I Part I (1), (2), (7)", authority: "binding" } · https://eur-lex.europa.eu/eli/reg/2024/2847/oj |

### Cross-cutting gaps
1. No decisive repository evidence of a CRA-oriented product cybersecurity risk assessment mapped to Annex I controls.
2. No decisive repository evidence of update-policy obligations from Annex I Part II, including automatic security updates by default where applicable, user notification, support period, or postponement controls.
3. Current vulnerability/code-scanning state is `INCOMPLETE` because GitHub alert APIs were inaccessible to this worker token.
4. Product scope and legal classification decisions are unresolved and require explicit human review before any conformity-route conclusions.

### Prioritized remediation backlog
1. **MUST** create or link a product cybersecurity risk assessment with threat scenarios, abuse cases, control owners, and release-gate traceability.
2. **MUST** document the shipped security-update model: support window, notification path, whether updates can auto-install, default state, opt-out path, and temporary postponement controls, or record why each item is not applicable.
3. **SHOULD** produce a release-ready security evidence bundle that captures current CodeQL, gosec, govulncheck, dependency, and SBOM results for the release commit.
4. **SHOULD** document resilience/restoration expectations for this product, including what users can restore, reset, or recover after configuration or runtime failure.
5. **SHOULD** map security-relevant logs and operator visibility to documented retention and access expectations.

Agent prompt
Review `docs/src/content/docs/introduction/architecture.mdx`, `SECURITY.md`, `.github/dependabot.yml`, `.github/workflows/codeql.yml`, `.github/workflows/security-scan.yml`, `.github/workflows/ci.yml`, `.github/workflows/release.md`, and `Makefile`. Create a CRA evidence bundle for `github/gh-aw` that adds: (1) a product cybersecurity risk assessment mapped to Annex I controls, (2) a security-update policy covering support period, default update behavior, user notification, opt-out, and temporary postponement, (3) a resilience/restoration note explaining reset or recovery behavior, and (4) a release checklist artifact that records current SBOM, CodeQL, gosec, and govulncheck evidence for a specific release commit. Keep legal classification decisions out of code/docs changes and instead add a short human-review checklist for scope/classification questions.

### Inaccessible or missing evidence
- Eur-Lex regulation text fetch blocked by anti-bot challenge from this worker environment; human verification against the official text is still required.
- GitHub Actions permissions API returned `403 Resource not accessible by integration`.
- GitHub code-scanning alerts API returned `403 Resource not accessible by integration`.
- No decisive artifact found for a formal product risk assessment, update-support policy, resilience objectives, or user-visible security logging commitments.

### Human-review questions
1. Is `github/gh-aw` being placed on the EU market as a product with digital elements, and if so by which economic operator?
2. Does the project rely on any CRA open-source/non-commercial treatment, and is that treatment still valid for the actual distribution model?
3. Is the product considered important Class I / Class II or critical under any current delegated or implementing act? If not, where is that decision recorded?
4. Which Annex I Part II update obligations are applicable to this CLI/workflow product, and which are not applicable with justification?
5. Before any release claim, who verifies current alert state and unresolved findings for the release SHA?

### What's working
The repository already shows a thoughtful security architecture with least-privilege defaults, safe-output isolation, recurring static/vulnerability scans, and SBOM generation — a strong base for building a defensible CRA evidence pack.

### Human Acceptance
A non-bot reviewer SHOULD add a 👍 reaction only after reviewing the complete requirement-to-evidence matrix, regulatory provenance, cross-cutting gaps, remediation backlog, and human-review questions.

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

> Generated by [:shield: EU CRA / Security](https://github.com/githubnext/gh-aw-cao/actions/runs/35111986631) · pi · gpt54 · 61.4 AIC · ⊞ 9.9K · [◷](https://github.com/search?q=repo%3Agithubnext%2Fgh-aw-cao+is%3Aissue+%22gh-aw-workflow-call-id%3A+githubnext%2Fgh-aw-cao%2Feu-cra-compliance-security-requirements-auditor%22&type=issues)
> - [x] expires on Oct 16, 2026, 3:04 PM UTC

Start by reading docs/src/content/docs/introduction/architecture.mdx, SECURITY.md, .github/dependabot.yml, the listed security and release workflows, and Makefile. Run the security-related Makefile targets and review the existing evidence matrix. Done means a CRA evidence bundle covers risk assessment, update policy, resilience/restoration, release security results, and unresolved human-review questions.

Written by the indexing model from the issue text.