今回のブログでは、AIコーディングツールのセキュアな活用について考えるために、OWASPが公開している「OWASP Artificial Intelligence Security Verification Standard（AISVS）」のAppendix C「AI-Assisted Secure Coding」（以下、Appendix C）を紹介します。

はじめに

生成AIを活用したコーディングツールが普及し、AIを前提とした開発スタイルが定着してきました。同時に、AIを使った開発においてどのようにセキュアに行うかという新たな課題も生じています。

AIコーディングツール（以下、AIツール）は開発速度の向上に貢献する一方、従来の開発にはなかったリスクも持ち込みます。代表的なものは、プロンプトインジェクション（AIツールへの入力に不正な指示を混ぜ込み、意図しない動作をさせる攻撃）と、AIが生成したコードへの脆弱性の混入です。さらに、自律型AIコーディングエージェント（人間の承認を待たずにコード生成からデプロイまでを実行するAI）を使う場合は、エージェントが生成した成果物を自ら承認してしまう自己承認のリスクも加わります。プロンプトインジェクションの攻撃手法とテスト方法については過去のブログ記事[2]で、AIエージェント固有のリスク全般についてはブログ記事[3]でそれぞれ解説しています。

従来のセキュアコーディングでは、開発者自身が書いたコードをいかに安全にするかが主な関心事でした。AIツールを使う場合に大きく異なるのは、ツールへ与える指示文（プロンプト）そのものが攻撃経路になりうるという点です。さらに、GitHubなどのコード管理プラットフォーム上にあるPull Request（以下、PR）の説明やIssueの本文のように、AIが外部から取り込む情報（以下、外部コンテンツ）も攻撃経路になりえます。

AIツールは与えられた内容を忠実に解釈して動作するため、悪意ある指示が混入すると、開発者が気づかないまま問題のあるコードを生成したり、機密情報を出力したりします。AIツールは開発を支援する手段であると同時に、セキュリティリスクの観点から管理すべき対象でもあります。

こうした課題に対する標準として、OWASPが「Artificial Intelligence Security Verification Standard（AISVS）」[1]を公開しています。AISVSはAIシステム全般のセキュリティ検証を対象とした標準であり、アプリケーションセキュリティから機械学習モデルのリスクまで多岐にわたる内容を含んでいます。その中でAppendix C「AI-Assisted Secure Coding」は、開発現場でのAIツールの利用に特化した実践的なコントロール集です。本ブログではOWASP AISVSの中からこのAppendix Cに焦点を絞り、AIツールを安全に利用するために開発者が特に意識したいコントロールを紹介します。

OWASP AISVS Appendix C「AI-Assisted Secure Coding」とは

AISVSは全12章で構成されており、プロンプトインジェクション対策、モデルの安全性、学習データのガバナンス、エージェントのアクセス制御といったコントロールが章ごとにまとめられています。開発者やアーキテクト、セキュリティ担当者が、AIシステムのセキュリティを確認するためのチェックリストとして活用できます。

Appendix Cは、AIツールを安全に活用するために組織が実施すべきコントロールをまとめた付録です。本体の各章がAIシステムを作る側や提供する側の視点を中心としているのに対して、こちらは開発の現場で日常的に参照しやすい実践的な内容になっています。

Appendix Cは14件のコントロールで構成されています。各コントロールには複数の要件が割り当てられており、それぞれの要件に検証レベル（Level 1〜3）が設定されています。Level 1が基本的な対策、Level 3がより高度な対策を示しており、組織の成熟度に合わせて段階的に取り組める構成です。各コントロールの概要を表1に示します（要件ごとのレベルは原文を参照してください）。

本ブログで取り上げる5つのコントロール

本章では、Appendix Cの14件のコントロールのうち、AIエージェントを用いた開発で特に意識したい次の5件を取り上げます。

• プロンプトとコンテキストの保護（AC.3）
• AIが生成したコードの検証（AC.4）
• 自律型AIエージェントの変更管理制約（AC.8）
• AIコードレビューボットの強化（AC.11）
• AIを考慮したCI/CDパイプラインの強化（AC.12）

選定の軸としたのは、AIの導入によって新たに生じた、あるいは影響が大きくなった次の4つのリスクです。これらは、Appendix Cのワークフロー文書整備コントロール（AC.1）の要件AC.1.3に列挙されている脅威シナリオと、AC.4の目的に挙げられているリスクを参考にしています。

• プロンプトインジェクションによるツールの乗っ取り
• AI生成コードへの脆弱性混入
• 自律型AIエージェントの自己承認
• CI/CDパイプラインの設定の不備を突く攻撃

各リスクと対応するコントロールの関係を表2に示します。

残りの9件のコントロールにも、AIツールを用いた開発で重要になる内容が含まれています。詳細は原文[1]を参照してください。

プロンプトとコンテキストの保護（AC.3）

AC.3でいうコンテキストとは、AIツールが回答を組み立てる際に参照する情報全般（プロンプト本文に加え、リポジトリのファイルやPR・Issueの記述など）を指します。このコントロールは、プロンプトへの機密情報の混入防止と外部コンテンツによるプロンプトインジェクション対策の2つを目的としています。

1つ目の機密情報の混入防止について、Appendix Cでは主に次の点が求められています。

• シークレット（APIキーやトークンなどの秘密情報）や個人情報をAIツールへのプロンプトに含めることを規程で禁止する（Level 1）
• この禁止をプリコミットフックやIDE（統合開発環境）連携、CIといった複数の仕組みで技術的に強制する（Level 1）
• プロンプトとして送信する前に機密情報を自動でマスキングする（Level 1）

2つ目のプロンプトインジェクション対策で求められているのは、主に次の点です。

• 外部コンテンツをすべて信頼できない入力として扱い、プロンプトに含める前にスクリーニングする（Level 1）
• システムメッセージや開発者メッセージがリポジトリのコンテンツより優先されることを確認する（Level 1）
• 長大な入力によってシステム指示が実質的に上書きされるコンテキストオーバーフロー攻撃の対策を講じる（Level 2）

ここでいう外部コンテンツとは、PRの説明やコメント、Issueの本文、コミットメッセージ、MCP（Model Context Protocol）ツールの出力などです。MCPとは、AIツールに外部のデータや機能を接続するための規格です。
AC.3の概要を図1に示します。機密情報の混入防止とプロンプトインジェクション対策は守る対象が異なるため、経路を分けて描いています。

実務で難しいのは、禁止事項を規程に書くだけでは守られないという点です。開発者は目の前の不具合を直すために、エラーログや設定ファイルをそのままプロンプトに貼り付けます。そこにシークレットが含まれていても、悪意はありません。AC.3が規程による禁止に加えて自動マスキングやコミット前の検査まで求めているのは、この悪意のない持ち込みを止めるためです。

AIが生成したコードの検証（AC.4）

AIが生成したコードを、マージやデプロイの前に検証することを定めたコントロールです。人間によるレビューと自動セキュリティスキャンの両方を求めています。

具体的には、主に次の点が求められています。

• AI生成コードは、生成を依頼した担当者とは別の人間がレビューする（Level 1）
• 自律型AIエージェントによる自己承認を技術的に防止する（Level 1）
• AI生成コードを含むPRには、SASTやDAST、SCAなどの自動スキャンを実行する（Level 2）
• 重大なセキュリティ上の問題が検出された場合は、マージをブロックする（Level 2）
• 認証や認可の処理、ID・アクセス管理ポリシー、CI/CDワークフロー定義といった重要なファイルをAIが生成または変更した場合には、2人によるレビューやセキュリティチームの承認を必要とする（Level 2）

AC.4の主要な検証フローを図2に示します。人間のレビュー、重要ファイルの追加承認、自動スキャンは、いずれもマージより手前に置きます。

AI生成コードは、一見正常に動いているように見えても、特定の条件下でセキュリティ上の問題が生じることがあります。また、大量に自動生成されたコードを人間が行単位で意図を把握しながらレビューするのは現実的ではありません。そのため、AC.4ではレビューを個人の努力に任せず、自動スキャンとマージブロック、重要ファイルの追加承認という形で仕組みに落とし込むことを求めています。

自律型AIエージェントの変更管理制約（AC.8）

コードの生成からコミット、デプロイまでをAIエージェントに任せると、人間が一度も間に入らないまま、変更が本番環境まで到達する経路ができます。AC.8は、こうした自律型AIエージェントにも人間と同様の職務分離（1人の担当者が作業と承認の両方を行えないようにする原則）を適用することを求めています。

そのための制約として、主に次の点が挙げられています。

• 自身が生成した成果物の承認・マージ・署名・デプロイを行わせないよう、ソースコード管理やCI、アーティファクトレジストリ（ビルドしたイメージやライブラリなどの成果物を保管・配布するシステム）の設定で制限する（Level 1）
• AIエージェントには専用のサービスアカウントを割り当て、権限を必要最小限に絞る（Level 2）
• 自身が生成した成果物を他の環境へ移せないよう制限する（Level 2）
• コードのマージに対する保護設定（特定のブランチへ直接変更を加えることの禁止、マージ時のレビューの必須化など）をエージェントが変更しようとした場合に、セキュリティアラートを発生させる（Level 2）

AC.8の概要を図3に示します。AIエージェントが担当する範囲と人間が担当する範囲を分け、その境界を設定によって担保します。

人間の開発者が自分のコードをマージしたりデプロイしたりする場合でも、少なくとも誰が何を承認したかは記録に残ります。自律型AIエージェントが生成から承認、デプロイまでを自動で完結させると、人間による承認の記録が残らないまま成果物が本番環境に反映されます。さらに、エージェントは与えられた権限の範囲で動くだけなので、「自己承認は禁止」と規程に書いても、それだけではこの経路は塞がりません。AC.8が技術的な制限を求めているのはこのためです。

AIコードレビューボットの強化（AC.11）

AIコードレビューボットやPRコメントボット、MCPを利用するAIアシスタントやIDEのコーディング支援機能など、リポジトリのコンテンツにアクセスするAIアシスタント全般を対象としたコントロールです（以下、まとめてボットと呼びます）。ボットがPRレビューを自動で行う場合、PRの説明やコメントに埋め込まれたプロンプトインジェクションによって、ボット自体が攻撃の踏み台にされるリスクがあります。

Appendix Cでは、ボットについて主に次の点が求められています。

• PRの差分や説明、コメントなどPR由来のコンテンツをすべて信頼できない入力として扱い、プロンプトインジェクション対策を適用する（Level 1）
• ボットのシステムプロンプトや設定は署名やハッシュで固定し、PRのコードやコメントなどリポジトリ上のコンテンツによって書き換えられないよう保護する（Level 1）
• 承認やマージといった特権アクションには、LLMとは独立したアクセス制御の仕組みによる認可を必須とする（Level 2）

AC.11の概要を図4に示します。入力側の防御、ボット設定の保護、特権アクションの認可は、それぞれ別の仕組みで担保します。

PRの説明やコメントに悪意のある指示を埋め込めば、ボットに承認させたり、外部へ情報を流出させたりできます。攻撃者が用意するのはテキストだけです。つまり、ボットを導入した瞬間から、誰でも書き込めるPRの本文がリポジトリを操作できる権限とつながることになります。

AIを考慮したCI/CDパイプラインの強化（AC.12）

AIエージェントがCI/CDパイプラインと連携する際のコントロールです。AIの導入でパイプラインの自動化が進むほど、セキュリティ設定の不備が攻撃経路になるリスクも大きくなります。

Appendix Cが求めているのは、主に次の点です。

• 外部からのPRを処理する際、シークレットや書き込み権限が外部のコードに露出しない構成にする（Level 1）
• AIが生成・変更したCI/CDワークフローファイルをセキュリティレビューの対象とする（Level 2）
• そのレビューをエージェント自身がバイパスできないよう権限を設定する（Level 2）

エージェントが自動でPRを作成・処理する場合、この構成に不備があると、シークレットが漏洩するおそれがあります。
AC.12の概要を図5に示します。パイプラインへの入口が2つあり、必要な設定もそれぞれ異なります。

外部からのPRを処理する際にシークレットを保護する設定は、AIコーディングが普及する以前からある対策です。変わったのは、その不備を突く試みの規模です。攻撃者がAIを使って大量のPRを自動生成すれば、多数のリポジトリを次々に狙えます。加えて、AIエージェント自身がCI/CDワークフローを生成・変更する場面では、バイパス権限を与える記述を誤って書き込むリスクもあります。

まとめ

本ブログでは、OWASP AISVSのAppendix Cを紹介しました。また、そのコントロールのうち、AIエージェントを用いた開発と関わりの深い5件について概要を見てきました。
AIコーディングツールは開発を助ける道具であると同時に、攻撃者に狙われる対象でもあります。プロンプトインジェクションや自律型AIエージェントの自己承認といったリスクは、既存のセキュアコーディング知識をそのまま応用しても対処できません。
AIコーディングツールを使い始めている方、これから導入を検討している方は、ぜひ一度OWASP AISVSのAppendix Cを参照して、自身の開発プロセスで不足している対策を確認してみてください。

参考文献

[1] OWASP Artificial Intelligence Security Verification Standard AISVS Docs | OWASP Foundation
https://owasp.org/www-project-artificial-intelligence-security-verification-standard-aisvs-docs/

[2] OWASP AI Testing Guide から学ぶ、AIアプリケーションのプロンプトインジェクションテスト | NECセキュリティブログ
https://group.nec/jp/ja/solutions/cybersecurity/blog/260515

[3] OWASP Top 10 for Agentic Applications から学ぶ、AIエージェントに潜むセキュリティリスクと対策について | NECセキュリティブログ
https://group.nec/jp/ja/solutions/cybersecurity/blog/260724

執筆者プロフィール

浦川　侑之介（うらかわ　ゆうのすけ）
担当領域：セキュア技術開発
専門分野：セキュア開発、DevSecOps

NECグループ社内向けのセキュリティ関連サービスの開発に従事。
CISSP、CCSP、CISA、CISM、GIAC(GCSA、GWAPT)、情報処理安全確保支援士(RISS)を保持。