10月19日、VeracodeのChief Security EvangelistであるChris Wysopalが「Why AI coding is widening the software security gap」と題した記事を公開した。AIコーディングアシスタントが生成するコードの44%に既知の脆弱性が含まれるという調査結果をもとに、開発速度の向上がセキュリティギャップをいかに拡大させているか、そして組織が取るべき具体的な対策について論じている。

AIが書いたコードの44%に既知の脆弱性

AIコーディングアシスタントはすでに実験的なツールではない。導入済みの組織では、コミットされたコードの約半分をAIが生成している段階にある。

問題はその品質だ。AIが生成するコードの構文的な正確さは99.9%のパス率を誇る一方、セキュリティの観点では話が大きく変わる。セキュリティテストの平均パス率は**わずか56%**であり、テストされたコード生成タスクの約44%が既知の脆弱性を含んでいる計算になる。

この結果、ソフトウェアの脆弱性はいまや侵害の入口として31%で首位となり、認証情報の窃取を上回るに至っている。

モデル選定はリスク管理の問題である

AIモデルは大量の公開コードから学習しているが、そのトレーニングデータには安全な実装だけでなく、古いライブラリ、脆弱な入力検証、安全でないコーディングパターンも含まれている。モデルはそうした安全でないパターンをスケールで再現してしまう可能性がある。

Wysopalが挙げるデータは具体的だ。テストした11モデルのうち、最も成績の良いモデルのセキュリティパス率は68%だったのに対し、6モデルは50〜53%の間に集中していた。つまりモデルの選定は、単なる生産性の問題ではなくリスク上の意思決定である。

ただし、より強力なモデルを選んでも、それだけで出力が信頼できるわけではない。SAST（静的アプリケーションセキュリティテスト）や強制力のあるセキュリティポリシーを用いて、ソフトウェア開発ライフサイクル（SDLC）全体を通じてテストを継続する必要がある。

脆弱性の種類によってパス率が大きく異なる

AIモデルのセキュリティ性能は脆弱性の種類によって大きくばらつく。この点が特にエンジニアにとって重要だ。

• **SQLインジェクション**：パス率83%
• 安全でない暗号アルゴリズム：パス率87%
• **クロスサイトスクリプティング（XSS）**：パス率15%
• ログインジェクション：パス率12%

SQLインジェクションのような脆弱性はコーディングパターンとして認識しやすいが、XSSやログインジェクションは話が異なる。これらはデータフロー、認可、トラストバウンダリー（※信頼できるコンポーネントと信頼できないコンポーネントの境界線。ユーザー入力がアプリケーション内部に渡る箇所などが典型例）、アプリケーション内のコンポーネント間の相互作用に依存するため、モデルが見落としやすい。

この非対称性が示すのは、アプリケーションのコンテキストを踏まえた検証が不可欠だという点だ。プルリクエストの段階でロジック上の欠陥や認証の不備を検出するAIネイティブな解析を、従来の静的解析と組み合わせることが推奨されている。

「発見数」ではなく「実害リスク」に絞って対処する

AIがコード生成の速度と量を引き上げると、セキュリティチームが評価・修正すべき脆弱性の量も比例して増大する。現状では82%の組織がセキュリティ負債を抱えており、60%の組織では重大なセキュリティ負債が存在している。

※セキュリティ負債とは、発見されているにもかかわらず未修正のまま積み残された脆弱性の累積を指す。技術的負債のセキュリティ版として捉えると理解しやすい。

すべての発見を均等に優先すれば状況は悪化するだけだ。Wysopalは、攻撃可能性、アプリケーションの重要度、ビジネスへの影響を軸に優先度をつけ、限られた対処リソースを本当に害をもたらしうる脆弱性に集中させるべきだと述べている。

AI支援による修正提案は発見から対処までのギャップを縮める手段になりえるが、生成された修正コードもテスト・検証・リグレッション確認（※修正によって既存の動作が壊れていないかを確認するテスト工程）が必要であることに変わりはない。

リーダーが今すぐやるべきこと

Wysopalはリーダー向けに以下の5つのアクションを提示している。

• AIが生成したコードの流入経路を把握する：どのチームがどのツールを使いどのリポジトリに書き込んでいるかを可視化することが出発点となる
• セキュリティ要件に基づいてモデルを評価する：生産性指標だけでなく、脆弱性カテゴリ別のパス率など定量的なセキュリティ基準で比較検討する
• 開発者のワークフローに検証プロセスを組み込む：セキュリティチェックをリリース後ではなくプルリクエスト段階に前倒しすることで、修正コストを下げられる
• 修正対象を「攻撃可能なビジネスリスク」に絞る：スコアの高い脆弱性をすべて潰すのではなく、実際に悪用されうるものに集中することがセキュリティ負債の現実的な解消につながる
• テスト済み・修正済み・許容済みのリスクに関するエビデンスを保持する：監査対応やコンプライアンス上の説明責任を果たすために、意思決定の記録を残しておくことが重要となる

AIの採用を遅らせることが答えではない。セキュリティがコード生成の速度に追いつけるよう、開発プラクティスそのものを進化させることが求められている。

詳細はWhy AI coding is widening the software security gapを参照していただきたい。