AIが生成するコードは、今や日々のソフトウェア開発に欠かせない存在になっています。開発者はプロトタイピングやリファクタリング、トラブルシューティングなど、これまでにない手軽さでアイデアを実装へと落とし込むためにAIを活用しています。その生産性向上の効果は疑いようがありません。しかしそれゆえに、セキュリティ責任者は今、難しい問いに直面しています。組織が同じスピードでAIが生み出すリスクを統制できるのか、という問いです。
この課題の根底にあるのは「規模」の問題です。AIはソフトウェアが作られる速度を一変させましたが、多くのアプリケーションセキュリティプログラムは、いまだにより緩やかな開発モデルを前提に設計された統制に依存しています。コード生成のスピードがレビューやテスト、問題修正の処理能力を上回ると、セキュリティ負債は加速度的に積み上がっていきます。
これがAI支援開発の見えにくいコストです。リスクは今や機械的な速度で企業に流れ込んでくる一方、多くの組織はいまだに人間の作業速度を前提としたプロセスでそれを管理しています。CISOは、AIが生成したコードを高リスクの入力として扱い、自動テストにかけ、安全でない依存関係がないか確認し、迅速に修正を行い、ポリシーに違反する場合は本番環境への反映をブロックするべきです。
重要な指標は「リスクの伝播速度」
アプリケーションセキュリティは長らく「発見」を基準に測られてきました。チームは脆弱性の数を数え、深刻度を分類し、傾向を報告し、数値が改善しているかどうかを示してきました。これらの指標が今も重要であることに変わりはありませんが、AIはより差し迫った指標を加えました。それが「リスクの伝播速度」です。セキュリティ責任者は、組織がどれほどの速さで新たなソフトウェアリスクを生み出しているか、そしてそれをどれほどの速さで低減・排除できるかを把握する必要があります。
AIはセキュリティ負債の経済性を変えてしまいました。セキュリティ対応力を見合った形で拡充しないまま大幅にコード生産量を増やす開発チームは、合理的にレビュー・修正できる範囲を超える問題を生み出すことになります。AIが生成したコードが1行あたりで見れば人間が書いたコードと同程度の品質であったとしても、変更量そのものが多いためリスクの総量は増大し得ます。バックログは膨れ上がり、脆弱性は放置されたままとなり、やがてセキュリティ負債が事業の足かせとなっていきます。
AIは、おなじみの失敗パターンを拡大する
失敗のパターン自体は目新しいものではありません。AIコーディングツールは、学習データに含まれる安全でないパターン、例えば脆弱な入力検証、安全でない認証フロー、安全でない直接オブジェクト参照、ハードコードされたシークレット、脆弱な依存関係の選択などを再現してしまうことがあります。また、特定の環境においてそのコードが本当に安全かどうかを左右する文脈、すなわち認可モデルやテナント境界、データの機微性、本番環境の設定、実際のアプリケーションにおけるサービス間の連携といった要素を見落とすこともあります。
人間側の要因もあります。納期のプレッシャーにさらされる中で、開発者は動作するコードを、その仕組みを十分理解しないまま受け入れてしまうことがあります。その結果生まれるのが、誤った安心感です。コードはコンパイルされ、テストは通り、機能はリリースされますが、その裏では見えないリスクがシステムに入り込んでいきます。時間の経過とともに、組織は手作業による開発で自然と意識されていたセキュリティ上の懸念を見失ってしまう可能性があります。
サプライチェーンリスクは、コードそのものより大きい
ソフトウェアサプライチェーンは、さらにもう一つのリスク層を加えます。現代のアプリケーションは、オープンソースのコンポーネント、フレームワーク、プラグイン、コンテナ、API、クラウドサービスを組み合わせて構築されています。AIコーディングツールは、古いパッケージや脆弱なライブラリ、あるいは実在しない依存関係を推奨してしまうことがあります。Veracodeの「2025年GenAIコードセキュリティレポート」によると、AIコーディングツールが安全でないコードを生成する割合はほぼ半数(45%)に上ります。これは滑稽なハルシネーション(幻覚)として片付けられそうに聞こえるかもしれませんが、攻撃者が似た名前の悪意あるパッケージを登録し、開発者や自動化ツールがそれを取り込むのを待ち構えているケースもあります。そうなれば、単なるコーディングの近道がサプライチェーン上の露出点に変わってしまいます。
AIはすでに開発ライフサイクルの一部となっており、その活用はこれからも広がり続けます。セキュリティチームには、この現実に即した統制モデルが必要です。
「シフトレフト」には強制力のあるレイヤーが必要
この業界はこの10年余りをかけて、開発ライフサイクルのより早い段階にセキュリティを組み込む取り組みを進め、可視性を高め、チームがより早く問題を発見できるようにしてきました。しかし多くの組織は、発見結果を開発者に近づける一方で、それに見合うだけのオーナーシップや自動化、修正対応力までは十分に移していませんでした。開発者はより多くのアラートを受け取るようになった一方、セキュリティチームはリスクへの可視性は高まったものの、それを低減すること自体には依然として苦労している、という状況が生まれました。
AIは、この運用面のギャップをより一層切迫したものにしています。ソフトウェアの生産量が増加するにつれ、セキュリティはもはやプロセスの終盤に置かれたチェックポイントであり続けるわけにはいきません。ソフトウェアが作られ、テストされ、承認され、デプロイされる過程そのものに組み込まれた、継続的な統制システムへと変わる必要があります。
「セキュア・バイ・デザイン」はインフラの一部にならなければならない
AI時代におけるセキュア・バイ・デザインには、安全でない選択がしにくく、かつ見つけやすいエンジニアリング環境が求められます。承認済みのフレームワーク、安全なデフォルト設定、リファレンスアーキテクチャ、依存関係の統制、自動テスト、ポリシーの強制執行は、開発者のワークフローやCI/CDパイプラインに直接組み込まれるべきものです。
修正対応もまた、コードが生み出される地点により近い場所へと移す必要があります。コーディングアシスタントが脆弱なパターンを持ち込んでしまった場合、理想的な対応は、通常の開発プロセスの一環としてインラインの修正案が提示され、検証され、統制されることです。信頼できるセキュリティシグナルやポリシーの文脈、実際のテストによる裏付けと結びついていれば、AIはこの場面で防御側の大きな助けになり得ます。しかし直感に反するようですが、コード作成にAIを使う開発者の多くは、人間によるレビューなしにAIがコードを自動修正することまでは信頼していません。これは、機械的な速度で生まれる脆弱性に追いつくための最良の手段の一つを、人間の速度にまで引き戻してしまうことを意味します。リスクとスピードの間で、許容できるバランスを見出す必要があります。
「承認」は「ガバナンス」ではない
CISOは、単にAIコーディングツールを承認するだけでなく、ガバナンスそのものに目を向けるべきです。ガバナンスとは、AIが生成したコードが自組織の環境のどこから入ってくるのかを追跡し、適用したポリシーやテストを文書化し、発見・修正した問題を記録し、これらの判断の証跡を保持することを意味します。AI支援開発が標準となるにつれ、こうした文書化は決定的に重要になっていきます。もし脆弱なコードが本番環境に到達してしまった場合には、十分な統制が講じられており、リスクがポリシーに従って管理されていたことを示す必要があるからです。
リーダーが今すべきこと
CISOやエンジニアリング部門のリーダーは、AIが生成したコードを、その安全性が証明されるまでは「信頼できないもの」として扱うべきです。リリース前の自動テストを義務付け、依存関係の統制を徹底し、悪用可能性とビジネスへの影響度に基づいて修正の優先順位を付け、重大なリスクをどれだけの速さで低減できたかによって成果を測る必要があります。
加えて、取締役会や組織の政策決定者は、AI支援によって作られたソフトウェアがデプロイされる前にきちんとガバナンスされていることを組織が示せるかどうかを問うべきです。その際の重要な証拠となるのは、適用されたポリシー、実施されたテスト、修正された脆弱性、受容されたリスク、そして記録された承認です。現状、多くの組織は自社のAIツールが何を生み出しているかは自信を持って追跡できていますが、その成果物が本番環境に到達するまでにどのように保護され、レビューされ、統制されたのかを示すことはできていません。業界全体として、このギャップを埋める取り組みが今なお続いています。
AIは、ソフトウェアリスクが企業内を伝わる速度そのものを変えつつあります。この変化を乗り越える組織とは、ガバナンスと修正対応、そしてその証跡をソフトウェア提供パイプラインに直接組み込むことで、セキュリティ対応を同じ速さで動かせるようにした組織です。
翻訳元: https://cyberscoop.com/governing-ai-code-security-risks-op-ed/
