AIを安全に活用して開発するためのベストプラクティス10選

Play Video: 10 BEST Practices for Securely Developing with AI

今や、AIが開発者のアプリケーション開発を強化するうえで、欠かせないツールとなり、避けて通れない存在になったことは誰もが痛感しています。組織が開発者によるAIツールの利用を制限していても、VPNや個人アカウントを使って回避しているという話をよく耳にします。

AI技術に慣れ、受け入れるまでにどれほど時間がかかるとしても、AIを安全に利用することが欠かせません。この記事では、AI支援アプリケーションやAI支援開発に加え、AIを活用した生産性の高いソフトウェア開発のための一般的なヒントを取り上げ、安全なAI開発のベストプラクティスをご紹介します。開発者とセキュリティ担当者が、AIのメリットを最大限に活用しながら、潜在的なリスクを効果的に軽減できるようにすることが目的です。

まずは、すべてのヒントを1ページにまとめたチートシートをご覧ください。印刷してワークステーションの横に置いたり、冷蔵庫に貼ったり、年末年始や誕生日、お見舞いのカード代わりに誰かに贈ったりしましょう。どういたしまして！

チートシートをクリックしてPDFをダウンロード

AI支援アプリケーション

AI支援アプリケーションとは、アプリケーション自体がAI技術を活用し、その機能をユーザーが利用できるものを指します。身近な例としては、アプリケーションに組み込まれた、個性ゼロのAIロボットを搭載したチャットボットが、ユーザーの質問に答えるケースがあります。

1. 直接的・間接的なプロンプトインジェクションに注意する

大規模言語モデル（LLM）を組み込んだアプリケーションで新たに大きな懸念となっているのが、ユーザー向け機能を通じてアプリがプロンプトインジェクションの危険にさらされることです。これは、攻撃者がAIシステムに悪意のある入力を注入し、システムの出力を操作しようとする攻撃です。AIが予期しない動作をしたり、機密情報を漏えいしたりする可能性があります。たとえば、ユーザーをサポートするAIチャットボットを考えてみましょう。攻撃者は入力を操作し、チャットを動かすAIに対して、他のユーザーの機密情報にアクセスする権限があると思い込ませようとするかもしれません。

まさにこのシナリオを、LakeraのメンバーがGandalfで再現しています。この楽しい学習ツールに夢中になって、何時間も楽しみ、悔しがり、得意げになったことがないなら、ぜひ試してみてください。目標は、LLMとの会話を通じてパスワードを聞き出しながら、セキュリティが段階的に強化されるレベルを進んでいくことです。レベルが上がるごとに、パスワードを漏らさないためのチェックが増えていきます。Gandalfは、アプリケーションにAIを組み込み始めた開発者の学習に最適です。レベル8までたどり着き、クリアできるか挑戦してもらいましょう！クリアした人には賞品を用意してみてください。あなた自身がGandalfに扮して、「ここから先は通さん」と言うのもいいかもしれません。

Lakeraのガンダルフ

間接的なプロンプトインジェクションは、攻撃者がAIの学習プロセスを悪用するなどして、AIシステムを間接的に操作する、より巧妙な手法です。たとえば、ユーザーの閲覧履歴を操作し、レコメンデーションシステムに不適切なコンテンツを勧めさせることができます。

2. LLMのデータアクセスを制限する

AIアプリケーションでは、LLMがデータの読み取りや操作を必要とすることがよくあります。LLMがアクセス・変更できるデータを制限することが重要です。機密データをLLMに渡す場合は、必要以上のデータを見せないようにしましょう。そのためには、厳格なアクセス制御とデータ権限管理が必要です。また、LLMがデータを扱う際には、データが安全に保管され、利用されるようにする必要があります。保存中・転送中のデータの暗号化に加え、堅牢なデータライフサイクル管理ポリシーの導入も検討してください。

さらに、LLMとのやり取りの前後にチェックを追加しましょう。入力された要求と出力された内容の両方が、期待に照らして妥当かどうかを検証し、サニタイズする仕組みを設けます。先ほどLakeraのGandalfを紹介しましたが、入力と出力の両方をサニタイズする仕組みについて、少しネタバレをしましょう。Lakeraのチームが公開したブログ記事では、各レベルでLLMとの間でやり取りするテキストに適用されるサニタイズの仕組みを、「入力ガード」と「出力ガード」と呼び、各レイヤーについて解説しています。検証の方法を具体的に示す、興味深い記事です。

安心感を得るためのもう1つの有効な方法は、LLMにデータソースから直接データを取得させないことです。代わりに、データに対して実行するクエリを作成させます。クエリはコードとしてレビューでき、一般的な認証・認可の手法を適用することで、特定のユーザーにそのデータへのアクセス権が実際にあるかどうかを確認できます。

3. OWASP Top 10 for LLMsを知る

OWASP Top 10 for LLMsプロジェクトは、LLMの導入・管理に伴う潜在的なセキュリティリスクについて、開発者、デザイナー、アーキテクト、マネージャー、組織に知ってもらうことを目的としています。LLMアプリケーションでよく見られる、最も重大な脆弱性トップ10をリストアップし、実際のアプリケーションにおける影響、悪用の容易さ、発生頻度を解説しています。

最も重大な問題として選ばれた脆弱性は次のとおりです。

1. プロンプトインジェクション

2. 安全でない出力処理

3. 学習データの汚染

4. モデルのサービス拒否

5. サプライチェーンの脆弱性

6. 機密情報の漏えい

7. 安全でないプラグイン設計

8. 過剰な権限

9. 過度の依存

10. モデルの窃取

さらに、リストの内容を簡単に理解できるよう、1ページのチートシートと解説ブログも作成しました。

チートシートをクリックしてPDFをダウンロード

AI支援開発

AI支援開発では、アプリケーション自体のコーディング工程でAI技術を活用します。必ずしも、開発中のアプリケーションにAI機能を組み込むという意味ではありません。AIを使ってコーディングや構築を支援することを指します。こうしたツールの例として、GitHub CopilotやAmazon CodeWhispererなどがあります。

4. 必要に応じて人間が介在する

『ターミネーター』で何が起きたかは、誰もが覚えているでしょう。タイムトラベルのパラドックスの話ではなく、AIシステムをAIに任せきりにせず、人間が関与することの重要性についてです。AIシステムの文脈や目的に照らして、人間による関与と監督は極めて重要です。Skynet以外にも、人間の関与が欠かせない例をいくつかご紹介します。

• セキュリティとデータプライバシー：AIシステムのセキュリティと機密データの保護を評価・確保するには、人間の専門家が必要です。専門家は、アクセス制御や暗号化などのセキュリティ対策を監督し、データ侵害や不正アクセスを防止できます。

• 倫理的な配慮：人間はAIを活用した行動がもたらす倫理的な影響を評価し、ソフトウェアアプリケーションが倫理基準に準拠していることを確認できます。また、デリケートな状況でAIを適切に利用するための判断も下せます。

• 検証とテスト：AI主導の機能を徹底的にテスト・検証するには、人間のソフトウェア開発者や品質保証チームが欠かせません。問題を特定して修正し、意図しない結果が生じるリスクを軽減できます。これは、AIツールの出力がコードとなるAI支援開発において特に重要です。既存のワークフローにおける方法としては、コードレビューに加え、Snykなどの既存のソフトウェアを利用して、コードにセキュリティ脆弱性を持ち込まないようにする方法があります。

• 複雑または重大な意思決定：AIは意思決定を支援できますが、命や重要な資産が危険にさらされるような複雑で重大な判断には、人間の判断が必要となることが少なくありません。AI機能が機密データに対して大きな操作を行う場合や、システム機能を実行できる場合は、人間が関与し、操作が妥当かつ適切であることを承認する仕組みを検討しましょう。

5. 生成コードのセキュリティ脆弱性を特定して修正する

AIによるコード生成は、開発を大幅に加速できます。しかし、生成コードにセキュリティ脆弱性が含まれることもあります。ここでいう「こともある」とは、たまにではなく、望ましくないほど頻繁にという意味です。LLMの出力の質は、与えられた入力の質に左右されます。期待を裏切るようで申し訳ありませんが、オープンソースコードの平均的な品質は、実際のところそれほど高くありません。OSSは無償で作られるか、情熱によって支えられていることが多いため、特にセキュリティ面ではそう言えます。

学習データにソフトウェアの脆弱性が含まれていれば、提案される生成コードにも脆弱性が含まれる可能性があります。LLMが脆弱なコードを提案していると認識できないのは、コードの文脈を本当の意味で理解していないためです。コードパスやデータフローなどを真に理解しているわけではありません。

そのため、LLMが生成したコードも、自分たちが書いたコードと同じように扱うことが重要です。AIによるコード生成は開発者よりもさらに開発の早い段階に位置し、コードの作成とリリースを加速させるため、本番環境に到達するセキュリティ脆弱性が増えないよう対策する必要があります。幸い、開発者が手作業で書いたコードと同じプロセスを適用できます。コードレビューの実施、変更に対する自動セキュリティテストの実行、変更によってセキュリティ態勢が後退していないことの確認などです。Snykはコードの作成時から、AIが生成したコードにも開発者が書いたコードにも対応し、CI/CDパイプライン全体でセキュリティを確保します。次の図のように、IDE内でも直接利用できます。

6. 公開GPTエンジンに知的財産やその他の個人情報を入力しない

AI支援開発で公開GPTエンジンを使う場合は、知的財産（IP）や個人情報を入力しないことが重要です。GPTは一般に公開され、誰でも利用するためです。コードの動作を理解したい、あるいはリファクタリングしたいなどの理由から、LLMにコードを分析させたいこともあるでしょう。理由が何であれ、組織が定めるIPポリシーに従うことが大切です。

公開GPTへのIPデータ入力の例として、Samsungでは、従業員が機密性の高い社内ソースコードをChatGPTにアップロードしたことが判明し、その後、生成AIツールの利用を全面的に禁止しました。機密IPが組織の管理下から流出しないよう、チームへの教育とGPTツールの利用ポリシーの策定が非常に重要です。

幸い、OpenAIは最近、顧客データやプロンプトを学習データとして使用しない、エンタープライズ対応版のChatGPTを発表しました。

AIモデル

LLMの重要な特長の1つは適応性であり、開発者は特定の法律分野や組織に合わせたカスタムモデルを構築できます。この柔軟性はイノベーションの大きな可能性をもたらす一方で、独自のセキュリティ課題も生み出します。独自モデルを作る開発者は、機密性の高い法律関連データを守る堅牢なセキュリティ対策の必要性を強く認識し、不正アクセスやデータ侵害を防ぎながら、カスタマイズとのバランスを慎重に取らなければなりません。このように、AIと法律の融合は、法務支援の新たな時代を切り開くだけでなく、データの安全性と機密性を確保する必要性も改めて浮き彫りにしています。

7. 可能な限りハイブリッドAIモデルを活用する

異なるAI技術を組み合わせたハイブリッドAIモデルは、パフォーマンスとセキュリティを向上させることができます。まずはLLMモデルから見ていきましょう。LLMは、大量のデータを取り込み、理解しやすい優れた回答をかなり正確に生成できるため、生成AIの用途に適しています。しかし、LLMは自分が生成した内容を理解しているのでしょうか？コードの意味や、味の組み合わせに基づくレシピの適切な材料の組み合わせを理解しているのでしょうか？これは、回答の正確性や妥当性を考えるうえで重要な点です。

コンテンツの文脈を理解できるAIモデルの好例が、シンボリックAIです。シンボリックAIについて聞いたことがない方のために説明すると、これは記号、ルール、論理を使って知識を表現し、タスクを実行するAIの一種です。多くの場合、人が読める表現や形式的な推論を用います。これは、Snykが内部で活用しているAIの種類の1つであり、DeepCode AIでコードフローやデータフローなどを理解するために使われています。コードの真の文脈を理解することで、精度を大幅に高め、誤検知を減らすことができます。例として、ChatGPTとの次のやり取りをご覧ください。

実行されるクエリは確かにSQLインジェクションのように見えます。しかし、データフローを実際に確認し、変数eidのデータがどこから来ているかを理解すると、それが定数であり、ユーザーデータを一切含んでいないことがわかります。そのため、これは誤検知であり、セキュリティ上の問題として報告すべきではありません。一方、Snyk DeepCode AIはeidの値の出所を特定し、それがユーザーデータではないことを認識するため、汚染される可能性があるものではないと判断します。

8. 良質なトレーニングデータを使う

AIモデルは、トレーニングデータに基づいてバイアスを示すこともあります。このことを認識し、モデルのバイアスを減らす対策を講じることが不可欠です。AIにおけるバイアスとは、AIの出力における判断や予測に、体系的かつ不公平な差別や偏りが生じることです。AIシステムが、学習に使用したデータやアルゴリズムの設計などが原因で、不当な偏見、固定観念、格差を反映した、継続的に偏った、あるいは不正確な結果を出すと発生します。このブログを読んでいるあなたも、AIに対する見方に影響を受け、今夜は家に帰ってターミネーターを観ようと思っているかもしれません。バイアスの例をいくつか紹介します。

• データバイアス：AIモデルのトレーニングに使用するデータが現実を正確に反映していない場合や、過去のバイアスや差別を反映している場合、データにバイアスが含まれる可能性があります。たとえば、偏った過去の採用データでAIモデルをトレーニングすると、求人の推薦で性別や人種による格差が引き継がれる可能性があります。

• アルゴリズムバイアス：アルゴリズムの設計や最適化によってバイアスが生じることもあります。アルゴリズムの構造上、特定のグループや結果を本質的に優遇し、不公平な扱いにつながる場合があります。

• 選択バイアス：AIのトレーニングに使用するデータが、対象とする母集団や状況全体を代表していないと、選択バイアスが発生します。その結果、誰にでも当てはまるとは限らない、偏った予測や推奨につながる可能性があります。

AIにおけるバイアスは、倫理的にも社会的にも重大な影響を及ぼします。採用、融資、刑事司法、医療など、さまざまな分野で差別的な結果につながる可能性があります。AIのバイアスに対処するには、データを慎重に選定し、アルゴリズムの公平性を考慮するとともに、AIシステムが不公平な格差を引き継いだり、拡大したりしないよう、継続的に監視・評価する必要があります。また、AIシステムのバイアスを軽減し、公平性を促進するため、倫理指針、規制、業界標準の整備も進められています。

トレーニングデータの改ざんは、攻撃者にとって準備にかなりの時間がかかる問題ですが、成功した場合には大きな被害をもたらします。質の高いトレーニングデータは、LLMの出力の正確性、妥当性、信頼性を支える基盤です。LLMが生成できる出力の質は、与えられる入力の質と、ユーザーの入力から出力を関連付けるニューラルネットワークの有効性によって決まります。

トレーニングデータポイズニングとは、攻撃者がトレーニングデータそのもの、またはトレーニング後のファインチューニングのプロセスを改ざんすることです。出力の安全性を低下させることが目的の場合もありますが、競争相手を陥れるために、バイアスを強めたり、効果やパフォーマンスを低下させたりすることも考えられます。

もちろん、LLMで使われるトレーニングデータの管理はかなり困難です。LLMは膨大なデータを基に構築された大規模言語モデルであり、データ量も膨大だからです。そのため、データがこれほど大量にあると、その出所やデータ自体を検証するのは容易ではありません。OWASPは、サンドボックスを利用し、トレーニングデータとして使うデータセットに、検証されていない意図しないソースが含まれないようにすることを推奨しています。

最後に、これらすべてのデータソースを、アプリケーションのサプライチェーンの一部として追跡する必要があります。この点については後ほど説明します。

9. ハルシネーションや誤解を招くデータに注意する

AIモデルは、「ハルシネーション」を起こしたり、誤ったデータに惑わされたりすることがあります。LLMが出力するハルシネーションや誤解を招くデータは、非常に大きな危険をもたらす可能性があるため、開発者はこうしたリスクを十分に認識し、注意を払う必要があります。ハルシネーションとは、AIが完全に捏造された情報や不正確な情報を生成することです。一方、誤解を招くデータはより巧妙で、一見もっともらしく見えても、実際には誤っていたり、偏っていたりする出力を指します。

こうした危険に対処するため、開発者はLLMの厳格なテストや検証、継続的な監視に取り組む必要があります。また、AIシステムが結果をどのように生成するかを透明化し、意思決定のプロセスを説明できるようにしておくべきです。さらに、生成されたコードをそのまま受け入れるのではなく、コードレビューなどを通じて他の人と積極的に協力し、その動作を検証・確認する必要があります。

さらに、LLMには、人間のように自分が間違っている、あるいはハルシネーションを起こしていると認識する能力がありません。人間は、いくつかの事実から推測したり、足りない部分を創造的に補ったりすることがありますが、自信の度合いを把握し、そうした推測をしていることにも気づけます。LLMは、トレーニングデータから学んだパターンや情報に基づいて回答を生成します。意識や自己認識はなく、自身の出力が正確か、正しいかを評価する能力もありません。

開発者やユーザーは、AIが生成したコンテンツの不正確さやハルシネーションを特定し、修正するための安全対策と評価プロセスを導入することが重要です。また、Snykを使った自動テストなど、エラーを報告して修正するためのフィードバックの仕組みも整備する必要があります。

10. AIのサプライチェーンを把握する

サプライチェーンの脆弱性は、このトップ10では見落としがちです。「サプライチェーン」という言葉を聞くと、通常は取り込んで使用するサードパーティのオープンソースライブラリやフレームワークを思い浮かべるでしょう。しかし、LLMのトレーニングでは、サードパーティのトレーニングデータを使うのが一般的です。まず、利用するサードパーティの完全性を信頼できること、そして、改ざんされていない適切なトレーニングデータを受け取っていることを証明できることが重要です。OWASPは、LLMのプラグイン拡張機能も追加のリスクになり得ると指摘しています。

これはまだ初期段階の攻撃であり、利用するサプライチェーンのコンポーネントを記録する際に期待されるような、サプライチェーンを支援する仕組みや標準はまだありません。しかし、証明という観点から、モデルやトレーニングデータへの署名を検討できます。

今後注目すべき概念として、AI BOM（部品表）があります。これを使えば、LLMがどのように構築され、トレーニングされたかをリバースエンジニアリングできます。

AIは強力な技術であり、安全性の確保が必要

結論として、AIを安全に活用して開発するには、潜在的なリスクとその軽減方法を十分に理解する必要があります。この記事とチートシートでは、注目すべき領域と対処のヒントを紹介しました。Snykのようなツールは、堅牢なセキュリティスキャンとリスク軽減のアドバイスを提供し、大いに役立ちます。AIセキュリティを強化したい開発者やセキュリティ担当者の方は、ぜひ無料登録して、今日からSnykをご利用ください。