脆弱性修正の自動化：検出から修正まで

脆弱性修正の自動化とは

脆弱性の修正とは、ソフトウェアから既知の脆弱性を取り除くことです。影響を受けるパッケージをアップグレードする、パッチを適用する、あるいはコンポーネントを置き換えることを指します。修正の自動化は、その作業のうち機械的な部分をソフトウェアに任せます。検出結果を読み取り、どのバージョンで修正されるかを割り出し、マニフェスト、ロックファイル、コードを変更して、その変更を提案します。多くの場合、提案はプルリクエストの形をとります。

現代のコードベースの既知の脆弱性の大半が存在するサードパーティの依存関係については、どのツールでもループは同じです。

1. インベントリ。出荷する各製品に、どのパッケージがどのバージョンで含まれているかを把握する。
2. 照合。そのインベントリをアドバイザリと照合し、新しいアドバイザリが公開されるたびに照合を続ける。
3. 優先順位付け。深刻度、悪用状況、影響範囲から、何を先に修正するかを決める。
4. 修正。修正済みのバージョンを選んで更新し、アップグレードで何かが壊れたらコードを調整する。
5. 検証。変更をビルドしてテストし、実際に出荷されたのが修正済みのバージョンであることを確認する。
6. 記録。何が影響を受け、いつ、どのリリースで修正されたかの記録を残す。

自動化が最も力を発揮するのは、作業が反復的なステップ2、4、6です。最も弱いのは入力が誤っている場合であり、他のすべてのステップへの入力となるのがステップ1です。

修正の自動化の4つの種類

アプローチ	内容	例	限界
依存関係アップデートボット	脆弱な依存関係を修正済みバージョンに上げるプルリクエストを作成	Dependabotのセキュリティアップデート、Renovate	リポジトリ内のマニフェストとロックファイルを起点に動作。破壊的なアップグレードでは、引き続き人がコードを調整する必要がある
SCAの修正プルリクエスト	商用SCAツールが挙げた検出結果について、アップグレードのプルリクエストを作成	Snyk、Black Duck、Aikido、Endor Labs	対応範囲はさまざま：直接の依存関係のみを修正するツールもあれば、パッチやバックポートを加えるツールもある
AIによるコード修正	検出結果（多くは静的解析のアラート）に対するコード変更を生成	GitHub Copilot Autofix	レビューが必要な非決定的な提案。AIによる修正を参照
インフラの自動修復	ルールが発動すると、設定ミスを元に戻したりホストにパッチを当てたりする	クラウドセキュリティポスチャ管理ツールやエンドポイントツール	対象は稼働中のインフラであり、出荷するソフトウェア内の依存関係ではない

最初の3つはいずれも出荷するコードを修正するもので、共通の前提を持っています。修正対象の脆弱なパッケージのリストが正しいという前提です。

すべての修正はインベントリに依存する

修正ツールが修正できるのは把握している脆弱性だけであり、把握しているのはインベントリに含まれる脆弱性だけです。ほとんどのインベントリは、マニフェスト、ロックファイル、インストール済みパッケージ、完成したコンテナイメージといったファイルから再構成されます。この再構成には、予測可能な形で漏れが生じます。

• ファイルに宣言されていないパッケージ。ビルドがダウンロードするツール、ベースイメージ、プラグイン、スクリプトでインストールされるものは、ロックファイルに一切現れないため、修正プルリクエストが作成されることもありません。
• ロックファイルと異なるバージョン。特にロックファイルがコミットされていない場合、ビルドはスキャナーが読み取るものとは異なるバージョンを解決することがあります。誤ったバージョンに基づく修正は、確信に満ちた誤答にすぎません。
• キャッシュから復元されたパッケージ。キャッシュされた依存関係はレジストリに再度アクセスしないため、ビルドが使ったものがリポジトリの記載より古いままになることがあります。

解決策は、ビルドが実際に使ったものを出発点にすることです。ビルド時SBOMはビルドの実行中に記録されるため、マニフェスト上で必要とされるものではなく、推移的依存関係を含めてジョブが取り込んだパッケージを記載します。そこから始めれば、実際に出荷するものを修正できます。

自動化すべきものと人に残すもの

修正をうまく機能させているチームの多くは、次のように役割を分けています。

• 検出と照合を自動化する。新しいアドバイザリは毎日公開されます。出荷済みのすべてのビルドを手作業で再確認していては追いつかず、これはまさにソフトウェアが得意とする作業です。
• 提案を自動化する。修正済みバージョンの選定と変更の作成は機械的な作業です。関連する更新をまとめ、レビュー担当者が20件ではなく1件のプルリクエストを見ればよいようにします。
• テストをマージの条件にする。テストスイートでカバーされているパッチレベルのセキュリティアップデートは自動マージします。破壊的なアップグレードやテストカバレッジのないものは、人に任せます。
• 判断は人に残す。脆弱性がそもそも自社製品に影響するのか、リスクのあるアップグレードを今週行う価値があるのかは、判断です。同じ問いを二度問わずに済むよう、たとえばVEXステートメントとして記録します。

修正ツールの評価方法

ツールにリポジトリでのプルリクエスト作成を任せる前に、次の点を確認してください。

1. 脆弱性リストはどこから得ているのか：リポジトリ内のファイル、スキャンしたイメージ、それともビルドそのものか？
2. 推移的依存関係を修正するのか、それとも宣言した直接の依存関係だけか？
3. 修正バージョンをどう選ぶのか：パッチ適用済みの最小バージョンか、最新版か、固定したバージョンか？
4. 修正は提示される前にビルドとテストが行われるのか、それともプルリクエストで初めて実行されるのか？
5. レビュー担当者に負担をかけないよう、更新をまとめたりスケジュールしたりできるか？
6. どのリリースが影響を受け、各修正がいつ出荷されたかを記録するか？

現在のCRACIの役割

CRACIはGitHub Actionsのジョブを独自のランナー上で実行し、推移的依存関係やキャッシュから復元されたパッケージを含め、各ジョブが実際に取得したパッケージを記録して、すべてのジョブに完全性の状態を付与します。この記録こそ、修正ワークフローの出発点となるべきインベントリです。

CRACIは監視対象のSBOMを継続的に再評価するため、新しいアドバイザリが公開されると、リポジトリをまたいで出荷済みのどのビルドが影響を受けるかがわかります。セキュリティチームは各検出結果をトリアージして修正を担当するチームに送り、CRACIはVEXに対応しているため、脆弱性が自社製品にどう影響するかを記録できます。次のビルドのSBOMで、ビルドが実際に使ったのが修正済みのバージョンかどうかがわかります。機能の全体像は脆弱性トラッキングのページをご覧ください。

EUのCyber Resilience Actのもとでは、メーカーはセキュリティアップデートの提供を含め、脆弱性に遅滞なく対処し修正しなければなりません。各ビルドに何が含まれ、各修正がいつ出荷されたかの記録は、そのプロセスに必要なエビデンスです。

脆弱性修正の自動化：よくあるご質問

脆弱性修正の自動化とは何ですか？

脆弱性修正の自動化とは、人が手間をかけずに脆弱性の検出結果を修正につなげるソフトウェアです。修正済みのバージョンを割り出し、マニフェスト、ロックファイル、コードを変更し、その変更を通常はプルリクエストとして提案します。何をマージするかは、引き続き人またはチームが信頼するポリシーが決めます。

脆弱性の修正と緩和の違いは何ですか？

修正は、たとえば修正済みバージョンへのアップグレードやパッチの適用によって、脆弱性を取り除くことです。緩和は、たとえば影響を受ける機能を無効にしたり攻撃経路を遮断したりして、脆弱性が残っている間のリスクを下げることです。緩和は時間を稼ぎ、修正は検出結果をクローズします。

脆弱性の修正は完全に自動化できますか？

一部は可能です。影響を受けるビルドの特定、アドバイザリの照合、バージョンアップの提案は機械的な作業であり、自動化に向いています。破壊的なアップグレードが安全か、脆弱性がそもそも自社製品に影響するかは、引き続き人が判断する必要があります。多くのチームは提案を自動化し、マージにはテストに裏付けられた人の判断を残しています。

Dependabotは脆弱性修正の自動化を行いますか？

Dependabotのセキュリティアップデートは、GitHubがリポジトリの依存関係グラフについて発するアラートを対象に、脆弱な依存関係をパッチ適用済みの最小バージョンに更新するプルリクエストを作成します。これは、マニフェストとロックファイルが宣言するものに対する修正の自動化です。宣言されたものと出荷されたものの違いについては、CRACIとDependabotの比較をご覧ください。

脆弱性修正ツールでは何を確認すべきですか？

脆弱性リストの出どころ、推移的依存関係に対応しているか、修正バージョンをどう選ぶか、修正が提示される前にビルドとテストが行われるか、そして何がいつ修正されたかを記録するかです。最後の点は、監査と、メーカーに脆弱性の遅滞ない修正を求めるCRAにとって重要です。