目次

• システム開発において進む生成AIの活用
• Webアプリケーション診断におけるAI活用の可能性
  • 動的アプリケーションを対象とするブラックボックス診断
  • ソースコードを対象とするホワイトボックス診断
  • 共通の課題
• 生成AIと脆弱性診断の方向性
• さいごに

システム開発において進む生成AIの活用

システムのセキュリティをどう確保するのか？

これは現在のシステム開発において大きな課題となっています。この課題に対処するため、セキュアな開発手法やセキュリティソリューションの導入、システム監視、セキュリティ研修の提供など、人やモノなどに対する複数の手法を組み合わせた多方面からのアプローチによるセキュリティ対策がとられています。

ここ数年においては、こうした取り組みにAIを活用して精度向上や効率化が図られてきました。特に、ChatGPTをはじめとした大規模言語モデル（以下、LLM：Large Language Models）の台頭により、自然言語を用いたAIへの指示が可能となったことで、AI活用のハードルは一気に下がりました。これまでは自動化や効率化が困難であった分野においてもAIの導入が進み、大きな効果が示されるようになってきています。

本記事では、このような中でも未だAIの利活用が限定的となっている、システムに潜在する脆弱性を検出するテスト、特にWebアプリケーションに対する脆弱性診断とAI活用の現状について取り上げます。

Webアプリケーション診断におけるAI活用の可能性

Webアプリケーション診断はその対象の違いにより、数種類の手法に区分されます。それぞれにメリット、デメリットがあり、実施するタイミングや目的によって使い分けられています。以下、代表的なWebアプリケーション診断手法における現状での生成AI活用について紹介します。

1．動的アプリケーションを対象とするブラックボックス診断

まずはWebアプリケーション診断の手法として比較的よく採用され、「ブラックボックス診断」と呼ばれる動的Webアプリケーション診断（以下、DAST：Dynamic Application Security Testing）についての現状を確認します。

DASTでは以下のようなツールが使用され、脆弱性の検出や評価、レポートの出力などを行うことができます。

例：DASTにて使用されるツール

• Burp Suite
• ZAP（旧OWASP ZAP）
• Nucleiなど

これらのツールを使用してWebアプリケーションに対して疑似的な攻撃を行い、LLMはその疑似攻撃の結果やレポートを解析。そこから修正案の提示や検出された脆弱性についての詳細な情報の提供を行うことが可能です。また、Burp Suiteの拡張機能として提供されているBurpGPTやReconAIzer（下図参照）を使用した場合、LLMとの連携による解析作業がサポートされます。

図1：Burp SuiteおよびReconAIzer

• BurpGPT
  https://burpgpt.app/
• ReconAIzer
  https://github.com/hisxo/ReconAIzer

しかしながら、DASTにLLMを使用する際には次のような留意事項があります。

• 疑似攻撃におけるリスク
  Webアプリケーション診断においては“疑似攻撃”と言われるように、可能な限り診断対象のシステムへ影響を与えずに脆弱性を検出できるよう予め検証したパターンが使用されます。しかし、LLMにより生成されるパターンには、診断対象システムに大きく影響を及ぼすものが出力されることがあります。
• パフォーマンスとコスト
  DASTは多量の通信が発生しますが、LLMを利用する際、その分の処理の遅延が発生します。また、外部のLLMサービスを使用する場合はその使用料もかかります。そのため、処理時間やコストなど全体のパフォーマンスについて事前の計画が重要となります。

2．ソースコードを対象とするホワイトボックス診断

ソースコードを対象に診断を実施する静的Webアプリケーション診断（以下、SAST：Static Application Security Testing、ホワイトボックス診断とも呼ばれる）のツールとしてLLMを利用することは、（制限はありますが）可能です（※1）。例えばLLMはプロンプトに次の例に示す情報を含め、「スニペットにセキュリティ上の問題がある場合は指摘してください」と指示することでソースコード内の脆弱性を探索することができます（下図参照）。

例：プロンプトに含める情報

• コードスニペット（脆弱性の確認対象となるソースコード）
• コードの仕様（どのような機能を実現するコードなのか、引数、戻り値の説明など）
• ソースコードに関する情報（言語、フレームワーク、ライブラリなど）
• 検出したい脆弱性（SQLインジェクション、XSS、またはCWEなど）
• 準拠すべきセキュリティポリシーや要件、規約
• 結果の出力形式（検出した脆弱性や行番号、解説などをJSON形式で出力など）

図2：LLMによる脆弱性の検出例

上図の例においてLLMはSQLインジェクションの問題を検出しました。最低限、コードスニペットとセキュリティの問題があるかの問いかけだけでもある程度検出してくれますが、より的確な回答を期待する場合は補足的な情報もプロンプトに含めることをおすすめします。

この方法にもいくつかの留意事項があります。

• トークンの制限とコンテキストの理解
  LLMは入力可能な文字数、回答の文字数に上限があり、この上限は使用するモデルなどにより差異があります。そのためプロジェクトのソースコード全てを一度に処理できるとは限りません。また、仮に全てを入力できたとしてもコードの文脈や技術仕様をLLMが完全に理解することは難しく、LLMの回答が正確ではない可能性があります。
• ウロボロス化
  LLMはソースコード上に脆弱性を検出した場合、（プロンプトによりますが）その脆弱性を修正したコードを提供してくれます。しかしそのコードがセキュアであるかは再度の確認が必要です。
  また、仮にソースコード内に複数の脆弱性が存在したとしてもLLMが一度に全ての脆弱性を検出するとは限らず、複数回の実行が必要となることもあります。

3．共通の課題

DAST、SASTにLLMを使用する場合、前述した留意事項以外にも次に挙げるような共通した課題があります。

• 機密情報の取り扱いとLLM実行環境
  DAST、SASTともに診断に関する情報は、取り扱いに注意を要するケースが多くあります。こうした情報を外部サービスに送信して解析を行う場合、その可否について事前確認が必須です（※2）。
• LLMのコンテンツポリシー
  LLMサービスでは各種の禁止事項があり、セキュリティに関するプロンプトは回答が制限される可能性があります。

他にもハルシネーション（幻覚）や情報が訓練時のものであるなど、通常のLLMの利用と同様の留意事項があり、LLMの回答については最終的に人による精査が必要です。

生成AIと脆弱性診断の方向性

Webアプリケーション診断のDASTとSASTにおけるLLMの利用についてみてきました。どちらの手法においてもLLMを利用するメリットがありますが、DASTにおいてはパフォーマンスやコスト、疑似攻撃のリスクが、SASTにおいては検出の精度や精査が課題であり、これらの理由から現在はLLMの利用は限定的です。

しかし、ローカルLLMの利用環境の整備が進み、関連ツールの開発も積極的に行われています。LLM自体の性能も日々向上しており、結果として、情報のプライバシーに配慮し、かつ、パフォーマンス的にも問題のない、生成AIを活用したWebアプリケーション診断環境が成熟しつつあります。

さいごに

生成AIやLLMの進化により、Webアプリケーション診断の実施はより容易に、効率的に行えるようになっています。従来は専門的な知見やノウハウを持つ第三者に依存していた診断業務も、LLMにより開発者自身が直接実施できるようになりつつあります。将来的には開発プロセスにこうした仕組みが組み込まれ、自動化されるでしょう。

よりセキュアなシステムの開発に寄与することが期待される一方で、今はまだシステム開発におけるセキュリティへのAI活用には専門的なノウハウが必要となります。これらについてお困りのことがあればぜひお声がけください。