SWEADV、悪意ある issue で修復エージェントを誘導：半数超が機能を修正しながら脆弱性を混入

自動プログラム修復エージェントの成功は通常、テストに合格したかどうかで評価される。しかし、新たな研究 SWEADV は、攻撃者がエージェントによる issue 記述への信頼を悪用し、「bug の修正」と「脆弱性の混入」を同時に成立させられることを示した。研究チームは SWE-bench Verified から実際の修復タスク150件を選び、各タスクについて、コマンド実行、安全でないデシリアライゼーション、パストラバーサル、サービス拒否（DoS）、脆弱なハッシュの5種類を誘発する敵対的な記述を作成し、合計750件のケースを構築した。

実験には mini_swe エージェントを使用し、バックエンドには GPT-5-Mini、MiniMax-M2.5、DeepSeek-R を採用した。論文によると、エージェントは平均51.7%のケースで、既存の機能テストに合格すると同時に、攻撃者の狙いに沿った挙動を生成した。これは、regression test やタスク完了率を確認するだけでは、patch が攻撃対象領域を拡大したかどうかを判断できないことを意味する。悪意ある要件は、バックドアの追加を直接求める必要さえない。一見もっともらしく見えるものの、修復方針を危険な実装へ誘導する再現手順を提示するだけでよい。

既存の防御策も効果は限定的だった。修復前に LLM で issue が悪意あるものかを判定した場合、平均精度は62.3%だった。修復後の静的解析による検出精度はわずか39.4%、LLM reviewer は55.4%にとどまった。エンジニアリングチームにとって、これは信頼できない issue の内容をサプライチェーンへの入力として扱うべきことを示している。エージェントは隔離環境で動作させ、patch にはデータフローと権限変更の検査を必須とし、自動マージや CI credential の使用も制限する必要がある。

ただし、SWEADV は既存タスクから合成された敵対的ベンチマークであり、検証対象も1種類のエージェントフレームワークと3種類のモデルバックエンドに限られている。検出率も、ルール、静的解析ツール、プロンプト設計の影響を受ける。今後は、データセットと生成プロセスが完全に公開されるか、ほかの coding agent でも結果を再現できるか、さらにプロジェクト固有の脅威モデルを導入することで攻撃成功率を大幅に低減できるかを検証する必要がある。