重大な脆弱性が公表された直後、開発チームが直面するのは「どのシステムが影響を受けるのか」という調査です。対象が判明しても、DockerイメージやOSパッケージ、CI設定、Infrastructure as Code（IaC）などに修正箇所が散らばっていれば、本番反映までには相応の時間がかかります。Cognitionが公開した「Devin Vulnerability Fixes」は、この一連の作業をコーディングエージェントに実行させるためのプラグインです。



プラグインには、PHP、Node.js、セルフマネージド版GitLabを対象とする3種類のAgent Skillsが含まれます。Agent Skillsとは、エージェントが特定の作業を進める際の手順や判断基準を記述した仕組みです。今回はCognitionが社内で利用した修正ワークフローを、MITライセンスのオープンソースとしてまとめています。利用料金は無料です。

特徴は、単に脆弱なバージョンを指摘するだけではない点にあります。エージェントが対象環境を読み取り専用で調査し、人間の承認を得てから修正し、更新前後のテストを行い、リポジトリごとに1件のプルリクエストを作成します。対応するのはDevinだけではありません。SKILL.md形式を読み込めるClaude Code、Codex、Cursor、Factory Droid、GitHub Copilot、Gemini CLI、OpenCode、Windsurfでも動作すると案内されています。

実行にはgit、シェル、Docker、コンテナレジストリへのアクセスが必要です。npx経由で導入する場合はNode.js 22.20以降も求められます。なお、修正成功率や処理速度を示すベンチマークは公開されていません。企業が評価する際は、対応製品の多さよりも、自社のリポジトリ構成とテスト環境でどこまで確実に動作するかを確認する必要があるでしょう。

今回の対象はいずれも、条件がそろうと遠隔からコードを実行される恐れがあるRCE（Remote Code Execution）です。RCEが成立すると、攻撃者が対象システム上で意図しない処理を実行できる可能性があります。ただし、深刻度スコアが高くても、実際の危険性は公開範囲や構成によって変わるため、資産の棚卸しと影響確認が欠かせません。



PHP向けスキル「fix-php-vuln」は、「PHP2Shell」と呼ばれるCVE-2026-109618とCVE-2026-109619を扱います。PHPプロジェクトは両方をCVSS v4.0で9.2と評価しています。前者はメモリ不足が発生した後のメモリ破損、後者は前のリクエストに残ったグローバル状態が次のリクエストへ到達する問題です。WebサーバーとしてPHPを動かすすべての構成がリスク対象とされ、なかでもApacheにPHPを組み込むmod_phpは最も高いリスクと評価されています。修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12です。PHP 8.1以前には通常の修正版リリースがなく、7.4、8.0、8.1向けにはソースコードのバックポートだけが提供されます。

Node.js向けの「fix-node-vuln」は、2026年10月のセキュリティリリースで修正された10件のCVEを対象とします。このうち4件はHigh評価です。中心となるCVE-2026-111497は、Brotliデコーダーにおける境界外書き込みで、RCEにつながる可能性があります。修正版はNode.js 22.23.4、24.22.1、26.12.1です。Node.js 20以前はサポート終了のため、今回の修正を受け取れません。

GitLab向けの「fix-gitlab-vuln」が扱うCVE-2026-110264は、正規表現コンパイラの整数オーバーフローにより、認証を受けていない攻撃者がコードを実行できる問題です。GitLab Community EditionとEnterprise Editionのバージョン7.0以降に影響し、CVSSは上限値の10.0です。対象は自社管理のGitLabであり、GitLab.comとGitLab Dedicatedにはすでに修正が適用されています。この違いを見落とすと、修正が必要な環境とサービス側で対応済みの環境を混同しかねません。

三つのスキルは対象技術こそ異なりますが、作業の流れは共通しています。設計の軸になっているのは、AIエージェントに即座にファイルを変更させるのではなく、調査と承認を変更作業から切り離すことです。自動化の速度を活用しながら、人間が対象範囲とアップグレードのリスクを確認できる構成になっています。



最初の段階では、エージェントがDockerfile、ベースイメージ、Linuxディストリビューションのパッケージ、CI設定、Helm、Terraform、Packer、AWS Lambda、構成管理ファイルを読み取り専用で調査します。アプリケーションの依存関係だけでなく、実行環境を組み立てる複数のレイヤーを横断して対象を探す点が特徴です。この時点ではファイルを変更しません。

調査結果がまとまると承認ゲートに進み、利用者が修正対象のリポジトリを選択します。マイナー版やメジャー版の更新を伴うなど、影響が大きい変更は編集前に示されます。承認後も、指定されたタグ、イメージダイジェスト、パッケージバージョン、チェックサムをそのまま信用するのではなく、公式の提供元で確認してから変更する手順です。

テストは更新後だけでなく、現在のバージョンでも実施されます。続いて、新しい本番用イメージの内部で同じテストを動かし、差異を確認します。回帰が検出されれば処理は停止するため、「脆弱性が消えた代わりにアプリケーションが動かなくなった」という変更をそのまま出荷しないための歯止めになります。

最後に、リポジトリ単位で1件のプルリクエストを作成します。PRには変更前後のバージョン、テスト結果、実行環境の差分、リスクラベル、ロールバック計画が含まれます。自動化の成果を人間がレビューできる形へ変換することで、既存のコードレビューや承認プロセスへ接続しやすくしています。

脆弱性対応では、公式の修正版番号へ更新すれば作業が完了するとは限りません。Linuxディストリビューション、固定されたコンテナイメージ、アプリケーション側の設定が絡むと、見かけのバージョンと実際の修正状態にずれが生じます。Devin Vulnerability Fixesには、こうした実務上の落とし穴を避けるための判断ルールも組み込まれています。



代表例がDebianとUbuntuのバックポートです。両ディストリビューションでは、上流のソフトウェア全体を新しいバージョンへ置き換えず、必要なセキュリティ修正だけを既存パッケージへ取り込む場合があります。そのため、php -vが示す上流バージョンだけを見ても、修正済みかどうかを正しく判断できません。Ubuntu 24.04における今回の修正済みパッケージは、8.3.6-0ubuntu0.24.04.13とされています。エージェントは、このようなディストリビューション固有の情報まで確認する必要があります。

コンテナイメージをダイジェストで固定している場合も注意が必要です。タグだけを変更しても、古いイメージのダイジェストを参照し続ければ更新は反映されません。新しいイメージに対応するダイジェストへ置き換え、実際にビルドされる成果物を確認する作業が求められます。また、Composerのrequire.phpを書き換えても、実行中のPHPランタイムそのものは修正されません。アプリケーションが要求するPHPの条件と、サーバーやコンテナで動くPHP本体は別の管理対象だからです。

プラグインが修正できない範囲も明示されています。マネージドランタイム、アプライアンス、Electronアプリは検出対象にはなりますが、自動ではパッチされません。利用者側でサービス提供元の更新状況を確認したり、製品アップデートを適用したりする必要があります。

もう一つの制約はテスト品質です。更新前後のテストを自動化しても、テストされていない機能の不具合までは検出できません。修正率のベンチマークが公開されていないことも踏まえると、プラグインの導入とテストカバレッジの改善は別々に評価せず、セットで考えるべきでしょう。

自動修正という言葉だけを見ると、Dependabot、GitHub Copilot Autofix、Snyk Agent Fixと同じ種類の製品に見えるかもしれません。しかし、主な違いはAIの有無ではなく、どのレイヤーを修正するかにあります。Devin Vulnerability Fixesが中心に据えるのは、アプリケーションコードよりも、ベースイメージ、OSパッケージ、CI、Helm、Terraform、構成管理といった実行環境です。



Dependabot security updatesは、修正版が存在する脆弱な依存関係やGitHub Actionsを対象とし、有効化されていれば自動的にPRを作成します。主な編集箇所はマニフェストとロックファイルです。公開CIの実行結果を基にした互換性スコアも利用できます。GitHub上の依存関係を継続的に更新する用途には適していますが、今回のプラグインが扱うOSパッケージやインフラ設定とは焦点が異なります。

GitHub Copilot Autofixは、コードスキャンで検出されたアラートに対して、リポジトリ内のコード修正案を生成します。事前承認や検証方法の詳細は、今回確認できた比較情報では明らかにされていません。Snyk Agent FixはSnyk Codeの検出結果を基に、利用者が「Generate AI fix」を選んでローカルファイルの修正を生成し、Snyk Codeのエンジンで再検査します。複雑なファイル間ロジックには対応しないとされています。

費用と利用場所にも違いがあります。Devin Vulnerability FixesはMITライセンスで公開され、SKILL.mdを扱える複数のエージェントで実行できます。DependabotはGitHubの全リポジトリで利用可能です。Copilot Autofixは公開リポジトリでは無料ですが、非公開リポジトリではGitHub Code Securityが必要です。Snyk Agent FixにはSnyk Codeが必要で、価格は公開情報に記載されていません。

これらは完全な代替関係ではありません。依存ライブラリ、ソースコード、ランタイム基盤では、検出方法も変更箇所も異なります。企業では一つの製品に統一することを先に考えるより、既存ツールがカバーしていない層を確認し、Devin Vulnerability Fixesがその空白を埋めるかを見るほうが実践的です。

企業がこのプラグインを試す場合、最初から全リポジトリへ適用する必要はありません。対象となるPHP、Node.js、セルフマネージド版GitLabの利用状況を確認し、影響範囲が理解できる少数のリポジトリで読み取り専用の棚卸しを実行する方法が考えられます。調査結果と既存の資産台帳に差があれば、修正を始める前に、その差が生じた理由を確認したほうが安全です。



承認ゲートでは、単に「修正するか」を判断するだけでなく、変更対象、更新幅、テスト結果、ロールバック方法を誰が確認するかまで決めておく必要があります。セキュリティ担当者が脆弱性の優先順位を判断し、サービスオーナーが業務影響を確認し、運用担当者が本番反映と切り戻しを承認するといった役割分担が考えられます。ただし、具体的な分担は各社の開発体制に合わせるべきです。

エージェントにはシェル、Docker、レジストリへのアクセスが必要なため、実行権限の設計も導入条件になります。検証環境と本番環境を分離し、作業に必要な範囲だけへアクセスを絞ることが望まれます。生成されたPRについても、バージョン番号の変更だけでなく、ベースイメージの出所、ダイジェスト、CIの実行結果、実行環境の差分を確認するとよいでしょう。プラグインがPRを作成できることと、そのPRを無条件にマージしてよいことは同義ではありません。

導入効果を測る際は、AIが何件のファイルを書き換えたかよりも、対象資産を見つけるまでの時間、レビューに必要だった手戻り、テストで検出できた回帰、ロールバック可能な状態で変更を届けられた割合を見るほうが運用判断につながります。公開された修正率がない以上、自社環境での小規模な試行結果が重要な判断材料になります。

最初の一歩としては、三つの脆弱性に該当する可能性があるリポジトリを一つ選び、読み取り専用のインベントリ結果を人手の調査結果と照合するのが現実的です。そこで検出精度、必要権限、テストの不足を把握してから、修正とPR作成まで許可する範囲を広げれば、AIエージェントを既存の変更管理へ段階的に組み込めます。