こんにちは！クライアント開発チームの安野です。
クライアント開発チームでは、クライアントポータルという to B 向けのサービス開発を担当しており、私はそこでフロントエンド・バックエンドの開発に携わっています。
クライアントポータルの内容はこちらからも確認できるので、ご興味があれば是非ご一読いただけますと幸いです！
そんなクライアント開発チームですが、この度、 Dependabot というライブラリの脆弱性管理ツールを導入しました。
今回は導入にあたって調査した Dependabot について共有できればと思います。
はじめに
ソフトウェア開発において、外部ライブラリの利用はもはや常態化しています。 豊富な機能や開発効率の向上といったメリットから、多くのプロダクトにライブラリが活用されています。
しかし、外部ライブラリにも脆弱性が含まれる可能性があり、発見や修正に多くの時間と労力を費やす必要が生じるケースも少なくありません。
このような課題を解決するために、Dependabot のような脆弱性管理ツールが注目されています。
Dependabot は GitHub と連携して、利用しているライブラリの脆弱性を自動的に検知し、修正のためのプルリクエストを作成するツールです。 これにより、開発者は脆弱性対策に費やす時間を大幅に削減でき、開発効率を向上させることができます。
本記事では、Dependabot の機能と設定方法、および弊チームでの利用状況について紹介いたします。
Dependabotとは
Dependabot はプロジェクトで利用するパッケージマネージャの依存関係を検知し、検知したライブラリの更新状況を監視します。
さらに必要に応じて該当のライブラリのバージョンアップを行うプルリクエストを発行してくれるサービスです。
https://docs.github.com/en/code-security/dependabot
Dependabotは主に3つの機能を有しています。
| 機能 | 役割 |
|---|---|
| Dependabot alerts | ライブラリの脆弱性を通知する |
| Dependabot security updates | 脆弱性を含むライブラリの更新を行う |
| Dependabot version updates | より新しいバージョンへの更新を行う |
Dependabot alerts
Dependabot alerts はコードが安全でないパッケージに依存していることを検知したタイミングで通知を行います。
リポジトリのデフォルトブランチをスキャンして、以下の場合にアラートが通知されます。
- GitHub Advisory Databaseに新しいアドバイザリが追加されたとき
- リポジトリの依存関係グラフが変更された場合
Dependabot が脆弱な依存関係を識別すると、リポジトリの Security タブにアラートが生成されます。
後述する Dependabot security updates を有効にしている場合、アラートと共に脆弱性を解消するバージョンへライブラリを更新するプルリクエストが作成します。(脆弱性に対応するバージョンが提供されてない場合はこの限りではありません。)
Dependabot alertsは Settings タブから有効化することができます。
Dependabot security updates
リポジトリの依存関係グラフで脆弱性のある依存関係に対して前述の Dependabot alerts が発生すると、Dependabot security updates はその脆弱性を解消するためのプルリクエストを作成します。
プルリクエストでは、該当ライブラリについてパッチを含む最小バージョンに依存関係を更新し、プルリクエストを Dependabot alerts にリンクします。
作成されるプルリクエストには、リリースノート、変更ログエントリ、コミットの詳細など脆弱性に関する情報が含まれます。
プルリクエストを一時的に無視したい場合には、該当のプルリクエストを Close することができます。 (@dependabot コマンドを利用していつでも再開可能です。)
利用可能なコマンドは以下になります。
@dependabot rebase will rebase this PR @dependabot recreate will recreate this PR, overwriting any edits that have been made to it @dependabot merge will merge this PR after your CI passes on it @dependabot squash and merge will squash and merge this PR after your CI passes on it @dependabot cancel merge will cancel a previously requested merge and block automerging @dependabot reopen will reopen this PR if it is closed @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
Dependabot security updates は Settings タブから有効化することができます。
Dependabot version updates
Dependabot version updates はライブラリに脆弱性がなくてもライブラリを最新のバージョンに保つようにプルリクエストを作成します。
依存関係グラフに最新のバージョンでないライブラリを検知したことを契機にプルリクエストを作成します。
(作成されるプルリクエストについては Dependabot security updates と大きな違いはありません。)
Dependabot version updates を有効化するには、プロジェクトの.githubフォルダ配下にdependabot.ymlファイルを配置する必要があります。
配置すると Settings タブからもdependabot.ymlファイルが編集できるようになります。
Dependabotの設定
前述のdependabot.ymlファイルを配置することで、Dependabot security updates と Dependabot version updates の動作を設定することができます。
詳細なプロパティは以下から確認できます。
必須プロパティがpackage-ecosystem/directory/scheduleの3つあるので最小構成としては以下のようになるかと思います。
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
directoryはパッケージマネージャに関するファイル(npmならpackage.json)が配置されている場所を示す必要があります。
また、ドキュメントにも記載されているように、Dependabot version updates では基本全てのプロパティが設定できますが、Dependabot security updates では設定できないプロパティが多々あるのでご留意ください...。
弊チームにおける利用状況
そんな Dependabot ですが弊チームでは、脆弱性の更新をメインとして Dependabot security updates を有効化して運用しています。
大まかな流れとしては下図のようになります。
1️⃣ : Dependabotがリポジトリ内のパッケージマネージャを探索し、脆弱性が含まれるライブラリとその更新情報を取得する
2️⃣ : 取得した情報をもとに、脆弱性を更新するプルリクエストを作成する
3️⃣ : 開発者が作成されたプルリクエストを確認し、マージする
Dependabot がプルリクエストを作成したタイミングで、CI として用意されている Github Actions がビルド・テストを実施します。
その CI が問題なく通ればマージする判断もできるのですが、弊チームでは品質影響を重視してさらに手動によるアプリケーション機能の確認と QA まで実施する方針としています。
導入する上ではまったポイント
Dependabot が作成するプルリクエスト上で対象ライブラリがpackage.jsonとpackage-lock.jsonの両方に存在するにも関わらずpackage-lock.jsonしか更新してくれない事象が発生していました。
これは Depedabot の設定によるもので、dependabot.ymlから設定できるversioning-strategyをincreaseにすることで弊チームの環境では解消しました。
デフォルトだと versioning-strategy: autoとなっていて、この状態だとincreaseとwidenがversioning-strategyに適用されるようです。
更新対象ライブラリを4.5.0に更新する状況で、package.json内のバージョン指定が"xxx": "^4.4.9",のように指定されていた場合にwidenが適用されても更新対象とならない状況であったと認識しています。そのため明示的にversioning-strategyをincreaseと設定しました。
参考になった issue
https://stackoverflow.com/questions/60201543/dependabot-only-updates-lock-file
おわりに
弊チームでは現時点で脆弱性のあるライブラリを更新対象としていますが、今後テストカバレッジがより向上して CI によるテストで品質を担保できる状況になった際には、自動マージや最新バージョンへの追従を含む更新も対象としていければと考えています。
また、Dependabot と Github Actions を併用して、Dependabot によって作成されたプルリクエストに対してより細かなカスタマイズを Github Actions で行うといった構成も考えていて、今後運用していきながら改善を進められればと思います。
GitHub ActionsでのDependabotの自動化
ビザスクではエンジニアの仲間を募集しています！ 少しでもビザスク開発組織にご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！ developer-recruit.visasq.works
