AIセキュリティリスク：AIシステムを安全に運用するためにDevSecOpsチームが知っておくべきこと
AIのセキュリティリスクは、もはやモデルの動作やデータプライバシーだけにとどまりません。今日では、ソフトウェアの記述、レビュー、構築、出荷の方法にも影響を及ぼしています。AIコーディングツール、エージェント型AIシステム、AIを活用したワークフローが普及するにつれ、 SDLCDevSecOpsチームは、より速いコード、より速い自動化、そしてより速いミスという、新たな種類のリスクに直面している。
しかし、これはチームがAIの導入を遅らせるべきだという意味ではありません。むしろ、AI支援開発のスピードに見合ったセキュリティ制御が必要です。このガイドでは、最も重要なAIセキュリティリスク、実際のエンジニアリングワークフローでどのように現れるか、そしてチームがコード、依存関係、シークレット、 pipelines、およびエージェント。
AIが脅威の状況をどのように変えるかについてのより広範な概要については、次のガイドを参照してください。 AIサイバーセキュリティ.
AIのセキュリティリスクとは？
AI セキュリティリスクとは、人工知能が実際のシステム内で設計、トレーニング、統合、または使用される際に発生する弱点、脅威、または障害モードのことです。これらのリスクは、モデル、データ、プロンプト、API、コード、 pipelineそれらと、それらをつなぐツール。
その NCSCによるAIとサイバーセキュリティに関するガイダンス サイバーセキュリティは安全で信頼性の高いAIシステムの中核要件であると説明しています。同様に、 NIST AI リスク管理フレームワーク 組織がガバナンス、測定、および実践的な管理を通じてAIリスクを管理するための枠組みを提供する。
DevSecOps チームにとって、問題はより具体的です。AI は今やソフトウェアデリバリーチェーンの一部となっています。コードを記述し、依存関係を提案し、構成を生成し、API を呼び出し、時には自律的に動作します。その結果、AI のセキュリティリスクは、 SDLCモデル層だけでなく、あらゆる層において。
AIセキュリティリスクが現在では異なる理由
従来のサイバーセキュリティリスクは、通常、人間が書いたコード、脆弱なパッケージ、脆弱な認証情報、または設定ミスのあるインフラストラクチャに起因します。これらのリスクは依然として存在します。しかし、AIは、それらのリスクの発生速度と検出の難しさを変化させています。
AIが生成したコードは一見正しく見えても、認証チェックが漏れている可能性があります。AIコーディングアシスタントが脆弱なパッケージを提案することもあります。エージェントワークフローが誤ったツールを呼び出したり、誤ったファイルにアクセスしたり、ログに機密情報を漏洩させたりする可能性もあります。さらに、AIシステムはコンテキスト、プロンプト、コネクタ、外部ツールに依存することが多く、セキュリティ上の脆弱性が生じる箇所が増えます。
その LLM アプリケーション向け OWASP トップ 10 即時注入、機密情報の漏洩、サプライチェーンの問題、過剰な権限行使といったリスクを強調しています。これらの分類は、AIの挙動と実際のアプリケーションセキュリティ問題を結びつける上で有用です。
言い換えれば、AIのセキュリティリスクはモデルそのものだけに関わるものではない。モデルを取り巻くシステム全体に関わるものなのだ。
DevSecOpsチームにとっての中核となるAIセキュリティリスク
以下は、AI が開発、AppSec、および CI/CD ワークフロー。
1. AI生成コードの脆弱性
AIコーディングツールは、動作するコードを生成することはできますが、安全ではない場合があります。例えば、適切なパラメータ設定なしにSQLクエリを作成したり、入力検証を省略したり、脆弱な認証ロジックを実装したりする可能性があります。
これは、多くのAIシステムがトレーニングデータに基づいて可能性の高いコードパターンを生成するために起こります。しかし、可能性の高いコードが必ずしも安全なコードであるとは限りません。実際には、公開リポジトリでよく見られるため、モデルが安全でない例を再現してしまう可能性があります。
一般的な例は次のとおりです。
- SQLインジェクション
- クロスサイトスクリプティング
- 認証チェックが不足しています
- セッション処理が不十分
- 安全でない逆シリアル化
- CSRF保護が欠落しています
したがって、AI生成コードは、次の条件を満たすまでは信頼できないものとして扱うべきである。 SAST方針の確認とレビュー。
内部リンクの提案: このセクションを次の投稿にリンクしてください AI SAST.
2．サプライチェーンと依存関係のリスク
AIツールはコードを生成するだけでなく、パッケージ、バージョン、スクリプト、インストールコマンドなども提案します。これにより、AIによる推奨事項からソフトウェアサプライチェーンのリスクへと直接つながる経路が生まれます。
例えば、AIツールは次のような提案をする可能性があります。
- 古いパッケージ
- 誤植された依存関係
- 幻覚的なパッケージ名
- インストールスクリプトに疑わしい部分があるパッケージ
- 脆弱性を抱えながらも広く利用されている図書館
さらに、攻撃者はAIツールが生成する可能性のあるパッケージ名を登録することで、この挙動を悪用できる。このリスクはしばしば「スロップスクワッティング」と呼ばれ、モデルの誤生成をパッケージサプライチェーン攻撃へと変える。
このリスクを軽減するために、チームは SCAマルウェア検出、依存関係ポリシーの適用、到達可能性分析など。また、次のような悪用可能性シグナルも使用する必要があります。 EPSS および、 CIS既知の悪用された脆弱性のカタログ.
3. AIワークフローにおける機密情報の漏洩
機密情報の漏洩は、最も現実的なAIセキュリティリスクの一つです。開発者はしばしば、AIツールにコンテキスト情報を貼り付けます。そのコンテキストには、APIキー、トークン、認証情報、URL、内部設定などが含まれる可能性があります。
さらに、AIが生成したコードには、本物そっくりのプレースホルダーが含まれている場合や、さらに悪いことに、秘密情報をソースファイルにコピーしてしまう場合がある。 pipeline スクリプト、またはログ。秘密情報が Git の履歴または CI/CD ログは、元のログが長期間使用されても悪用可能なままになることがあります。 commit.
一般的な暴露箇所は以下のとおりです。
- プロンプト履歴
- 生成されたコード
- Gitの commits
- CI/CD ログ
- IaC ファイル
- コンテナイメージ
- 共有ワークスペース
このため、チームはIDEレベルのスキャンと、 pre-commit チェック、リポジトリ履歴スキャン、 CI/CD ログのスキャンと自動的な取り消し。
内部リンクの提案：このセクションを、貴社の機密情報セキュリティ製品または関連コンテンツにリンクしてください。
4. AIエージェントおよびツールの誤用
エージェントAI エージェントは行動を提案するだけでなく、自ら行動を起こすこともできるため、新たなリスク要因が生じる。
AIエージェントは、シェルコマンドを実行したり、ファイルを編集したり、APIを呼び出したり、 pull requestsCIワークフローを変更したり、クラウドサービスと連携したりすることができます。これは生産性を大幅に向上させる一方で、ミスが発生した場合の影響範囲も拡大します。
主なリスクは次のとおりです。
- 安全でないシェル実行
- 権限過剰のAPIキー
- 不正なコード変更
- MCPまたはAPIコネクタの設定ミス
- 承認された範囲外のツール呼び出し
- タスクに必要な範囲を超えた環境へのアクセス
OWASP LLM Top 10の「過剰なエージェント権限」というカテゴリは、特にここで重要になります。エージェントが過剰なアクセス権限を持っている場合、不適切な指示、迅速なインジェクション、または侵害されたツールによって、深刻なセキュリティインシデントが発生する可能性があります。
5. CI/CD (NAIST) と Pipeline リスク
AIが生成したコードは最終的に pipelineその時点で、リスクはソースコードからビルド、成果物、機密情報、依存関係、およびデプロイメントワークフローへと移行する。
例えば、AIによる変更には以下のようなものがある。
- 安全でないビルド手順を追加する
- GitHub Actionsワークフローを変更する
- インストール中に悪意のあるパッケージをプルする
- 秘密情報をビルドログに出力する
- セキュリティ制御を無効にする
- デプロイメントロジックを変更する
その結果、 CI/CD セキュリティはAI導入において不可欠な要素となる。 Pipeline guardrails 安全でないパターンは、本番環境に到達する前にブロックする必要があります。詳細については、次のコンテンツを参照してください。 CI/CD セキュリティ (NAIST) と software supply chain security.
6. データ漏洩と即時注入
プロンプトインジェクションは、最もよく知られたAIセキュリティリスクの一つですが、しばしば誤解されています。これはチャットボットだけの問題ではなく、外部からの入力を受け取り、その入力に基づいてアクションを実行するあらゆるAIワークフローに影響を与える可能性があります。
例えば、悪意のある問題の説明、READMEファイル、サポートチケット、または依存関係のドキュメントページには、隠された指示が含まれている可能性があります。AIエージェントがその内容を読み取り、それに従うと、攻撃者はツールの呼び出し、コードの変更、またはデータへのアクセスに影響を与える可能性があります。
データ漏洩は同様の方法で発生する可能性があります。モデルが機密性の高い情報を漏洩したり、プライベートファイルを要約したり、機密データを外部サービスに送信したりする可能性があります。したがって、AIシステムには迅速なフィルタリング、出力制御、ツール制限、およびアクセスできるデータに関する明確な境界が必要です。
AIセキュリティリスク SDLC
AIのセキュリティリスクは、ソフトウェアライフサイクルのさまざまな段階で発生します。重要なのは、最終的なアプリケーションだけでなく、各段階のセキュリティを確保することです。
| SDLC ステージ | AIセキュリティリスク | 例: | 推奨されるコントロール |
|---|---|---|---|
| IDE | 安全でないAI生成コード | AIコーディングアシスタントが、安全性の低い認証ロジックを提案した。 | リアルタイム SAST そして、安全なコーディングフィードバックを提供します。 |
| Commit | 秘密暴露 | トークンは生成されたコードに現れるか、 commit 歴史。 | 秘密の検出、 pre-commit チェック機能、および自動失効機能。 |
| Pull Request | ポリシーバイパス | 生成されたコードは、レビューなしにアクセス制御ルールを変更します。 | PR guardrails そして政策の執行。 |
| 建設 | 悪質な依存 | AIが推奨するパッケージに、不審なインストール動作が含まれています。 | SCAマルウェア検出、および依存関係ポリシーのチェック。 |
| CI/CD | Pipeline 操作 | エージェントはワークフローファイルまたはデプロイメントスクリプトを変更します。 | CI/CD セキュリティチェックと異常検知。 |
| ランタイム | 即時注入またはデータ漏洩 | 外部からの入力によって、AIワークフローが機密性の高い情報を漏洩する。 | 迅速な制御、アクセス制限、および監視。 |
AIのセキュリティリスクと従来のサイバーセキュリティリスクの比較
従来のサイバーセキュリティ対策は依然として重要である。しかし、AIは新たな行動パターンを生み出し、それに応じた異なる対策が必要となる。
| エリア | 従来のサイバーセキュリティリスク | AIセキュリティリスク |
|---|---|---|
| CPコード | 人間が作成した脆弱性。 | AIが生成するセキュリティ上の脆弱性パターンがより高速化される。 |
| 依存関係 | 既知の脆弱性のあるパッケージ。 | 幻覚的、悪意のある、または安全でないAIが提案するパッケージ。 |
| シークレット | 認証情報が誤って commit開発者によって作成されました。 | プロンプト、生成されたコード、またはログにコピーされた秘密情報。 |
| ツール | 開発者ツールの手動による誤用。 | 自律エージェントがツールやAPIを悪用する。 |
| Pipelines | 設定されていない CI/CD ワークフロー。 | エージェントが生成したワークフローの変更、または安全でない自動化。 |
現実世界におけるAIセキュリティリスクの事例
AIのセキュリティリスクは理論上の問題ではない。現在、複数の公的フレームワークや研究活動が、これらの問題をより体系的に追跡している。
その MIT AIリスクリポジトリ OWASPは、さまざまな原因と領域にわたる1,700を超えるAIリスクをカタログ化しています。一方、OWASPは、即時注入、機密情報の漏洩、サプライチェーンの脆弱性、過剰な代理行為など、LLMアプリケーションのリスクに関する実用的なカテゴリを提供しています。
DevSecOpsチームにとって、最も関連性の高い事例は、ソフトウェア開発の現場でよく見られる。
- 脆弱なコードを示唆するAIツール
- ワークフローファイルを変更するAIエージェント
- AIが生み出す依存関係がサプライチェーンのリスクを高める
- プロンプト、ログ、または commits
- 承認された範囲外のツールを呼び出すエージェントワークフロー
つまり、AI システムがコード、認証情報、パッケージ、 pipelineまたはインフラストラクチャ。
AIセキュリティリスクを実際に軽減する方法
AIセキュリティリスクを軽減する最善の方法は、AI支援開発を SDLCつまり、早期にスキャンを行い、頻繁に検証し、開発者が実際に作業する場所でポリシーを徹底する必要があるということです。
1. IDEでAI生成コードをスキャンする
開発者は、AIが生成したコードを記述または受け入れる際に、セキュリティに関するフィードバックを確認できるべきです。これにより、コンテキストの切り替えが減り、問題がGitに到達する前に修正するのに役立ちます。
使用します。
- SAST IDEで
- インライン脆弱性説明
- 安全な修正案
- ポリシーを考慮した是正措置
これは、安全でない提案がすぐにコードベースに入り込んでしまう可能性のあるAIコーディングアシスタントにとって特に重要です。
2. ビルド前に依存関係を検証する
AI が提案する依存関係は、インストールまたは出荷する前に検証する必要があります。したがって、チームは開発中に依存関係の管理を徹底し、 CI/CD.
使用します。
- SCA
- マルウェアの検出
- タイポグラフィ検出
- EPSSスコア
- 到達可能性分析
- ポリシーベースのブロック
これは、理論上のリスクだけでなく、実際のリスクを反映したパッケージを優先的に選択するのに役立ちます。
3. 秘密情報を自動的に検出して取り消す
機密情報のスキャンは、ソースコードだけにとどまるべきではない。AIを活用したワークフローでは、多くの場所で認証情報が漏洩する可能性がある。
使用します。
- Pre-commit スキャニング
- リポジトリ履歴のスキャン
- Pipeline ログスキャン
- IaC スキャニング
- コンテナ画像スキャン
- 自動取り消し
その結果、チームは感染から封じ込めまでの時間を短縮できる。
4. 強制する Guardrails in CI/CD
Guardrails 変更を進めるのに十分安全かどうかを判断する必要がある。報告は有用だが、重大なリスクに対しては阻止措置が不可欠である。
Guardrails 以下をカバーすべき:
- 新たな重大な脆弱性
- シークレット
- 悪意のある依存関係
- ピン留めされていない、または信頼されていないパッケージ
- 安全でないワークフローの変更
- 見つけて下さい SBOMs
- ポリシー違反
さらに、チームは必要に応じて報告のみのモードから始め、自信がつくにつれてブロックへと移行していくべきである。
5. エージェントツールの動作を監視する
エージェント型AIシステムには可観測性が必要です。エージェントがファイルを編集したり、ビルドをトリガーしたり、APIを呼び出したりできる場合、チームはエージェントが何をしたのか、いつしたのか、そしてその動作が想定内だったのかを知る必要があります。
モニター：
- ツール呼び出し
- ワークフローファイルの変更
- リポジトリ書き込みアクティビティ
- ネットワーク接続先
- 秘密へのアクセス
- Pull request 創造
- Pipeline トリガされ
この可視性がなければ、エージェントの自律性を信頼することは難しくなる。
XygeniがAIセキュリティリスクの軽減に役立つ点
Xygeni は、ソフトウェア デリバリー チェーン全体にわたって AI 支援開発のセキュリティを確保することに重点を置いています。AI リスクを別のカテゴリとして扱うのではなく、コード、依存関係、秘密情報、 pipelines、およびビジネスコンテキスト。
具体的な例を挙げますと、以下の通りです。
- SAST 安全性の低いAI生成コードを早期に検出するのに役立ちます。
- SCA 依存関係を検証し、悪意のあるパッケージを検出します。
- シークレットセキュリティ リポジトリ全体で公開された認証情報を検出し、 pipelines.
- CI/CD セキュリティ 危険な変更が実施される前に、ポリシーを施行する。
- 異常検出 開発および配信ワークフローにおける異常な動作を特定します。
- ASPM 調査結果を一つのリスクビューに統合することで、チームが重要な事項を優先的に判断できるようにする。
これは、AIのセキュリティリスクが本質的に複数のレイヤーにまたがるため重要です。脆弱な依存関係、公開されたトークン、安全でないワークフローの変更は、個別のツールではそれぞれ独立しているように見えるかもしれません。しかし、これらが組み合わさると、はるかに大きな攻撃経路となる可能性があります。
知っておくべきAIセキュリティリスク管理フレームワーク
いくつかのフレームワークは、チームが業務を体系化するのに役立つ。
その NIST AI リスク管理フレームワーク 組織がAIリスクをマッピング、測定、管理、統制するのに役立ちます。リーダーシップ、コンプライアンス、リスク管理プログラムに有用です。
その LLM アプリケーション向け OWASP トップ 10 これは、即時インジェクション、機密データの漏洩、サプライチェーンの脆弱性、過剰なエージェンシーといった技術的なリスクに直接対応しているため、AppSecチームにとってより実用的です。
その NCSCのAIおよびサイバーセキュリティに関するガイダンス AIが組織のサイバーリスクをどのように変化させるかを理解する必要のあるセキュリティリーダーにとって有益です。
これらの資料を総合すると、一つの明確な点が浮かび上がってくる。それは、AIのセキュリティは、人、プロセス、システム、そしてソフトウェア配信ワークフロー全体にわたって管理されなければならないということだ。
チェックリスト：AIセキュリティリスクを軽減する方法
このチェックリストを実践的な出発点として活用してください。
| コントロールエリア | 何をすべきか | それが重要な理由 |
|---|---|---|
| AIが生成したコード | ラン SAST IDE、PR、および CI/CD pipeline. | 安全性の低いコードが本番環境に渡るのを防ぎます。 |
| 依存関係 | SCAマルウェア検出、EPSS、および接続性。 | AIが推奨する危険なパッケージをブロックします。 |
| シークレット | スキャン commits、ログ、履歴、 IaC、コンテナなど。 | 認証情報の漏洩や悪用を軽減します。 |
| CI/CD | 施行 pipeline guardrails そしてポリシーゲート。 | 安全でないビルドやデプロイを阻止します。 |
| エージェントツール | ツール呼び出し、APIアクセス、ワークフローの変更を監視します。 | 過剰な権限行使や予期せぬ行動を制限する。 |
| 危機管理 | ASPM 複数の層にわたる調査結果を関連付ける。 | チームが真のビジネスリスクに集中できるよう支援します。 |
主要なポイント（要点）
- AI セキュリティのリスクは、コード、依存関係、秘密情報に影響を及ぼします。 pipelines、およびエージェント。
- 従来型のアプリケーションセキュリティツールは依然として必要だが、より早い段階で、より多くのコンテキスト情報に基づいて実行される必要がある。
- AIが生成したコードは、検証されるまでは信頼できないものとして扱うべきである。
- AIエージェントのワークフローには guardrails権限、および可観測性。
- DevSecOps チームは、 SDLC AIリスクを効果的に管理するため。
よくある質問：AIのセキュリティリスク
AIのセキュリティリスクとは何ですか？
AI セキュリティリスクとは、AI システムの構築、統合、使用時に発生する脅威や脆弱性のことです。これらは、モデル、データ、プロンプト、コード、依存関係、API に影響を与える可能性があります。 pipelines.
DevSecOpsチームにとって、AIセキュリティにおける最大のリスクは何ですか？
最大の危険には、安全でないAI生成コード、脆弱な依存関係、秘密情報の漏洩、プロンプトの注入、過剰なエージェント権限、安全でないコードなどが含まれます。 CI/CD オートメーション。
AIのセキュリティリスクは、従来のサイバーセキュリティリスクとどのように異なるのでしょうか？
AIシステムはコードを生成し、依存関係を提案し、ツールを呼び出し、自律的に動作することができます。その結果、リスクはより速く、より多くのレイヤーにわたって現れます。 SDLC.
チームはどのようにしてAIのセキュリティリスクを軽減できるのか？
チームは、AI 生成コードをスキャンし、依存関係を検証し、秘密を検出し、強制することでリスクを軽減できます。 CI/CD guardrailsエージェントの行動を監視し、結果を相関させることによって ASPM.
AIが生成したコードは安全ですか？
AIが生成したコードは、デフォルトでは安全ではありません。本番環境に導入する前に、レビュー、スキャン、テスト、検証を行う必要があります。
最終的な考察：AIセキュリティリスクの必要性 SDLC-レベルコントロール
AIはソフトウェアリスクの速度と形態を変革する。AIはチームの開発速度を向上させる一方で、安全性の低いコード、漏洩した機密情報、安全でない依存関係、リスクの高い自動化などが開発プロセスに混入する新たな経路を生み出す。
したがって、AIセキュリティはモデルガバナンスやポリシー文書だけで対処できるものではありません。 SDLC: IDE フィードバック、 SAST, SCA秘密の検出、 CI/CD guardrails異常検知、 ASPMレベルの相関関係。
AIのセキュリティリスクを適切に管理できるチームこそが、AIの導入を阻害するチームではなく、AIを取り巻く適切な安全層を構築するチームとなるだろう。
