Help Net Securityのインタビューで、OplaneのCTO、Oscar Anderssonは、多くのスキャンツールが失敗する理由を解説しています。これらのツールは実際のコードでは実行不可能な脅威を警告し、「オオカミが来た」状態に陥ります。議論の核心は「到達可能性」にあります。実際に動作するビルドにおいて、影響に至るパスを辿ることができた場合のみ、検出結果は有効とみなされます。彼は、人気のオープンソースプロジェクトで小さな設計上の選択が積み重なってアカウント乗っ取りに至った経緯を示しつつ、ベンダーの主張を検証する方法、AI自体を標的にした攻撃への対処法、そして年1回の監査よりもコード変更のたびにレビューすることの有効性について語ります。
セキュリティツールが廃れる原因：実際のバグの見逃しではなく、過剰なアラート
トリアージ疲労こそが、セキュリティツールを機能不全に追い込む最大の要因です。SCAはその典型例といえます。CVSS 9のアラートが届くとすべての作業を中断しますが、脆弱な関数が自分たちのコードからは到達不可能だったと判明します。スコアは本物でしたが、リスクはゼロだったのです。これを十数回も繰り返せば、優秀なエンジニアでも次の9.8を見た瞬間にクローズするよう「訓練」されてしまいます。
判断基準となるのは、検出結果が実際のコード内の到達可能なパスに結びついているかどうかです。到達可能性こそがすべてであり、それは双方向に機能します。実行不可能なCVSS 9は「脅威に見える側」から失格となり、本当に悪用可能なバグは逆に「退屈に見える側」から現れることが多いのです。
最近の事例がこれを具体的に示しています。GitHubのスター数が35,000以上のオープンソースプロジェクトでの話です。あらゆるスキャナーが抽象的な形で警告を出します。「任意のファイルアップロードを受け付けている」というものです。単独で見れば収まりがよく見えます。Content-Security-Policyがスクリプトを’self’に固定しているため、インラインの<script>や外部URLは即座に遮断されます。一見クローズできそうです。チェックボックス的なレビュアーはアラートをそのまま申請するか、あるいは見逃してしまうかのどちらかですが、いずれも失敗です。誰もそのパスを実際に辿っていないからです。本当の発見は連鎖でした。各リンクはコードの一行に紐づいています。アップロードは任意の型を受け付け、/uploads/*ルートは認証不要で、ディレクトリが一覧表示可能なためファイル名を列挙でき、ファイルはcontent-typeのままインラインで配信され、CSPはアップロードが置かれているのと同じオリジンを信頼している——という連鎖です。バイパスは不要でした。.jsファイルにコードを置き、SVGが<script src>でそれを読み込む。同一オリジンであり、まさに’self’が許可するものです。CSPは破られたのではなく、満たされたのです。そして最後まで実行されました。ペイロードは被害者のアカウント下にパーソナルアクセストークンを生成します。そのトークンは被害者のパスワードリセット後も、セッション無効化後も、さらには攻撃者をワークスペースから追い出した後でさえ有効です。そのキーはそもそも攻撃者のアカウントからは切り離されていなかったからです。curlを使って実際のビルドに対して検証した、完全なアカウント乗っ取りです。
「危険そうだ」という評価は、具体的な行を求めた瞬間に崩れ去ります。「悪用可能」とは、実際に辿っても成立するパスのことです。35,000のスターではそれを発見できませんでした。パスを歩くことが発見につながったのです。
アーキテクチャレベルの脅威における「正しさ」の基準
SASTが問うのは、ある行が誤って書かれているかどうかです。脅威モデリングが問うのは、すべての行が正しく書かれていても設計そのものが誤っていないかどうかです。一方は悪い構文を探し、もう一方は悪いアイデアを探します。
アーキテクチャレベルになっても「正しさ」の基準が消えるわけではなく、一段上に移動するだけです。欠陥はコンポーネント間の関係に宿るため、真実の単位はパスに変わります。「このパスは実際のビルドにおいて影響に到達するか」という問いです。最初の事例のアップロードの件では、脆弱な行は一行も存在しません。アップロードは任意の型を受け付け、ファイルは返却され、CSPが存在し、各行はそれ単体では正しい。アイデアそのものがバグなのです。
これが後半の問い——誰が「正しさ」の裁定者か——にも答えます。脅威モデラーでも、モデルでも、その場で最も経験豊富な人物でもありません。悪いアイデアは、誰かが影響まで辿り着くまでは仮説に過ぎません。裁定者はビルドであり、意見ではありません。
一点、正直に限界を認めます。アーキテクチャの欠陥すべてが再現しやすいわけではありません。証明を構築できる場合はそれが最高の基準ですが、できない場合でも基準が「信頼してほしい」に下がるわけではありません。具体的な攻撃者のパスと名前付きの前提条件を示し、懐疑的な人物が個々のステップに異議を唱えられる形にします。厳密さと意見の境界線は「curlを実行したかどうか」にあるのではなく、「特定のステップに誰かが反論できるかどうか」にあります。
ベンダーの「偽陽性が少ない」という主張を見抜く質問
罠は「率」という言葉にあります。提示される偽陽性の数値は、ベンダーが選んだコーパスで、ベンダーが調整した閾値で、デモの直前に測定されたものです。私は率を尋ねません。システムに作業過程を示させます。具体的にどのチェックを実行したか、そして私自身のコードのどの行でそれぞれのチェックが通過または失敗したかを確認します。
デモ用に調整されたシステムは単一パスです。コードを入力し、判定とスコアが出力され、そのスコアが製品です。私が信頼できるシステムは、それぞれが保持可能な成果物を残す別々のパスを実行します。まずそもそも何が問題になり得るか、次に「正しく実施された場合」がどのような状態かを個別のチェックとして示し、さらに各チェックを実際のコードに対して評価します——このチェックは通過、対象のファイルと行はここ。このチェックは不合格、欠けているものはここ。その連鎖は偽造できません。成果物が存在するかしないかだからです。
もう一つの見極め方があります。誤った場合、どちらの方向に壊れるかです。存在するコントロールを欠如していると判定しても、引用されたファイルで10分あれば確認できます。問題ないと言いながら実際には問題があれば、侵害につながります。私が信頼するシステムは前者の方向に失敗します。自分のシステムの2種類のエラーのうちどちらがコストがかかるかを考えたことのないCTOは、システムではなく数字を売っているのです。
分析レイヤーそのものを狙った敵対的攻撃への対応
これ以上ないほど真剣に受け止めています。それを示す方法は、攻撃者が勝つと仮定することです。モデルはインジェクション耐性を持てません。攻撃者が提供するテキストを読む確率論的な推論エンジンだからです。問題は、その操作が攻撃者に何をもたらすかであり、これはプロンプティングの問題（解決不可能）からアーキテクチャの問題（解決可能）へと移行します。
攻撃者の目的を二つに分けます。一つ目は検出結果を抑制すること、つまりレビュアーがバックドアをクリーンだと判定するようにコードを形成することです。それが解決済みとは言いません。しかし基準は「パスが再現されるか」であり、悪用可能でありながら無害として再現されるコードは書くのが困難です。システムがコントロールを確認できない場合、「確認してください」と言い、「問題ありません」とは言いません。また、このシステムは人間のレビューに取って代わるものではなく、その上に位置します。
二つ目の目的は実際の影響範囲が大きく、ほとんど誰も問わないものです。モデルを実行しているプロセスを乗っ取り、そのプロセスがクレデンシャルを保持しているためにピボットすることです。信頼されていないコードを読む部分は、すでに侵害されているものとして扱われます。そのパーツが保持するのはたった一つのクレデンシャル、すでに実行中のジョブ——攻撃者自身の作業のレビュー——にスコープされた一時的なキーだけです。別のテナント、別のジョブ、プラットフォームのキーには到達できません。プロバイダーへの呼び出しは信頼された側が仲介するため、生のクレデンシャルが敵対的な入力を読むボックスに触れることはありません。これは強制されています。クレデンシャルを含む変数がそこに現れた場合、ビルドチェックが失敗します。攻撃者はモデルとの議論に勝てる場合がありますが、その勝利をそもそも自分のものではなかったものへのアクセスに変えることはできません。
確率論的システムがセキュリティ判断に適さないという主張への反論
困難な部分は認めます。確率論的システムは完璧な防御を提供しません。そしておそらく、そうなるものは永遠に現れないでしょう。しかし決定論を求める主張は、私たちが頼りにしている決定論的なツールが、確率論的なものにはできないとされるセキュリティを実際に提供しているという前提に立っています。実際にはそうではありません。年1回のペネトレーションテスト、設計時の脅威モデル、SASTの実行で完璧な防御を得た人は一人もいません。これらも同じ基準で失敗しており、ただそのスケジュールに皆が慣れてしまっているだけです。
また、決定論が間違った軸に向けられています。スキャナーはパターンが存在するかどうかについては確実ですが、それが到達可能かどうかについては確実ではありません。本当に重要なことの代替指標について確信を持っているのです。
設計上の問題点について深く推論する能力は、かつては年1回のペネトレーションテストと脅威モデルにしか存在しませんでした。どちらもスナップショットであり、撮影した日は正確でも、その後のマージのたびに乖離していきます。その推論をすべてのプルリクエストに適用すれば、たとえ常にではなくほとんどの場合しか正しくなくても、「来年まで未検査」が「マージ前に検査済み」に変わります。
そして、どちらかを選ぶ必要はありません。PRごとのチェックはペネトレーションテスターがいない364日間をカバーし、その中でコインフリップに賭けているわけでもありません。発見は確率論的ですが、確認は確率論的ではありません。パスが実際のビルドで再現されるかされないかです。年1回のアーキテクチャレビューから出荷するすべての変更にレビューを実施するチームは、年1回のレビューの精度をいくら上げてもかなわない形でセキュリティ態勢を改善しています。これがトレードオフです。そして、その差は歴然としています。
翻訳元: https://www.helpnetsecurity.com/2026/06/16/oscar-andersson-oplane-ai-threat-modeling/
