TesujiGitHubを使っているなら、依存パッケージの脆弱性確認を始める選択肢がDependabotです。GitHub Freeを含む全プランで、通知・セキュリティ更新・定期更新の基本機能を利用できます。これらを使うために、GitHub Code SecurityやGitHub Secret Protectionの追加契約が必須というわけではありません。GitHubの全プランで利用できる機能
この記事はGitHub.comでの利用を対象に、2026年10月28日時点の公式情報を整理したものです。
Dependabotの三つの機能
| 機能 | 何をしてくれるか | 最初に見るところ |
|---|---|---|
| Dependabot alerts | 依存関係にある既知の脆弱性を知らせる | 対象パッケージ・影響バージョン・修正版・利用箇所 |
| Dependabot security updates | 脆弱性を解消する更新PRの作成を試みる | どの警告を直すPRか、更新できない理由がないか |
| Dependabot version updates | 古くなった依存関係の更新PRを定期的に作る | 更新内容・互換性・リリースノート |
脆弱性の修正と、通常のバージョン追従では目的が異なります。security updatesとversion updatesは、GitHub上の全リポジトリで利用可能と案内されています。実際に対応できる依存関係は、エコシステムや構成によります。セキュリティ更新、バージョン更新
GitHub Advisory Databaseと、自分の依存関係を照合する
Dependabot alertsは、デフォルトブランチの依存関係をもとに、新しい脆弱性情報や依存関係の変更を検知します。GitHub Advisory DatabaseでGitHubがレビューしたアドバイザリが対象です。通知の仕組みと検出範囲
通知が出たら、深刻度だけでなく、どのパッケージがどこから入っているか、修正版があるかを確認します。TesujiのGitHub Advisory Databaseの解説から、情報源の役割もたどれます。
無料の範囲と、CIの利用料を分ける
Dependabotの基本機能を追加契約なしで使えることと、関連するすべての処理が無条件に無料であることは別です。
| 処理 | 料金・利用枠の確認点 |
|---|---|
| 標準のGitHub-hosted runnerで、Dependabotが更新PRを生成するジョブ | 含まれるGitHub Actions実行分数の消費対象にならない |
| Dependabotをlarger runnerで動かす場合 | 通常のrunner料金が適用される |
| 更新PRを受けて、自分たちのテストやビルドを実行するCI | 通常のGitHub Actionsとして扱う。非公開リポジトリではプランの無料枠と超過利用を確認する |
公開リポジトリで標準のGitHub-hosted runnerを使う通常のActions実行は無料と案内されています。実行環境や保存物などの条件は、Actions側の料金仕様も確認します。Dependabotの更新ジョブの扱い、GitHub Actionsの料金仕様
また、Dependabot alertsの担当者・チーム・AIエージェントへの割り当てなど、別のライセンスが必要な機能もあります。基本機能と追加機能の条件を分けて確認してください。アラート割り当ての利用条件
まずは通知と、更新PRの設定を確認する
リポジトリのセキュリティ設定で、Dependabot alertsとsecurity updatesを確認します。version updatesには、通常、リポジトリの構成に合わせた .github/dependabot.yml を使います。公式クイックスタートは、設定の有効化と警告・PRの確認手順を案内しています。公式の導入ガイド
ルートにpackage.jsonがあるプロジェクトで、パッケージとGitHub Actionsを週ごとに確認する設定例です。pnpmでもエコシステムの指定は npm を使います。
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
この例はversion updatesの設定です。脆弱性の通知・セキュリティ更新の有効化も別に確認します。複数のアプリを置くリポジトリや非公開レジストリを使う構成では、対象ディレクトリとアクセス条件を合わせて設定してください。設定項目の公式リファレンス、対応エコシステム
更新PRが届いた後の確認
PRを受け取ったら、更新対象と互換性、manifestとlockfileの差分、テスト・型チェック・ビルドの結果を確認します。マージ後も、実際に動く環境へ修正版が反映されたかを確認します。これはTesuji編集上の運用提案です。
たとえば依存設定だけを変更し、lockfileが対応していないと、固定lockfileを要求するCIのインストールが失敗することがあります。pnpmも、manifestとlockfileが一致しない場合のfrozen installの失敗を説明しています。設定とlockfileを同期して検証することが確認点になります。pnpmのインストール仕様
すべての警告が自動修正されるとは限りません。更新PRを作れない場合や検出範囲外の問題もあるため、担当者を決め、通知から対応完了まで追う運用に組み込みます。
最初に確認する4点
- 対象リポジトリで、依存関係と警告を確認できるか。
- セキュリティ更新と定期更新の、どちらを有効にするか。
- 届いたPRを誰が確認し、どのテストで判断するか。
- 更新PRの生成ジョブと、通常のCIの利用枠を区別しているか。
ソースコードに含める秘密情報の扱いは、APIキー・秘密鍵の解説も参考になります。Dependabotによる依存関係の保守と、秘密情報の保護は、それぞれ対応を確認します。
確認日：2026年10月28日。無料範囲・追加機能・runnerの料金条件は変更されるため、利用時点の公式情報で確認してください。