[eu-cra-compliance:supply-chain-sbom-auditor] github/gh-aw-actions CRA supply-chain and SBOM audit

クローズ
  • 何か問題がありますか？
#19,646 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
15/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
github-actions, javascript
領域
devops, security

調査の方向性

Start by confirming whether this mirror or the upstream github/gh-aw repository is the source of truth, then read SECURITY.md, setup/js/package.json, setup/action.yml, and the sync workflow. Inspect the release workflow and existing tests for SBOM and provenance entry points. Done means a sampled release maps its tag and source SHA to SPDX and CycloneDX assets and verifiable provenance, with ownership and retention procedures documented.

索引モデルが issue の本文から書いたものです。

説明

eu-cra-compliance eu-cra-compliance:supply-chain-sbom-auditor

The current branch has a machine-readable GitHub Dependency Graph SPDX SBOM (29 packages), but release evidence does not substantiate the repository policy that every release carries SPDX and CycloneDX assets. The last 20 published releases expose no assets; no tracked SBOM generator, Makefile target, dependency lockfile, signature, or attestation workflow was found. Release/component correspondence and private operational controls therefore remain unresolved.

Action: The github/gh-aw-actions release maintainer should establish a reproducible, source-of-truth SBOM and release-attestation path, then accept only when a sampled release maps its tag and source SHA to complete SPDX/CycloneDX outputs, protected build provenance, vulnerability triage ownership, and retained authority-access evidence.

  • GAP_FOUND — release SBOM: SECURITY.md says SPDX and CycloneDX files are generated for every release via make sbom; the checkout has no Makefile, generator, or SBOM workflow, and the 20 newest published releases have zero assets. Topic: machine-readable SBOM; requirement: Annex I, Part II, point (1); Regulation (EU) 2024/2847; verified 2026-10-23.
  • GAP_FOUND — release traceability: tags/releases exist, but no checked evidence binds release, source, dependency resolution, built action bundle, container, SBOM, and fixes. Topic: component documentation and technical documentation; Annex I, Part II, point (1), and Annex VII; official text; verified 2026-10-23.
  • INCOMPLETE — security operations: coordinated disclosure is documented, but alert enablement, automated security fixes, branch protection, advisory triage, remediation tracking, and registry evidence were inaccessible to the configured credential. These are not negative conclusions. Topic: vulnerability handling and due diligence; Article 13 and Annex I, Part II; official text; verified 2026-10-23.
<b>Component surface and SBOM matrix</b>
Surface / claim Evidence at audited SHA Rating
Direct JavaScript dependencies setup/js/package.json declares development/runtime-build inputs; no tracked lockfile exists because the sync workflow explicitly removes it INCOMPLETE
Transitive dependencies GitHub Dependency Graph generated SPDX 2.3 with 29 packages and 29 relationships; exact release correspondence is not shown EVIDENCE_SUFFICIENT for current-snapshot machine readability; GAP_FOUND for release mapping
Bundled/generated action code setup/action.yml runs checked-in index.js/post.js; sync copies generated runtime files from github/gh-aw while excluding tests and lockfile HUMAN_REVIEW_REQUIRED
Container/build components Dockerfile uses mutable node:lts-alpine, upgrades Alpine packages, pins npm 11.19.0, and patches selected npm internals; labels support base digest but the Dockerfile does not require a digest GAP_FOUND
Vendored, firmware, other runtimes No firmware or separate vendored manifest was identified in the bounded tracked-file inventory; absence is not independently proven NOT_ASSESSED
Release SPDX/CycloneDX Policy claims both; no generator/target/workflow or release assets were observed GAP_FOUND
Registry/container contents Workflow/configuration cannot prove registry contents; registry metadata was unavailable NOT_ASSESSED
Confidential SBOM delivery/retention No tracked access-controlled authority-supply or retention procedure was found; external records were unavailable INCOMPLETE

Requirement/topic for all rows: component identification and SBOM in a commonly used machine-readable format, expressly covering at least top-level dependencies; Annex I, Part II, point (1), Regulation (EU) 2024/2847; official text; verified 2026-10-23. Deeper hashes, licenses, suppliers, reproducibility, and full transitive coverage are implementation evidence beyond that express minimum.

source:
  instrument: "Regulation (EU) 2024/2847"
  provision: "Annex I, Part II, point (1)"
  authority: "binding"
<b>Release, vulnerability, and provenance evidence</b>
Topic Finding Rating
Release-to-source Releases and tags are present; the newest release sampled was v0.93.0, while audited main is d9128e...; no release SBOM asset establishes component correspondence GAP_FOUND
Upstream/supplier integrity Sync validates upstream refs and ancestry; action dependencies are SHA-pinned; installer checksum manifests have reviewed SHA-256 pins EVIDENCE_SUFFICIENT for these controls
Build provenance/signatures No checked release attestation/signature workflow or verification instructions were found; release assets were empty GAP_FOUND
Advisory intake SECURITY.md routes reports privately to GitHub open-source security EVIDENCE_SUFFICIENT for intake only
Identification/triage/remediation Repository automation was not found; GitHub vulnerability settings and private records returned 403 INCOMPLETE
EOL/forks/patches Container patches are documented; supplier EOL, fork ownership, unsupported dependency review, and release-level patch mapping are not evidenced GAP_FOUND
Protected release Sync restricts actors and source refs, but branch protection was inaccessible; actual protection is unverified INCOMPLETE

Topics: third-party component due diligence, vulnerability handling, and technical documentation; Article 13, Annex I, Part II, and Annex VII, Regulation (EU) 2024/2847; official text; verified 2026-10-23. No harmonised standard, certification scheme, or presumption of conformity is claimed.

<b>Regulatory timing and limitations</b>

Article 71 dates verified for this record: entry into force 10 December 2024; conformity-assessment-body provisions apply 11 June 2026; Article 14 reporting applies 11 September 2026; general application is 11 December 2027. Source: Regulation (EU) 2024/2847, Article 71, binding, official text, verified 2026-10-23. The Commission policy entry point returned 403, so the stated 27 July 2026 guidance issue date and current non-binding guidance content are INCOMPLETE, not relied upon: Commission CRA policy, checked 2026-10-23. ENISA material is supporting guidance only and was not used as a substitute for the Regulation.

<b>Prioritized remediation and agent prompt</b>
  1. P0: Align SECURITY.md with an implemented release SBOM control; generate SPDX and CycloneDX deterministically from resolved inputs and attach them to each release.
  2. P0: Bind tag, commit, built actions/container digest, SBOM digest, provenance attestation, and verification instructions; retain the evidence by supported release.
  3. P1: Document vulnerability/advisory ownership, upstream/EOL review, update automation, remediation linkage, and exception handling.
  4. P1: Define access-controlled SBOM retention and lawful authority-supply procedures without public disclosure of sensitive evidence.

Assign this issue to Copilot only after confirming whether changes belong in the mirror or upstream github/gh-aw.

<b>Agent prompt</b>

Prepare a focused patch in the confirmed source-of-truth repository that implements deterministic SPDX and CycloneDX generation from resolved dependencies, attaches both plus signed provenance to releases, verifies release-to-commit/artifact/SBOM digests, documents local verification and confidential retention/authority delivery, and updates policy text to match. Add tests that fail when a release lacks either SBOM or traceability metadata. Do not claim legal conformity.

Human-review questions
  • A non-bot product/legal reviewer must decide CRA scope, economic-operator/FOSS role, product classification, conformity route, and release eligibility; status: HUMAN_REVIEW_REQUIRED.
  • The release/security owners must identify the authoritative upstream build, registry locations, supported versions, triage records, branch rules, signing identity, retention owner, and confidential evidence location; status: HUMAN_REVIEW_REQUIRED.
Human Acceptance

A non-bot reviewer should add a thumbs-up reaction only after reviewing the complete component surface, SBOM matrix, release traceability, vulnerability-management, provenance, prioritized gaps, and human-review record. The reaction must not be added until every INCOMPLETE, NOT_ASSESSED, and HUMAN_REVIEW_REQUIRED item has an owner and disposition.

cao: githubnext/gh-cao, correlation: 39913084763-893

Generated by 🎯 EU CRA / Supply Chain · pi · gpt56 · ~62 AIC · ⌖ ~14 AIC · ⊞ 13.5K · ◷

  • expires on Nov 22, 2026, 6:54 AM UTC
主要言語
JavaScript
スター
14
フォーク
5
平均マージ
3時間 41分
マージ済み PR（30日）
714

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

githubnext/gh-cao のほかの issue

githubnext/gh-cao の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。