はじめに
こんにちは、ACS事業部の田中です。 今回は依存関係（ライブラリ、パッケージなど）の脆弱性と、Dependabot を用いた組織的な脆弱性対応について整理したいと思います。
依存関係の脆弱性
近年で有名な依存関係の脆弱性の事例といえば、Log4Shell（CVE-2021-44228）でしょうか。
2021年11月、ログ出力ライブラリ「Apache Log4j 2」に脆弱性が発見されました。 Log4j は Java ベースのアプリケーションで広く利用されており、この脆弱性を利用した攻撃も容易であることから、世界に影響を及ぼしました。
- Apache Log4j の脆弱性対策について(CVE-2021-44228) | アーカイブ | IPA 独立行政法人 情報処理推進機構
- Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた - piyolog
脆弱性の深刻度の国際的指標である CVSS（共通脆弱性評価システム）では、この脆弱性を Critical（スコア10.0、致命的）としています。
この脆弱性の修正は、脆弱性が公開される数日前のバージョンでリリースされました。 しかし、当時、脆弱性の対応に組織的に取り組んでいる企業は多いとは言えず、Log4j を使用しているコードを特定し、修正バージョンを適用し終えるには長時間かかったようです。
余談
Log4Shell の情報や修正バージョンの公開から数日の様子を SNS で遡ってみたところ、日本に情報が広がり始めたのが金曜日の夜中だったこともあり、休日対応に追われる方も散見されました。 当時、私が勤めていた企業では Java で開発していなかったため直接的な影響はありませんでしたが、『なにやら大変な脆弱性が発見された』と話題になっていたのを覚えています。
脆弱性発生時の対応
例に挙げた Log4Shell 以外にも、Critical な脆弱性やバックドアの混入は毎年・毎月・毎週 発生しています。 では、このように利用している依存関係に脆弱性が発見されたとき、どのような対応が必要でしょうか。
- 脆弱性に関する情報収集
- 影響範囲の確認
- 対応方法の検討
- 実対応と検証
- 関係者への連絡
ざっと書き出してみましたが、特に『1. 脆弱性に関する情報収集』と『2. 影響範囲の確認』が大変なように思われます。 セキュリティと開発で担当するチームが分かれている場合、セキュリティチームが担当することになる部分でしょうか。 脆弱性に関する情報を常日頃からキャッチアップしておく必要がありますし、その脆弱性が自社のプロダクトに関連するのか確認するのも Ctrl + F で検索して終わり、というわけにもいきません。
Dependabot による脆弱性の検知
Dependabot は GitHub が提供する自動化されたセキュリティと依存関係管理ツールです。
主な機能である Dependabot alerts はリポジトリ内の依存関係を監視し、既知の脆弱性データベース（GitHub Advisory Database など）と照合して、脆弱性を自動で検出します。 どのような脆弱性が、どの依存関係に影響を及ぼし、どのリポジトリで修正が必要か、を一覧で確認できるため、前述の『1. 脆弱性に関する情報収集』と『2. 影響範囲の確認』にかかる時間が大幅に短縮されます。
すべてのリポジトリで依存関係の脆弱性が継続的にチェックされるように組織全体で Dependabot alerts を有効化しておけば、セキュリティ担当者が脆弱性の情報が公開されてから慌てて影響範囲を確認する、といったことはなくなるでしょう。
また、Dependabot security updates を有効化しておけば、依存関係を脆弱性を排除したバージョンにアップデートするプルリクエストを自動で作成します。 プルリクエストに記述された脆弱性とアップデートに関する情報を確認し、マージしてしまえば、『3. 対応方法の検討』と『4. 実対応と検証』は完了です。
定期的にバージョンアップをする文化づくり
脆弱性のある依存関係をアップデートする場合、周辺の関連する依存関係も同時にアップデートが必要になるケースは少なくありません。 脆弱性が極力含まれないように維持するのと同時に、利用する依存関係を定期的に最新バージョンに維持することも重要です。
Dependabot version updates を有効化しておくことで、最新バージョンでない依存関係を検知してアップデートするプルリクエストを自動で作成します。
Dependabot を活用した組織的な脆弱性対応
以上の機能を用いて、いつ・誰が・どのような対応を行うのかを整理しました。
| セキュリティチーム | 開発チーム | |
|---|---|---|
| 通常時 | Dependabot すべてのリポジトリで依存関係の脆弱性チェックが実行され るように設定します。（組織設定、ルール化） |
Dependabot alerts 依存関係の脆弱性アラートを解消し、脆弱性が極力含まれ ないように維持します。 Dependabot version updates 脆弱性のある依存関係をアップデートするときは、周辺の 関連する依存関係も同時にアップデートを必要とするケース が多くあります。こうしたケースに備え、定期的に利用する 依存関係を最新バージョンに維持します。依存関係を定期的 にアップデートをする文化（意識）づくりも重要です。 |
| 脆弱性発生時 | Dependabot alerts 問題となっている脆弱性がある依存関係を利用している リポジトリを特定します。 Dependabot security updates 脆弱性を含む依存関係をアップデートするプルリクエストを 自動で作成することで、効率よく脆弱性対応を進めることが できます。 対応時のポイント 問題が発生した依存関係が組織内のどのリポジトリで利用 されているか、すぐに把握・対応できる仕掛けづくりが重要 となります。 |
セキュリティチームと協力しながら依存関係をアップデートし、 アプリケーションを公開します。 対応時のポイント 依存関係が最新の状態になっていない場合は、修正や動作確認 に数日から1-2週間かかる場合もあります。問題発生から 修正・リリースまでの時間を最短にするためにも、定期的に 依存関係のバージョンを最新に維持することが重要となります。 |
企業によってチームやロールに差はあると思いますが、脆弱性に組織で対応するイメージは掴んでいただけたのではないでしょうか。 Dependabot は GitHub Free プランから利用可能ですので、ぜひ活用をご検討ください。
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage 、Azure AI Service などを活用し、Platform Engineering + AI の推進・内製化のご支援をしております。
www.ap-com.co.jp www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！ 我々の事業部の CultureDeck はこちらです。
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
