Uniforceのインフラエンジニアのニシです。

最近はBlendyの濃厚ヘーゼルナッツラテにハマっています。(甘い飲み物、食べ物、好き🤤)

今回はGitHubのDependabotについて調べて理解を深めてみましたので、そのアウトプットです。

Dependabotとは

Dpendabotの速習にはGitHubのクイックスタートガイドがわかりやすいです。

Dependabot クイックスタート ガイド - GitHub Docs

Dependabot は、依存関係の管理に役立つ 3 つの異なる機能で構成されています。 　・Dependabot alerts — リポジトリで使っている依存関係に内在する脆弱性について通知します。 　・Dependabot security updates — 使っている依存関係のうち、既知のセキュリティ脆弱性があるものを更新するための pull request を自動的に生成します。 　・Dependabot version updates — 依存関係を最新に保つための pull request を自動的に発行します。

クイックスタートガイドから、Dependabot alertsとDependabot security updatesが脆弱性に対して動き、Dependabot version updatesは脆弱性に関係なく依存関係を最新にするために動くことが読み取れます。

また、クイックスタートガイドを読み進めていくとDependabotを使う場合には依存関係グラフも使用されることがわかります。

メモ: 依存関係グラフがリポジトリに対してまだ有効になっていない場合は、Dependabot を有効にすると、GitHub によって自動的に有効になります。

依存関係グラフとは

依存関係グラフとは何であるか、GitHubのドキュメントを見てみます。

依存関係グラフについて - GitHub Docs

依存関係グラフは、リポジトリに格納されているマニフェストおよびロック ファイルと、依存関係送信 API (ベータ) を使用してリポジトリに送信された依存関係の概要です。 それぞれのリポジトリについて、以下が表示されます: 　・リポジトリが依存している依存関係、エコシステム、パッケージ 　・リポジトリに依存する対象、リポジトリ、パッケージ 依存関係ごとに、ライセンス情報と 脆弱性の重大度を確認できます。 検索バーを使用して、特定の依存関係を検索することもできます。 依存関係は、脆弱性の重大度によって自動的に並べ替えられます。

リポジトリで使用しているマニフェストファイルやロックファイルを読み取り、依存関係ごとにライセンスや脆弱性の情報を可視化してくれるものであることがわかります。

また、依存関係グラフがサポートしているパッケージエコシステムが同一ドキュメント内に記載があります。

依存関係グラフについて - GitHub Docs

Dependabotと依存関係グラフの関係性

依存関係グラフが何であるかがわかってきました．

それではDependabotを使うときにどのように使われているのかですが、Dependabot alertsのページに書かれていました。

Dependabot アラートについて - GitHub Docs

Dependabot により、安全でない依存関係を検出するためにリポジトリのデフォルト ブランチ スキャンが実行され、以下の場合に Dependabot alertsが送信されます。

・GitHub Advisory Database に新しいアドバイザリが追加されたとき。 詳細については、「GitHub Advisory Database でのセキュリティ アドバイザリの参照」を参照してください。

注: GitHub によってレビューされたアドバイザリのみが、Dependabot alertsをトリガーします。

・リポジトリの依存関係グラフが変更された場合。 たとえば、共同作成者がコミットをプッシュして、依存しているパッケージまたはバージョンを変更したとき、またはいずれかの依存関係のコードが変更されたときなどです。 詳しくは、「依存関係グラフについて」を参照してください。 注: Dependabot では、アーカイブされたリポジトリはスキャンされません。

Dependabot alertsのトリガーとして依存関係グラフが使われているため、Dependabotを使用する際には依存関係グラフも有効化する必要があることがわかりました。

Dependabot alertsのトリガーの1つとして依存関係グラフがありますが、もう1つのトリガーとしてGitHub Advisory Databaseがでてきましたので、次にGitHub Advisory Databaseについて調べてみます。

GitHub Advisory Databaseとは

GitHub Advisory Databaseとは何であるか、GitHubのドキュメントを見てみます。

GitHub Advisory Database について - GitHub Docs

アドバイザリは、以下のソースから GitHub Advisory Database に追加されます。

・GitHubで報告されたセキュリティアドバイザリ 　・National Vulnerability Database 　・npm セキュリティ アドバイザリ データベース 　・FriendsOfPHP データベース 　・Go Vulncheck データベース 　・GitHub Packaging Advisory データベース 　・Ruby Advisory データベース 　・RustSec Advisory データベース 　・コミュニティのコード提供。 詳細については、「https://github.com/github/advisory-database/pulls」を参照してください。

GitHub Advisory Databaseは各ソースから情報を収集した脆弱性情報のデータベースのようです。

そして、GitHub Advisory Databaseは3つのグループで情報をカテゴリー化しているとのことです。

• GitHub でレビューされたアドバイザリ

  レポジトリに対する Dependabot alertsを有効にすると、GitHub でレビューされた新しいアドバイザリによって、依存するパッケージの脆弱性が報告された場合、自動的に通知されます。

• レビューされていないアドバイザリ

  この種類のアドバイザリは、有効性または完成度について確認されないため、Dependabot では、レビューされていないアドバイザリの Dependabot alerts は作成されません。

• マルウェア アドバイザリ

  ほとんどの脆弱性はダウンストリーム ユーザーが解決できないため、Dependabot では、マルウェアが検出されたときにアラートは生成されません。 GitHub Advisory Database で type:malware を検索すると、マルウェア アドバイザリを表示できます。

Dependabot alertsのページにもありましたが、3種類のアドバイザリのうちDependabot alertsのトリガーに使用されるのはGitHubでレビューされたアドバイザリのみです．レビューされたものが情報として送られてくるのは利用する側としては助かりますね。

ここまででDependabot alertsとそのトリガーとして使われている依存関係グラフ、GitHub Advisory Databaseについてわかってきました。

次はDependabot security updatesを掘り下げてみます。

Dependabot security updatesとは

Dependabot security updatesのページを見てみます。

Dependabot のセキュリティ アップデート - GitHub Docs

Dependabot security updates がリポジトリに対して有効になっている場合、Dependabot は、使用可能なパッチを持つすべての開いている Dependabot アラートを解決するために pull request を自動的に開こうとします。 どのアラートに対して Dependabot が pull request を開くかカスタマイズする場合は、Dependabot security updates を [無効] のままにし、オート トリアージ ルールを作成する必要があります。 詳しくは、「自動トリアージ ルールをカスタマイズして Dependabot アラートの優先度を設定する」を参照してください。

クイックスタートガイドに「既知のセキュリティ脆弱性があるものを更新するための pull request を自動的に生成します。」との説明がありましたが、Dependabot alertsの情報をもとにしてpull requestを開いてくれることがわかりました。

注意するのはカスタマイズしたいトリアージルールを使用した場合はDependabot security updatesは無効のままにする必要がある点でしょうか。

カスタマイズしたトリアージルールについてはこちらに記載があります。

自動トリアージ ルールをカスタマイズして Dependabot アラートの優先度を設定する - GitHub Docs

GitHubがプリセットで用意してくれているルールもあります．対象はnpmのみですが、最初からカスタマイズしたトリアージルールを作っていくのも難しいと思いますので、こちらのプリセットルールを使用してみるのも良さそうです。

GitHub プリセット ルールを使用して Dependabot アラートに優先順位を付ける - GitHub Docs

Dependabot version updatesとは

次にDependabot version updatesについて見ていきます。

GitHub Dependabot のバージョンアップデートについて - GitHub Docs

You enable Dependabot version updates by checking a dependabot.yml configuration file into your repository. The configuration file specifies the location of the manifest, or of other package definition files, stored in your repository. Dependabot uses this information to check for outdated packages and applications. Dependabot determines if there is a new version of a dependency by looking at the semantic versioning (semver) of the dependency to decide whether it should update to that version. For certain package managers, Dependabot version updates also supports vendoring. Vendored (or cached) dependencies are dependencies that are checked in to a specific directory in a repository rather than referenced in a manifest. Vendored dependencies are available at build time even if package servers are unavailable. Dependabot version updates can be configured to check vendored dependencies for new versions and update them if necessary.

日本語でページにアクセスしても英語表記でした。Google翻訳したものがこちらです。

dependabot のバージョン更新を有効にするには、dependabot.yml 構成ファイルをリポジトリにチェックインします。構成ファイルは、リポジトリに保存されているマニフェストまたは他のパッケージ定義ファイルの場所を指定します。 dependabot はこの情報を使用して、古いパッケージやアプリケーションをチェックします。 dependabot は、依存関係のセマンティック バージョニング (semver) を調べて、そのバージョンに更新する必要があるかどうかを判断することで、依存関係の新しいバージョンがあるかどうかを判断します。特定のパッケージ マネージャーでは、Dependabot のバージョン更新でもベンダー化がサポートされます。ベンダー (またはキャッシュ) 依存関係は、マニフェストで参照されるのではなく、リポジトリ内の特定のディレクトリにチェックインされる依存関係です。パッケージ サーバーが利用できない場合でも、ベンダーの依存関係はビルド時に利用できます。新しいバージョンのベンダーの依存関係を確認し、必要に応じて更新するように、Dependabot のバージョン更新を構成できます。

Dependabot version updatesを有効にするにはdependabot.yml構成ファイルが必要であること、依存関係に脆弱性がなくても、依存関係を最新のバージョンがあるかどうかチェックすることができることがわかります．クイックスタートガイドに書いてあった通りですね。

サポートされているパッケージエコシステムは依存関係グラフのものとは違うようです．例えば、Terraformもあったりします。

dependabot.yml ファイルの構成オプション - GitHub Docs

組織のリポジトリに対してDependabotを有効にする

組織で有効にできるセキュリティでは、security configurationsとglobal settingsの2つがあります。

大規模なセキュリティ機能の有効化について - GitHub Docs

GitHubの組織に対してDependabotを有効化したことがある方は「こんな設定だったかな？」と思われたのではないでしょうか。

2024年7月10日にCode security configurationsがGAされたことにより設定画面が変わりました(正確には2024年4月のパブリックベータ公開時点で設定画面が変わっています)。

記事にある通り昔の設定はsecurity configurationsに”Legacy”として残ります。

Code security configurations are now GA · GitHub Changelog

それでは、security configurationsについて見てます．

リポジトリのセキュリティ構成の選択 - GitHub Docs

Security configurations は、GitHub のセキュリティ機能向け有効化設定のコレクションで、組織内の任意のリポジトリに適用が可能です。GitHub には、次の 2 種類の security configurations が提供されています。

• GitHub-recommended security configuration
• Custom security configurations

組織では、最初に GitHub-recommended security configurationを適用することをお勧めします。 組織内のリポジトリに GitHub-recommended security configuration を適用した後、各リポジトリのセキュリティ結果を評価し、代わりに custom security configuration を作成して適用するかどうかを判断できます。

security configurationsがセキュリティ機能を有効化するためのコレクションで組織内のリポジトリに適用できることがわかります。

では、どのような設定ができるのかについては、Custom security configurationsのページを見るとわかります。

カスタム セキュリティ構成の作成 - GitHub Docs

Dependency graph や Dependabotの設定を有効化する項目がありますので、GitHubの組織に対してDependabotを有効化したことがある方には馴染みやすいのではないでしょうか。

Dependency graph や Dependabot以外にもGitHub Advanced Securityライセンスがあることで使用できるCode scanningやSecret scanningもあります。

まさしく、セキュリティ機能を有効化するためコレクション、といった印象を受けます。

次にglobal settingsを見ていきます。

組織のグローバル セキュリティ設定の構成 - GitHub Docs

リポジトリ レベルのセキュリティ設定を決定する security configurations と共に、組織の global settings も構成する必要があります。 Global settings は組織全体に適用され、ニーズに基づいて GitHub Advanced Security 機能をカスタマイズできます。 global settings ページでセキュリティ マネージャーを作成して、組織のセキュリティを監視およびメインすることもできます。

global settingsがsecurity configurationsと一緒に使用する機能であること、 GitHub Advanced Security 機能をカスタマイズできるものであることがわかります．しかし、ドキュメントを見るとGitHub Advanced Securityのライセンスが必要なCode scanningやSecret scanning以外にDependabotの設定もできることがわかります。

• グローバル Dependabot 設定の構成

  Dependabot 自動トリアージ ルール の作成と管理 Dependabot セキュリティ更新プログラムのグループ化 GitHub Actions ランナーでの依存関係の更新の有効化 プライベート リポジトリへの Dependabot アクセス権の付与 への Dependabot アクセス権の付与

• グローバルな code scanning 設定の構成

  デフォルト設定の拡張クエリ スイートの推奨 Pull Requestの code scanning チェックの失敗しきい値の設定

• グローバルな secret scanning 設定の構成

  ブロックされたコミットのリソース リンクの追加

以上をまとめると、組織のリポジトリに対してDependabotを有効化するには、security configurationsで有効化すれば良いことがわかりました。

そして、Dependabotの細かな設定を組織で統一的に設定するにはsecurity configurationsを使用するのが良さそうです。

まとめ

今回はGitHubのDependabotについて調べたことを記事にしました．VCS（バージョン管理システム）のホスティングサービスとしてGitHubを使用する際に無料で利用できるセキュリティ機能であるDependabotですが、これまでその裏側の動きを詳しく調べたことがありませんでしたので、とても面白かったです。

本日の記事はここまでとなります。

最後まで読んでいただきありがとうございました🙌