9月23日と24日、Xygeniチームは2つの都市と2つのOWASPコミュニティに分かれて、AIアプリケーションセキュリティについて議論しました。 OWASP AppSec Days ポルトガル、ポルト (NAIST) と OWASPのAIセキュリティイベントがカールスルーエで開催されます。、ドイツ。
国も人も違うが、会話のほとんどすべてで同じ質問が出てくる。 「AIはアプリケーションセキュリティにおいて実際にどのような点で役立つのか、また、単に古いツールに新しいラベルを付けただけなのか？」
これは、私たちが耳にした内容、驚いたこと、そして私たちが答えたことをまとめたものです。
TL; DR
OWASPの2つの会議室、2つの国、そして1つの疑問：AIはアプリケーションセキュリティにおいて実際にどのような役割を果たすのか？ ポルトとカールスルーエでは、実務担当者はAIを使うべきかどうかを問うのではなく、自社のアプリケーションセキュリティスタックの中でどのAIが実際に機能しているのか、そしてAI自体を誰が保護しているのかを問うていた。
- ASPM 多くのチームにとって、それはまだ新しい概念である。 ポルトでは、多くの実務家が Application Security Posture Management プラットフォームは、毎日解決している問題（ツールが多すぎる、アラートが多すぎる）を実感しているにもかかわらず、そう感じてしまうのです。
- ASPM そして「AI」 SAST「それらは同じものではありません。」 スキャンによってコードの欠陥が発見される。 ASPM 実行するすべてのツールから得られる結果のうち、実際に時間を費やす価値があるのはどれかを判断する。
- AIによるトリアージと修復が最も注目を集めた。 「これは本当なのか？どれくらい緊急なのか？修復はどれくらい難しいのか？」これは、すべてのチームが、あらゆる発見事項、あらゆるスキャナーからの情報に対して、自動的に回答を得たいと願う質問です。
- AIはもはや単なる利用ツールではなく、保護すべき資産となっている。 プロンプトファイル、MCPサーバー、エージェント構成など
.mcp/servers.jsonまた、AI認証情報も攻撃対象の一部であり、CHAINDROPキャンペーンは事件の3週間前にそれを明らかにした。 - ヨーロッパでは主権が重要だ。 独自のインフラストラクチャと独自のモデルでAIを実行するという点が、何度も話題に上がった。
2つの都市、AIアプリケーションセキュリティに関する1つの対話
In ポルト, Agustín Sánchez (グローバル アプリケーション セキュリティおよびセキュア AI 開発アドバイザー) (NAIST) と マルコス・マーティン（DevSecOpsエンジニア） 私はアントニオ・クパチーノ・デ・ミランダ財団のブース12で2日間過ごしました。で カルルスルーエ, George Nissim (シニア ソリューション エンジニア)）は、IHK Haus der Wirtschaftで開催されたOWASPコミュニティのイベントに参加し、AIセキュリティに重点を置いた一日を過ごしました。
会場は開発者、アプリケーションセキュリティエンジニア、DevSecOpsリーダーといった実務家でいっぱいだった。スライドを読むのではなく、テストによって評価する人たちだ。おかげで議論はより鋭く、私たちにとってより有益なものになった。
質問1：「一体何が ASPM？ "
この問題はポルトで頻繁に話題に上り、明確な回答が必要だ。
ASPM (Application Security Posture Management）は、あらゆるセキュリティツールからの検出結果を1つのリスクモデルに変換するレイヤーです。 ほとんどの組織は既に複数のスキャナーを実行しています。コード用、依存関係用、シークレット用、場合によってはインフラストラクチャ・アズ・コード用などです。それぞれが独自のリスト、独自の深刻度スケール、独自の dashboardその結果、何千ものアラートが発生する一方で、唯一重要な質問に対する共通の答えは得られない。 まず最初に何を直すべきでしょうか？
ASPM その質問に答えます。ネイティブスキャナーと サードパーティ製のツールそれらを相関させ、生の深刻度ではなく実際のリスクに基づいて優先順位を付けます。このカテゴリーが初めての方は、 何 ASPM それが何であり、なぜ重要なのか 良い出発点です。
会議室にいるチームにとっての重要なポイント： ASPM 既にお使いのソフトウェアを置き換える必要はありません。 既存のスタックが入力となります。
Is ASPM AIと同じ SAST?
いいえ。スキャンによって問題が発見されます。 ASPM どの問題に時間を費やすべきかを判断する。
| 次元 | スキャン（SAST AIを使って） | ASPM |
|---|---|---|
| 質問に答える | このコードに脆弱性はありますか？ | 私たちが発見したすべてのものの中で、最も重要なものは何でしょうか？ |
| 対象領域 | 発見された情報の種類の一つ：ソースコード | すべての発見タイプ、 あらゆるツールから |
| AIが役立つ場面 | コードの欠陥を検出、説明、修正する、 IDE内で直接 | ポートフォリオ全体にわたるトリアージ、優先順位付け、および是正措置 |
| 出力 | 所見 | A 優先順位付けされたリスクモデル 固定キュー |
要するに： スキャンで問題が見つかりました。 ASPM どの問題に時間を費やすべきかを判断する。 両方とも必要です。そして、両方を組み合わせることでより強力になります。なぜなら、同じAIレイヤーがXygeniのスキャナーが検出するものと、他のツールが検出するものの両方に適用されるからです。市場のより広い視野については、当社の比較をご覧ください。 top ASPM 2026年のためのツール.
質問3：「XygeniはAIアプリケーションセキュリティをどのように活用していますか？」
ほとんどの議論はここから最も深い内容へと発展しました。私たちの答えはこうです。XygeniのAIは、アラートを増やすためにあるのではありません。ノイズを除去し、作業を完了させるためにあるのです。AIアプリケーションセキュリティに関する4つの具体的な仕事：
1. AIトリアージ：この発見は本当なのか？
すべての発見について、 AIトリアージ 3つの質問に答えます。それは誤検出かどうか、実際の影響に基づいてどの程度緊急性があるか、そして修正の複雑さ（自動、中程度の手動作業、または高度な手動作業）です。Xygeniの検出結果と、サードパーティのスキャナーから取り込まれた検出結果の両方に対応しています。
2. AIの説明：攻撃者はこれをどのように利用するでしょうか？
CWE番号と一般的な説明ではなく、開発者は脆弱性の悪用方法と検証方法といった、完全なエクスプロイトパスを受け取ることができます。これが、バックログに放置されるチケットと修正されるチケットの違いです。
3. AIの修復：ビルドを壊さずに修正する
Xygeniは、コードおよびインフラストラクチャ・アズ・コードの検出結果に対して、ビルドを壊さないように設計された検証済みの修正案を提案します。目標は、チケットの件数を減らすことであり、チケットの記述を改善することではありません。
4. DevAI：プロンプトなしでIDE内でセキュリティを実現
開発AI VS Code、IntelliJ、Cursor、Windsurfといったツールで、開発者からの依頼を待つことなく、積極的に脆弱性を検出します。人間が書いたコードとAIが生成したコードの両方において、記述と同時に脆弱性を検出し、攻撃者がどのように悪用するかを説明し、その場で修正案を提示します。
質問4：「では、AI自体のセキュリティは誰が確保するのですか？」
カールスルーエはまっすぐここへ向かい、ポルトがそれに続いた。
AIコーディングアシスタント、エージェント、MCPサーバーは、今やあらゆる開発環境の一部となっています。これらは、プレーンテキストファイル（スキルファイル、ルールファイル、プロンプト、MCP構成）によって制御され、 commit文書のようにテストされ、レビューされます。しかし、それらはAIアシスタントに指示される内容と到達できる範囲を静かに変更します。これらのリスクについては、 AIセキュリティにおけるトップ10の脅威.
その チェーンドロップ 2026年8月のキャンペーンは、それが実際に何を意味するのかを示した。自己増殖するワームが数百のnpmパッケージにバックドアを仕掛け、合計で 月間ダウンロード数1.3億回以上認証情報収集ツールで標的を絞った AIアシスタントの認証情報 数百もの他のパターンの中に含まれます。アクティブなエクスプロイト中にCVEは割り当てられませんでした。待つ必要はありませんでした。これは、毎週確認済みの攻撃で追跡しているパターンと同じです。 悪意のあるnpmパッケージ 調査結果。
Xygeni AI Securityは、このレイヤーに3つのステップで対応します。
- 発見： リポジトリ全体にわたるすべての AI アセット (モデル、フレームワーク、データセット、エージェント、MCP サーバー、スキル、プロンプト、 guardrails （使用されているAIコーディングツールも含む）コード、依存関係、およびAIツールが残した構成ファイルから構築されています。アンケートも自己申告もありません。 なぜ発見が最優先されるのか.
- 地図： an AI-BOM また、どのエージェントがどのツールを呼び出すか、どのMCPサーバーがどのアシスタントの背後にあるかを示す関係グラフも表示されます。リスクは個々の資産ではなく、配線に潜んでいます。
- 検出: コードと構成における迅速な注入と関連するリスク、 LLM アプリケーション向け OWASP トップ 10正確なファイル名と行番号。さらに、プロンプトおよびエージェント構成ファイルに公開された AI プロバイダー認証情報、および悪意のある AI スタック依存関係が、 松下電工署名が存在する前に悪意のあるパッケージを検出する、当社のマルウェアエンジンです。
全体像を把握するには、以下をお読みください。 AIセキュリティについて解説 と私たちのガイド AIサプライチェーンセキュリティ.
質問5：「私のコードは私のインフラストラクチャ内に保持できますか？」
ヨーロッパの会議室では、この質問が必ず出てきます。多くのチームにとって、AI アプリケーション セキュリティは、AI 自体がデータ主権を尊重する場合にのみ機能します。答えはイエスです。Xygeni は SaaS として動作し、 on-premises、ハイブリッド、またはエアギャップ。モデル（OpenAI、Anthropic、Gemini、Groq、Azure AI Foundry、AWS Bedrock、または独自の互換性のあるAPI）を選択でき、コードは環境外に流出せず、AIコストを制御できます。
自律的AI サイバーレジリエンス法に基づく報告義務 2026年9月11日以降（実際に悪用されている脆弱性について早期警告を発信するのに24時間以内）、実際のリスクを迅速に把握することは、もはやあれば良いものではなく、規制上の要件となっています。
私たちが持ち帰ったもの
1週間と2つのOWASPルームから得られた3つの教訓：
- 市場は語彙を先取りしている。 チームは ASPM ユーザーはカテゴリ名を知る前に、問題（ツールが多すぎる、アラートが多すぎるなど）を認識してしまう。名前を付けることよりも、それを分かりやすく説明することの方が重要だ。
- 実務家たちは、仕事を終わらせてくれるAIを求めている。 トリアージと修復は、あらゆる議論において「AIによる検出」よりも優れている。
- AIはもはや単なる利用ツールではなく、保護すべき資産となっている。 「実際にどんなAIを運用しているのか？」というインベントリに関する質問は、ほとんどのチームが未だに答えられないものです。これは、あらゆる本格的な取り組みの出発点でもあります。 AIリスク管理 プログラム。
OWASPポルトガルとOWASPドイツのコミュニティ、主催者の皆様、そして立ち寄って会話をしてくださった皆様に感謝いたします。次回のイベントでお会いしましょう。
FAQ
違いは何ですか ASPM (NAIST) と SAST?
SAST ソースコードをスキャンして脆弱性を検出します。 ASPM 集計結果 SAST そして他のすべてのセキュリティツールと同様に、それらを関連付け、実際のリスクに基づいて優先順位付けすることで、チームは最初に何を修正すべきかを把握できます。
AIによるトリアージは、他のツールによる調査結果にも適用できるのか？
Xygeniの場合、はい。AIによるトリアージ、説明、および修復機能は、Xygeni独自の検出結果だけでなく、Snyk、Veracode、Checkmarxなどのサードパーティ製スキャナーから取り込まれた検出結果にも適用されます。
AI-BOMとは何ですか？
AI 部品表には、ソフトウェア内の AI コンポーネント (モデル、データセット、エージェント、MCP サーバー、プロンプト、および guardrailsそして、それらがどのように繋がっているのか。
XygeniのAIは実行できますか on-premises?
はい。Xygeniはサポートしています。 on-premiseAIモデルを選択可能な、s、ハイブリッド、エアギャップ展開。
