従来、監査とは記録・プロセス・統制を独立した立場から検証し、コンプライアンス遵守状況や財務・運用面の健全性を評価する作業でした。
現代においては、こうしたアプローチをソフトウェア開発ライフサイクル(SDLC)にも広げる必要があります。特に、人工知能(AI)や大規模言語モデル(LLM)を活用したコード生成が普及した今、その重要性は増しています。CISO(最高情報セキュリティ責任者)とそのチームには、開発者たちが安全な製品を生み出していることを証明できる材料が求められています。というのも、組織の5社に1社がAI生成コードに直接起因する深刻なセキュリティインシデントを経験しているからです。問題の根本にたどり着くには、誰がAIを利用しているのか、どのツールが使われているのか、そしてSDLCのどの段階でAI生成コードが組み込まれているのかを可視化する必要があります。これは「ADLC(エージェント型開発ライフサイクル)」と呼ばれる考え方です。
CISOには、これらのツールが承認済みで安全なものであるという確信が求められます。徹底した監査を行えば、AIに関連する具体的な脆弱性や、最も問題を引き起こしているツールを特定できます。さらに望ましいのは、その情報を実際のアクションへとつなげることです。
誤解のないよう明確にしておくと、AI/LLM主導のソフトウェア開発は効率性と生産性全体を大きく押し上げます。しかしその一方で、新たな、しばしば管理の行き届かないリスクも生み出します。「事後」に発見されるソフトウェアの脆弱性は、時間のかかる修正と手戻りを招きます。セキュリティチームと開発チームのリーダーは協力し、有効性・イノベーション・保護のバランスを適切に見極める必要があります。
効果的な監査は、AIが本番コードにどのような影響を及ぼしているかを企業レベルで可視化するところから始まります。しかし、こうした可視性を確保することは依然として容易ではありません。個々の開発者は日常業務において自分の好みのLLMツールを使っていますが、これらのツールはセキュリティの習熟度がまったく異なる水準で運用されていることが多く、CISOが定量化されたリスクを関係者に報告することも、チームがガバナンスポリシーを徹底することも、極めて難しくなっています。
こうした取り組みが重要であることは、私たちの調査結果からも裏付けられています。特定のセキュリティタスクにおいて人間と機械を比較したところ、成果にはばらつきが見られました。最も優れたLLMでさえ、コードスメル(構造上・設計上の問題)やアンチパターン(一般的だが有害な解決策)の指摘といった、限られた範囲の安全なコーディングタスクにおいてのみ、熟練したプロフェッショナルに匹敵する水準の成果を示しました。一方で、DoS対策やログ記録の不足、権限設定の誤りといった項目では、ツールが苦戦する場面も確認されています。全体として見れば、セキュリティに精通したトップクラスの開発者はLLMを上回る成果を出しますが、平均的な開発者はそこまでには至りません。
新たなリスクの発生源
実際のところ、AIブームは新たなカテゴリーの運用リスクを生み出したと言って差し支えありません。それは外部の攻撃者ではなく、SDLCの内部から生じるリスクです。その結果、CISOたちは、開発者の意図しない行動に起因する可視性のギャップに、これまで以上に直面するようになっています。しかも、それはただでさえ責任の所在や帰属をたどることが難しい状況下で起きているのです。
関係者に定量化されたリスクをきちんと報告するためには、SDLCに対するAIの影響を包括的に監査し、次のような要素を組み込む必要があります。
AIの導入状況。 誰がAIツールを使用しているのか。どのくらいの頻度で。どこで使われているのか。
開発者のスキル。 LLMが持ち込んだ不正確な点や脆弱性を見抜き、排除できるだけの力量を備えたメンバーは誰か。逆に、そのためのスキルアップが必要なのは誰か。
脆弱性評価。 問題が発生したのはどの段階か。その被害はどれほど深刻だったか。
これらを踏まえることで、CISOは取締役会レベルで求められる監査に関する重要な問いに答えられるようになります。すなわち、AIはどこでリスクを高めているのか。どのチームや行動がそのリスクを生み出しているのか。各チームはAI/LLMを日常的に活用するにふさわしいスキルを備えているのか、といった問いです。
ここに到達するために、CISOは開発チームのリーダーと緊密に連携しながら、効果的な監査を実現する次の段階を踏む必要があります。
ツール利用状況の記録。 承認済みか否かを問わず、コード生成に使用されているすべてのAI/LLMアシスタントについて、検証可能な記録をまとめます。そして、それらを実際のコード出力に直接紐づけます。こうしたステップを踏むことで、CISOは監査・コンプライアンス対応の準備を整えるとともに、新たに求められつつある規制上の指針を満たすために必要なトレーサビリティを確保できます。
ツールの評価・ベンチマークと修正。 既知の脆弱性パターンに照らしてAIモデルを評価し、安全な製品を生み出すモデルを標準として採用します。これを踏まえて、承認するツールの選定と適切なガバナンスを決定します。また、MCP(モデルコンテキストプロトコル)連携を追跡・監督し、AIエージェントが承認済みのツールやデータソースのみに接続するようにします。さらに、「タイムトラベル」監査を活用すれば、侵害されたLLMモデルに関連するすべてのコミットを即座に特定・修正でき、時間のかかる手作業でのコードレビューに伴う過剰なコストを避けられます。
スキルアップへの投資。 継続的な教育やベンチマークにとどまらず、組織はリスクスコアを設けるべきです。これは信用スコアに似た仕組みですが、開発チームのメンバーが持つスキルセット、業務の進め方、監督能力といった複数の要素を踏まえ、意図せず生じるリスクの大きさを測る点が異なります。
AIと事業目標の結びつけ。 監査から得られる知見は、AIツールの導入を生産性・コード品質・安全な成果と結びつけるものでなければなりません。これにより、意思決定者はどのツールに投資すべきか、そしてイノベーションとリスク管理のバランスをどう取るべきかを判断する材料が得られます。
幸いなことに、現在すぐに利用できるソリューションを使えば、CISOや開発チームのリーダーは可視性を高め、リスクを特定し、AIとSDLCに関するポリシーに基づいたトレーニングやガバナンスを促すことができます。そして、そのすべては包括的な監査から始まり、最終的には適切な人材が適切なツールを使う体制、すなわちAIに過度に頼りすぎない体制の実現へとつながります。こうした取り組みを続けることで、SDLCは革新的かつ生産的であると同時に、安全なものになっていくはずです。
詳細はこちら AI Risk Summit | Ritz-Carlton, Half Moon Bay
翻訳元: https://www.securityweek.com/how-to-conduct-a-successful-audit-of-ai-driven-software-development/
