トップ > セキュリティ > GitHub で実現する Dependabot × SBOM による依存関係の脆弱性管理を考えて試してみた

GitHub で実現する Dependabot × SBOM による依存関係の脆弱性管理を考えて試してみた

セキュリティ Dependabot SBOM GitHub GitHub Actions
記事タイトルとURLをコピーする

こんにちは、近藤（りょう）です！

ソフトウェア開発では、多くの OSS ライブラリやパッケージが利用されています。そのため、依存関係の脆弱性管理やソフトウェア構成を把握することが重要になります。

GitHub では、依存関係の脆弱性を検知する Dependabot とソフトウェア構成を一覧化する SBOM（Software Bill of Materials）を生成する仕組みを利用できます。

本記事では、Dependabot と SBOM を組み合わせて、GitHub 上で依存関係管理とソフトウェア構成の可視化を行う方法を紹介します。

なお、米国の標準化機関である NIST でも、ソフトウェアサプライチェーン対策として SBOM の活用が推奨されています。

www.nist.gov

Dependabot について

Dependabot は、プロジェクトで利用している依存パッケージを自動で検出し、 各ライブラリの更新状況や脆弱性情報を継続的に監視してくれる GitHub 標準のセキュリティ機能です。

検知した依存関係については、ライブラリのバージョンアップを行うプルリクエストを自動で作成することもでき、依存関係の更新や脆弱性対応を継続的に運用しやすくします。

Dependabot は主に以下の 3つの機能を提供しています。

機能 役割
Dependabot alerts 利用しているライブラリに含まれる脆弱性を検知
Dependabot security updates 脆弱性を含むライブラリを修正する更新PRを自動作成
Dependabot version updates 脆弱性有無に関わらず、より新しいバージョンへの更新PRを作成

docs.github.com

Dependabot は GitHub に標準で提供されている機能のため、追加料金なしで利用できます。 Public リポジトリでは無料で利用でき、Private リポジトリでも基本機能は無料で利用可能です。

github.com

SBOM（Software Bill of Materials） について

SBOM（Software Bill of Materials）とは、ソフトウェアを構成する ライブラリやコンポーネントの一覧をまとめた「ソフトウェア部品表」 のことでソフトウェアに含まれる依存関係を含めた構成要素（部品）を一覧化したものと言えます。

SBOM は主に以下のような情報が含まれます。

  • 利用しているライブラリ名
  • バージョン情報
  • 依存関係（どのコンポーネントがどれに依存しているか）
  • 配布元やライセンス情報 など

github.com

SBOMのフォーマットには以下があります。

  • CycloneDX
    • OWASP コミュニティによって開発された SBOM フォーマット（JSON / XML 等）
    • セキュリティ脆弱性情報を扱える構造
    • 自動生成・自動解析との相性が良い
  • SPDX
    • ライセンス情報の管理に強い SBOM フォーマット
    • ISO 標準として広く認知されている
    • 非常に多くの情報を表現できる
      • SPDX-Lite といった必要最低限の項目のみを扱う軽量版も有り
    • 2系、3系があるがフォーマットが異なるので導入にはどちらを採用するか検討が必要
      • 2系：Tag-Value
      • 3系：JSON-LD, RDF/XML, Terse RDF Triple Language, N-Triples（参考：SPDX形式 v3.0）
  • SWID タグ
    • ソフトウェア構成アイテムの識別に特化した標準
    • 脆弱性情報・依存関係情報は弱い

参考：経済産業省 ソフトウェア管理に向けた SBOM（Software Bill of Materials）の導入に関する 手引 Ver. 1.0

　

SBOM は Syft などの OSS ツールを利用することで無償で生成することができます。なお、GitHub Actions を利用する場合は、GitHub Actions の実行時間が利用量としてカウントされる場合があります。

なぜ Dependabot と SBOM を組み合わせるのか

Dependabot と SBOM は、どちらもソフトウェアのセキュリティに関わる仕組みですがそれぞれの用途と役割が違います。

■ Dependabot

  • 依存関係に含まれる脆弱性を検知し、修正のための更新 PR を作成する
  • 「脆弱性対応を継続的に回す仕組み」

■ SBOM

  • ソフトウェアを構成する部品や依存関係を可視化する
  • 「何が使われているかを説明するための情報」

Dependabot により脆弱性対応を継続的に実施でき、SBOM によりソフトウェア構成を正確に把握できます。２つを組み合わせることで、「対応できる」だけでなく「説明できる」脆弱性対応を実現できます。

Dependabot と SBOM の設定方法

どちらも高度なツール導入を前提とせず、GitHub で導入できる点が特徴です。

Dependabot

■ 前提

組織所有 および ユーザー所有のリポジトリであること。

動作の確認は、GitHub から提供されているデモリポジトリをフォークしたもので実施しています。

　

■ 設定方法

対象のリポジトリの Dependabot security updates, Dependency graph, Dependabot alerts を Enable にする。

※ Dependabot security updates を Enable にすると Dependency graph, Dependabot alerts も Enable になります。

参考：GitHub ActionsでのDependabotの自動化 - GitHub ドキュメント

　

■ 動作

「Security」-「Depebdabot」を選択して Depebdabot alerts で検知結果を確認できます。

Depebdabot alerts

対象項目をクリックすると脆弱性を検知したパッケージや影響を受けるバージョンなどが確認できます。

Depebdabot 内容

プルリクエスト（PR） が自動起票されるので変更内容等を確認し、問題がなければマージをします。

セキュリティアップデート例

アラートを抑制したい場合は、Depebdabot alerts から抑制したいアラームの画面を開き、「Dismiss alert」をクリックして理由を記載します。

Dismiss alert 1

Dismiss alert 2

■ 補足-その①

パッケージ エコシステムのカスタマイズをセキュリティ更新プログラムにのみ適用する (バージョン更新プログラムを除外する) 場合は、open-pull-requests-limit キーを 0 に設定します。

参考：open-pull-requests-limit

～ 例 ～
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 0

　

■ 補足-その②

Dependabot の既定では、担当者なしで pull request が発行されるので .github/dependabot.yml や .github/CODEOWNERS にレビュー担当者を記入することでレビュー担当者を自動追加することができます。

参考①：担当者の自動追加

参考②：レビュー担当者の自動追加

SBOM

GitHub UI から SBOM Export を実行してSBOMを取得することできます。 GitHubにログインし、「Insights」-「Dependency graph」を選択し、「Export SBOM」をクリックします。

SBOM Export

github.blog

ただ、この方法はその時点の依存関係を手動で取得するための機能なので、本記事では SBOM を自動生成・登録し続けるように main ブランチへマージされたタイミングで SBOM を自動生成するよう GitHub Actions を設定してみます。

　

■ 前提

本記事では セキュリティ脆弱性情報が管理しやすい CycloneDX を利用しています。

動作の確認は、GitHub から提供されているデモリポジトリをフォークしたもので実施しています。

今回は、複数のパッケージエコシステム（package ecosystem）が含まれていたため、GitHub のドキュメントでも紹介されている SBOM 生成ツールである Syft（OSS ツール）を利用します。

　

■ 設定方法

Syft を利用して CycloneDX を作成します。

参考①：GitHub Actionsからソフトウェア部品表を生成する

参考②：GitHub Action for SBOM Generation

Sample GitHub Actions：.github/workflows/sbom.yml

name: SBOM

on:
  push:
    # main ブランチに push（例：PR マージ）されたタイミングで実行
    branches: [main]

permissions:
  # SBOM生成時に依存関係などを解析するためにリポジトリの内容を読み取る権限
  contents: read

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # anchore/sbom-action は内部で Syft を実行する GitHub Action
      # Syft は OSS の SBOM 生成ツールであり、ソースコードや依存関係を解析してソフトウェア部品表を生成する
      # format: SBOM の出力フォーマットを指定（今回は OWASP が策定している CycloneDX JSON を利用）
      # artifact-name: SBOM artifact の名前を指定（例：sbom）
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          # CycloneDX JSON 形式で出力
          format: cyclonedx-json
          # SBOM artifact の名前
          artifact-name: sbom

　

■ 動作

main にマージすると「Actions」-「Summary」から対象の SBOM をダウンロードできます。（ZIP圧縮されてダウンロードされます。）

SBOM Artifacts

Github Actions の実行結果はこのような感じです。

Github Actions Syft SBOM

Syft（CycloneDX 形式）で取得した SBOM をダウンロードしたファイルの内容です。

{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:cd7cb099-db84-4ee4-959c-e41c9511d4ed",
  "version": 1,
  "metadata": {
    "timestamp": "2026-03-04T09:11:14Z",
    "tools": {
      "components": [
        {
          "type": "application",
          "author": "anchore",
          "name": "syft",
          "version": "1.42.1"
        }
      ]
    },
    "component": {
      "bom-ref": "af63bd4c8601b7f1",
      "type": "file",
      "name": "."
    }
  },
  "components": [
    {
      "bom-ref": "pkg:npm/%40handsontable/formulajs@2.0.2?package-id=5658b20c60fafb0c",
      "type": "library",
      "name": "@handsontable/formulajs",
      "version": "2.0.2",
      "cpe": "cpe:2.3:a:\\@handsontable\\/formulajs:\\@handsontable\\/formulajs:2.0.2:*:*:*:*:*:*:*",
      "purl": "pkg:npm/%40handsontable/formulajs@2.0.2",
      "properties": [
        {
          "name": "syft:package:foundBy",
          "value": "javascript-lock-cataloger"
        },
        {
          "name": "syft:package:language",
          "value": "javascript"
        },
        {
          "name": "syft:package:type",
          "value": "npm"
        },
        {
          "name": "syft:package:metadataType",
          "value": "javascript-npm-package-lock-entry"
        },
        {
          "name": "syft:location:0:path",
          "value": "/javascript/package-lock.json"
        }
      ]
    },
    {
      "bom-ref": "pkg:npm/%40handsontable/formulajs@2.0.2?package-id=ebd331a5161a8420",
      "type": "library",
      "name": "@handsontable/formulajs",
      "version": "2.0.2",
      "cpe": "cpe:2.3:a:\\@handsontable\\/formulajs:\\@handsontable\\/formulajs:2.0.2:*:*:*:*:*:*:*",
      "purl": "pkg:npm/%40handsontable/formulajs@2.0.2",
      "properties": [
        {
          "name": "syft:package:foundBy",
          "value": "javascript-lock-cataloger"
        },
        {
          "name": "syft:package:language",
          "value": "javascript"
        },
        {
          "name": "syft:package:type",
          "value": "npm"
        },
        {
          "name": "syft:package:metadataType",
          "value": "javascript-yarn-lock-entry"
        },
        {
          "name": "syft:location:0:path",
          "value": "/javascript/yarn.lock"
        }
      ]
    },

～ 省略 ～

余談ですが、デモリポジトリでは Ruby もあるのでその情報も取得ができていました。

　

■ 補足-その①

Syft（CycloneDX 形式）で取得した 各キーの概要となります。（参考までに...）

▼ トップレベルのキー

キー 説明
$schema JSONスキーマのURL（CycloneDX 1.6形式）
bomFormat BOMのフォーマット名（CycloneDX固定）
specVersion CycloneDX仕様のバージョン（1.6）
serialNumber このBOMファイルの一意識別子（UUID形式）
version このBOMのバージョン番号
metadata BOM自体のメタ情報

▼ metadata の中身

キー 説明
timestamp SBOM生成日時
tools.components SBOMを生成したツール情報（ここでは syft v1.42.1）
component SBOMの対象となるルートコンポーネント（このリポジトリ）

▼ components の各エントリー

キー 説明
bom-ref このBOM内でコンポーネントを一意に識別するID
type コンポーネントの種類（library=ライブラリ、file=ファイル）
name パッケージ名
version バージョン
licenses ライセンス情報（SPDX ID形式）
cpe CVE脆弱性照合用の識別子（CPE 2.3形式）
purl パッケージの標準URL（Package URL形式）
hashes ファイルのハッシュ値（type: fileの場合のみ）
properties syft固有の追加メタデータ（下記参照）

▼ properties の主なname値

name 説明
syft:package:foundBy どのカタログ処理で検出されたか（例: javascript-lock-cataloger）
syft:package:language プログラミング言語（javascript, rubyなど）
syft:package:type パッケージマネージャの種類（npm, gem, github-actionなど）
syft:package:metadataType 検出元ファイルの種類（javascript-npm-package-lock-entryなど）
syft:location:0:path 検出元ファイルのパス
syft:cpe23 追加のCPE識別子（表記揺れのバリエーション）

今回の SBOM では同じパッケージが2エントリ存在することがありますが、 package-lock.json と yarn.lock の両方から検出されているためです。

　

■ 補足-その②

Anchore が提供する OSS ツールを組み合わせることで、ソフトウェアサプライチェーンの管理を行うことも可能です。

Syft を利用して SBOM を生成し、Grype を利用してその SBOM をもとに脆弱性スキャンを実施します。 さらに Grant を利用することで、オープンソースライセンスのコンプライアンス確認を行うこともできます。

Anchore OSS flow
引用元：Anchore Project

まとめ

Dependabot を導入することで「脆弱性対応を継続的に回す仕組み」を構築でき、SBOM を導入することで「何が使われているかを説明するための情報」を取得できます。

Dependabot によって脆弱性対応を継続的に実施しつつ、SBOM によってソフトウェア構成を明確にしておくことでセキュリティ対応とソフトウェア管理の両方を支えることができます。

この2つを組み合わせることで脆弱性への対応だけでなくソフトウェア構成の透明性を高めることができます。

SBOM 生成ツールは、今回紹介した Syft 以外にも複数存在しますので利用しやすさや要件との適合性を踏まえながら適切なツールを選定してください。

近藤 諒都

（記事一覧）

カスタマーサクセス部CS5課

夜行性ではありません。朝活派です。

趣味：お酒、旅行、バスケ、掃除、家庭用パン作り（ピザも）など

2025 Japan AWS All Certifications Engineers