AI
AIによる脆弱性修正：AIの修正プルリクエストでできること
脆弱性管理で時間がかかるのは、脆弱性を見つけることではありませんでした。修正を書き、破壊的なアップグレードにコードを合わせ、変更のレビューを通すことです。そこが今、AIの得意分野になっています。その修正が役立つかどうかは、何を修正するよう指示されるかにかかっています。
更新日
AIによる修正とは
AIによる脆弱性修正では、言語モデルを使って既知の脆弱性の修正を作成します。形は3つあります。
- コード修正の提案。モデルが静的解析アラートの横にパッチを提案します。たとえばGitHub Copilot Autofixは、「プルリクエストおよびデフォルトブランチで見つかったCodeQLアラートに対して、コード変更の提案を自動生成」します。
- コードを適合させる依存関係のアップグレード。バージョンを上げるのは簡単です。難しいのは、新しいバージョンがもたらす関数名の変更やデフォルト値の変更です。モデルはそうした付随する変更を同じプルリクエストで行えます。
- エージェント型の修正。エージェントが修正の複数のステップを自律的に進めます。コードを変更し、ビルドとテストを実行し、失敗内容を読んで再試行し、チェックが通ったときにだけプルリクエストを作成します。
AIの修正が真価を発揮する場面
ルールベースの更新ボットは、脆弱なパッケージを修正済みバージョンに上げるプルリクエストをすでに作成しています。しかし、アップグレードで何かが壊れると止まってしまいます。呼び出し側のコードを合わせる作業はルールにできないからです。バックログが積み上がるのはここです。メジャーバージョンの変更に取り組む時間が誰にもなく、セキュリティアップデートが何か月も開いたままになります。
変更履歴を読み、呼び出し箇所を見つけて書き換える作業は、言語モデルが得意とするものです。アップグレードとコード変更がそろい、ビルドとテストも済んだAIの修正が届けば、誰かが1週間かけていた作業がレビューだけで済みます。
AIの修正が失敗する場面
限界を最も明確に述べているのは、ベンダー自身です。Copilot Autofixについて、GitHubは次のように書いています。
- 「非決定的な生成モデルを使用しています。同じアラートとコードであっても、有効な提案を生成できない場合や、試行ごとに提案が異なる場合があります。」
- 「このシステムは、どの依存関係のバージョンがサポートされているか、安全かを把握しておらず、統計的にありそうな名前で公開された架空の依存関係を提案する可能性があります。」
2点目は仮定の話ではありません。コード生成モデルに関する研究では、存在しないパッケージがどれほどの頻度で推奨されるかが測定されています。そうした名前は攻撃者が登録してマルウェアを仕込めます。ハルシネーションで生まれたパッケージをインストールする修正は、ある脆弱性をより悪いものに置き換えることになります。
リスクの大半は、次の3つのガードレールで防げます。
- すべての修正をビルドしてテストする。人がレビューする前に行い、レビューの時間を機能する修正に充てます。
- 追加・変更されたすべてのパッケージを確認する。レジストリと、想定しているバージョンに照らして確認します。
- マージには人が関わる。AIの修正はコントリビューターのプルリクエストであり、決定ではありません。
入力が不正確なら、プルリクエストも不正確になる
AI修正ツールが修正するのは、与えられた脆弱性です。その一覧がロックファイルやスキャンしたイメージから再構成されたものであれば、再構成の欠落をすべて引き継ぎます。どのマニフェストにも宣言されていないのにビルドがダウンロードするツール、ビルドが解決したものと異なるバージョン、キャッシュから復元されたパッケージなどです。その結果、ツールは一部の脆弱性には自信満々にプルリクエストを作成し、ほかの脆弱性は知らないままになります。
さらに踏み込んで、依存関係そのものをモデルに推定させるチームもあります。そうするとインベントリまで非決定的になります。本来、プロセスの中で毎回同じ結果になるべき部分であるにもかかわらずです。推測したインベントリがエビデンスにならない理由は、AI生成のSBOMで解説しています。
うまくいくのは、土台に決定的なデータを置き、その上でAIが判断するパターンです。各ビルドに実際に含まれるものを記録した一覧を照合でアドバイザリと突き合わせ、修正はAIが書きます。
CRACIの役割
CRACIは決定的なレイヤーです。GitHub ActionsのジョブをCRACI独自のランナーで実行し、推移的依存関係やキャッシュから復元されたパッケージを含め、各ジョブが実際に取得したパッケージを記録し、ジョブごとに完全性の状態を示します。監視対象のSBOMを継続的に再評価するため、新しいアドバイザリは影響を受けるビルドに対して表示され、セキュリティチームは各検出結果をトリアージして、修正を担当するチームに送ります。
AIの修正が出発点とすべきなのはこの一覧です。修正がマージされた後は、次のビルドのSBOMで、修正済みバージョンが本当にビルドで使われたかを確認できます。機能の全体は脆弱性トラッキングを、それぞれのアプローチが適する場面はAIと決定的セキュリティの比較をご覧ください。
AIによる脆弱性修正：よくあるご質問
AIによる脆弱性修正とは何ですか？
AIによる脆弱性修正とは、言語モデルを使って脆弱性の修正を作成することです。静的解析の検出結果に対するコード変更や、依存関係のアップグレードとそれに必要なコード変更がこれにあたります。出力は通常、人がレビューするための提案またはプルリクエストです。
エージェント型の修正とは何ですか？
エージェント型の修正では、AIエージェントにツールを与え、修正の複数のステップを自律的に進めさせます。検出結果を読み、コードを変更し、ビルドとテストを実行し、通るまで繰り返してから、プルリクエストを作成します。一度きりの提案との違いは、人が目にする前にエージェントが自分の作業を検証する点です。
AIが生成したセキュリティ修正はマージしても安全ですか？
ほかのコントリビューターのプルリクエストと同じように扱ってください。GitHubはCopilot Autofixを非決定的なものと説明し、架空の依存関係を提案する可能性があると警告しています。変更をレビューし、テストを実行し、追加されたパッケージがすべて実在し、想定どおりのものであることを確認してください。
AIは依存関係の脆弱性を見つけられますか？
その部分には向いていないツールです。あるパッケージのバージョンが既知のアドバイザリの影響を受けるかどうかは照合の問題であり、毎回同じ結果になるべきです。脆弱なパッケージの一覧は、記録されたSBOMから決定的なツールで作成し、AIは判断が役立つ場面、つまり修正の作成と調整に使ってください。
AI修正ツールがうまく機能するには何が必要ですか？
実際に脆弱なものの正確な一覧、修正を検証できるビルドとテストスイート、そしてマージを判断する人です。最も欠けがちなのは一つ目です。製品が出荷していないパッケージに対する修正プルリクエストはノイズにすぎず、インベントリから漏れた脆弱なパッケージには修正が届きません。