GitHub ActionsでSBOMを生成する4つの方法

Q: GitHub ActionsでSBOMを生成するにはどうすればよいですか？

インストールステップの後に生成ツールのステップを追加します。最も簡単なのは anchore/sbom-action@v0 で、ワークスペースに対してSyftを実行し、SPDX JSONのSBOMをワークフローの成果物としてアップロードします。署名付きのSBOMが必要な場合は、そのファイルを actions/attest@v4 に sbom-path で渡します。

Q: SBOMのワークフローにはどの権限が必要ですか？

anchore/sbom-actionは contents: write と、SBOMをリリースに添付する場合は actions: read を求めます。 actions/attest による署名には id-token: write と attestations: write が必要で、構成証明をコンテナレジストリにプッシュする場合は packages: write も必要です。

Q: GitHub ActionsでコンテナイメージのSBOMを生成するにはどうすればよいですか？

image 入力を path の代わりに使って、イメージをanchore/sbom-actionに渡します。署名するには、 actions/attest に subject-name と subject-digest でイメージ名とダイジェストを渡し、 push-to-registry: true を設定して、 gh attestation verify oci://IMAGE で検証します。

4つの方法

2026年9月時点。
機能	方法	SBOMが記述するもの	手間
依存関係グラフのエクスポート	GitHubのグラフ	デフォルトブランチ上のリポジトリのマニフェストとロックファイル	不要
生成ツールのステップ	Syft、Trivy、cdxgen	ステップの実行時に存在するファイルまたはイメージ	ジョブごとに1ステップ
構成証明	actions/attest	渡したSBOMを署名し、成果物に紐付けたもの	生成後に1ステップ
ビルド時の記録	CRACI	ジョブが実行中に取得したもの（完全性の状態付き）	runs-onを変更

1. 依存関係グラフをエクスポートする

GitHubはリポジトリ内のマニフェストとロックファイルから依存関係グラフを作成し、SPDX SBOMとしてエクスポートできます。ワークフローの変更は不要です。リポジトリのInsightsタブを開き、Dependency graphを選んでExport SBOMをクリックします。このSBOMは特定のビルドではなくデフォルトブランチ上のリポジトリを記述するため、ワークフローがインストールするツールやパッケージは含まれません。

スクリプト化するにはREST APIを使います。GET /repos/{owner}/{repo}/dependency-graph/sbomは1回の呼び出しでSPDX JSONを返しますが、GitHubは2026年11月13日以降にこれを廃止します。後継のAPIは非同期です。レポートをリクエストし、返されたsbom_urlを取得します。このURLはSBOMの生成中は202を返し、その後SPDX JSONファイルにリダイレクトします。GitHubはこのファイルを最長1週間保持します。

# Export the dependency graph as SPDX JSON (closing down after November 13, 2026)
curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/repos/OWNER/REPO/dependency-graph/sbom

# The replacement: request a report; the response carries an sbom_url
curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/repos/OWNER/REPO/dependency-graph/sbom/generate-report

2. 生成ツールのステップを追加する

ワークフロー内のステップで、ワークスペースまたはイメージに対して生成ツールを実行します。anchore/sbom-actionはSyftを実行します。デフォルトではワークスペースのディレクトリをスキャンしてSPDX JSONを出力し、代わりにコンテナイメージをスキャンすることもできます。SBOMはワークフローの成果物としてアップロードされ、リリースにも添付されます。READMEではcontents: writeと、SBOMをリリースに添付する場合はactions: readの権限が求められています。

name: sbom
on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: write # upload the SBOM
      actions: read # attach it to a release
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      # Scan the workspace after the install step
      - uses: anchore/sbom-action@v0
        with:
          path: .
          format: cyclonedx-json

formatにはspdx、spdx-json、cyclonedx、cyclonedx-jsonを指定できます。イメージをスキャンするには、pathをimageに置き換えます（例：image: ghcr.io/OWNER/app:1.0）。BuildKit自身のイメージSBOMについてはDocker SBOMをご覧ください。

Trivyとcdxgenも同じように、通常のrunステップとして実行できます。cdxgenはCycloneDXを出力し、バージョン13以降のnpmパッケージ名は@cdxgen/cdxgenです。

    steps:
      - uses: actions/checkout@v7
      - run: npm ci
      - run: npm install -g @cdxgen/cdxgen --ignore-scripts
      - run: cdxgen -o bom.json .
      - uses: actions/upload-artifact@v7
        with:
          name: sbom
          path: bom.json

タイミングが重要です。依存関係のインストール後にステップを実行しないと、依存関係を検出できません。それでも、生成ツールが見るのは目の前にあるファイルだけです。スクリプトがダウンロードして使用し、削除したパッケージや、パッケージマネージャーを介さずにインストールされたツールは漏れることがあります。

3. 構成証明として署名する

GitHubのアーティファクト構成証明は、SBOMを記述対象の成果物に紐付け、Sigstoreで署名します。actions/attest@v4はsbom-pathを通じてSPDXまたはCycloneDXのJSON（最大16MB）を受け付けます。sbom-pathを指定しない場合は、代わりにSLSAのビルド来歴を生成します。actions/attest-sbomは非推奨となる予定で、現在はactions/attestをラップしています。ジョブには、署名証明書を取得するためのid-token: writeと、結果を保存するためのattestations: writeが必要です。

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write # sign with a Sigstore certificate
      contents: read
      attestations: write # store the attestation
    steps:
      - uses: actions/checkout@v7
      - run: make build # writes dist/my-app
      - uses: anchore/sbom-action@v0
        with:
          path: .
          format: spdx-json
          output-file: sbom.spdx.json
          upload-artifact: false
      - uses: actions/attest@v4
        with:
          subject-path: dist/my-app
          sbom-path: sbom.spdx.json

コンテナイメージの場合は、subject-nameとsubject-digestをsubject-pathの代わりに渡し、push-to-registry: trueを設定してpackages: writeを追加します。アーティファクト構成証明は、現行のすべてのGitHubプランのパブリックリポジトリで利用できます。プライベートおよび内部リポジトリにはGitHub Enterprise Cloudが必要です。

その後、GitHub CLIで誰がどの成果物のためにSBOMを生成したかを確認します。SBOMの構成証明には--predicate-typeが必要です。SBOM自体を表示するには--format jsonを追加します。イメージの場合は、ファイルパスの代わりにoci://に続けてイメージ名を指定します。

gh attestation verify dist/my-app \
  -R OWNER/REPO \
  --predicate-type https://spdx.dev/Document/v2.3

構成証明は、誰がどの成果物のためにSBOMを生成したかを証明します。SBOMをより完全にするものではありません。

4. ビルド中に記録する

CRACIはジョブの実行中にSBOMを記録します。runs-onをcraciに変更するだけです。

jobs:
  build:
    runs-on: craci # was: ubuntu-latest

するとランナー上のパッケージを認識するプロキシが、CIキャッシュから復元されたパッケージや、インストールスクリプトがダウンロードするコードなどロックファイルに記載されない隠れた依存関係も含め、ジョブが取得したすべてのパッケージを記録します。配置すべき生成ツールのステップがないため、タイミングの問題は生じません。CycloneDXまたはSPDXの各SBOMには、ジョブごと・キャッシュごとの完全性が示され、APIはSBOM、ネットワークトレース、来歴を返します。CRACI GitHub Appやネットワーク設定を含むセットアップはCRACIドキュメントに、各完全性の状態の意味はジョブとキャッシュのSBOMの完全性に記載しています。

どれを使うべきか

リポジトリの簡単なインベントリ：依存関係グラフのエクスポート。
コンテナイメージのSBOM：イメージに対する生成ツールのステップ。
誰がどの成果物のためにSBOMを生成したかの証明：いずれかの方法に加える構成証明。
脆弱性対応やCyber Resilience Actのための、ビルドが実際に使用したものの記録：ビルド時の記録。SBOMツールの比較をご覧ください。

GitHub ActionsのSBOMに関するよくあるご質問

GitHub ActionsでSBOMを生成するにはどうすればよいですか？

インストールステップの後に生成ツールのステップを追加します。最も簡単なのはanchore/sbom-action@v0で、ワークスペースに対してSyftを実行し、SPDX JSONのSBOMをワークフローの成果物としてアップロードします。署名付きのSBOMが必要な場合は、そのファイルをactions/attest@v4にsbom-pathで渡します。

GitHubはSBOMを自動で生成しますか？

GitHubは、InsightsタブまたはREST APIから、リポジトリの依存関係グラフをSPDX SBOMとしてエクスポートできます。これはリポジトリ内のマニフェストとロックファイルを記述するもので、特定のビルドではないため、ワークフローがダウンロードするツールやパッケージは表示されません。

GitHub ActionsでSBOMを生成するアクションはどれですか？

anchore/sbom-actionがSyftを実行します。デフォルトではワークスペースのディレクトリをスキャンしてSPDX JSONを出力します。代わりにコンテナイメージをスキャンすることもでき、SBOMをワークフローの成果物としてアップロードし、リリースに添付します。

SBOMのワークフローにはどの権限が必要ですか？

anchore/sbom-actionはcontents: writeと、SBOMをリリースに添付する場合はactions: readを求めます。actions/attestによる署名にはid-token: writeとattestations: writeが必要で、構成証明をコンテナレジストリにプッシュする場合はpackages: writeも必要です。

GitHub ActionsでSBOMに署名するにはどうすればよいですか？

GitHubのアーティファクト構成証明を使います。actions/attestはSPDXまたはCycloneDXのJSON SBOMにSigstoreで署名し、成果物に紐付けます。検証はgh attestation verifyで行います。actions/attest-sbomは非推奨となる予定で、現在はactions/attestをラップしています。

GitHub ActionsでコンテナイメージのSBOMを生成するにはどうすればよいですか？

image入力をpathの代わりに使って、イメージをanchore/sbom-actionに渡します。署名するには、actions/attestにsubject-nameとsubject-digestでイメージ名とダイジェストを渡し、push-to-registry: trueを設定して、gh attestation verify oci://IMAGEで検証します。

ワークフローはSPDXとCycloneDXのどちらを出力すべきですか？

SBOMを読み込むツールが想定する方です。依存関係グラフのエクスポートはSPDXのみで、cdxgenはCycloneDXを出力します。anchore/sbom-actionはどちらも出力でき、actions/attestはどちらも受け付けます。CycloneDXとSPDXの比較をご覧ください。

SBOMのステップはビルドの前と後のどちらで実行すべきですか？

依存関係のインストール後です。そうしないと依存関係を見落とします。それでも、ステップが見るのはディスク上にあるものだけで、ジョブがダウンロードして削除したものや、スクリプトが取得したものは見えません。ビルド中に記録すれば、タイミングの問題を避けられます。

GitHub ActionsでSBOMを生成する方法