サードパーティスクリプトはサプライチェーンリスク
サードパーティスクリプトは、あなたが書いていないコードであり、あなたが管理しない会社が配信し、あなたのページの中でユーザーのセッションとともに実行されます — サプライチェーンの言葉で言えば、リリースもレビューも通知もなしに、いつでも自らのコードを変えられる依存関係です。2026年10月、その抽象的なリスクは、報道によれば、具体的な損失になりました。主要な取引サイトが読み込んでいたパフォーマンス監視スクリプトが、ユーザーを流出させるために作られたものと交換されたのです。この記事は、報道された内容、SRIが実際に止めるもの、バージョンの固定がそのハッシュより先に来る理由、自前ホスティングがより良い答えになる場合、そして目録を正直に保つ短い監査ルーチンを辿ります。
報道されたPolymarketでの出来事
報道によれば、2026年10月29日、Polymarketの国際サイトは、ユーザーが口座から資金が流出していると報告した後、取引をキャンセルのみに切り替え、約1時間後に取引が再開されました。報道によれば、同社自身の声明はインシデントを侵害されたサードパーティプロバイダに帰し、この件は法執行機関に付託されたとし、影響を受けたユーザーを完全に補償すると約束しました。同社の10月30日のポストモーテムに基づく報道は、攻撃で取られた額を約270万ドル、取引停止による損失への善意の支払いを含めた総返金を390万ドルとしました。報道で引用された独立したオンチェーン分析は、数百のウォレットにわたって同様の数字、約270万ドルを追跡しました。これらの数字はいずれもここでは独立に検証されていません — それらは報道の数字であり、この記事もそのように扱います。
報道によれば、一般化できる部分はその仕組みです。報道で引用された研究者は、悪意のあるコードを、ウェブサイトパフォーマンスベンダーのリアルユーザーモニタリング（RUM）スクリプトに結び付けました — 訪問者のブラウザでページ読み込み速度を測ることだけが仕事の小さなファイルで、顧客ごとにベンダーのCDNから埋め込まれます。報道によれば、そのファイルはターゲットサイトのために特別に書かれたペイロードに置き換えられました。それはログイン済みセッション内で動作し、ページ内にすでに存在するサイト自身の取引機構を使い、ポジションと資金を攻撃者が管理する宛先へ移動させました。報道によれば、スマートコントラクトの欠陥も、盗まれたパスワードや秘密鍵も関与していません — 交換されたスクリプトは、ブラウザにとっては単にページそのものでした。その説明の細部が後の精査に耐えるかどうかは、教訓にとっては本筋ではありません。攻撃の形 — ベンダーファイル1つ、1回の交換、すべての訪問者による実行 — は、この種のインシデントの標準的な形です。
サードパーティスクリプトはあなたのコードだが、リリース手順は他人のもの
古典的なscriptタグにはサンドボックスがありません。ベンダーのCDNから読み込まれるコードは、あなた自身のバンドルと同じアクセス権であなたのオリジン内で実行されます。DOMを読み書きでき、入力中のフォーム値を読め、ユーザーのセッションであなたのAPIを呼べ、見つけたものをどこへでも送れます。サードパーティJavaScriptに関するOWASPのガイダンスは3つのリスクをはっきり名指します — クライアントアプリケーションの変更に対する管理の喪失、クライアントシステム上での任意コードの実行、第三者への機密情報の開示 — そして3つすべてがこの1つの事実から従います。あなたのレビュー手順、コードフリーズ、変更委員会はあなた自身のビルドで終わります。ベンダーのファイルは、ベンダーによって、ベンダーを侵害した攻撃者によって、あるいはドメインが失効した場合にそれを再登録した者によって編集され得ます。
その非対称性こそが、「このベンダーを信頼している」が統制ではない理由です。信頼は、今日誰のスクリプトを受け入れるかを決めます。明日そのURLが何を配信するかについては何も言わず、内容が変わったときに何の信号も与えません。機能する統制は、信頼を取り除くもの（ファイルを自分で配信する）、信頼を制約するもの（あらゆるスクリプトにできることとデータの送信先を制限するContent-Security-Policy）、あるいは読み込みのたびに機械的に検証するもの — それがSRIの役割です — です。目録から始めてください。あなたが持っていると知らないスクリプトには3つのどれも適用できません。そして、マーケティングタグ、サポートウィジェット、監視用埋め込みを数えれば、ほとんどのサイトは所有者の予想より多くのスクリプトを持っています。
SRIが止めるもの — そして止めないもの
Subresource Integrityはブラウザの仕組みで、W3Cが仕様化しMDNが文書化しています。ページはタグの integrity 属性に、期待するファイルの暗号ハッシュを宣言し、ブラウザは実際にダウンロードしたものをハッシュし、不一致があればファイルの実行を拒否します。クロスオリジンのファイルについては、タグに crossorigin="anonymous" も必要で、サーバーはCORSヘッダーを送らなければならず、そうしてブラウザはチェックを行うことが許されます。固定されたライブラリに適用すれば、SRIは静かな交換を大きな失敗に変えます。到着したファイルは、あなたがレビューしたファイルとバイト単位で同一か、まったく実行されないかのどちらかです。報道されたインシデントの監視スクリプトが、そのように読み込まれた固定ファイルだったなら、交換されたペイロードはユーザーのセッションで実行される代わりにチェックに失敗したでしょう — この条件法が主張の正直な形です。なぜなら、その特定の埋め込みがハッシュ可能だったかどうかは、動的な顧客別ファイルに関する問題であり、それこそが下記の難しいケースだからです。
SRIが止めないものも同じくらい重要です。内容が変わることが前提のスクリプト — タグマネージャーのコンテナ、パーソナライゼーションや同意のローダー、顧客別に生成されるファイル — には役立ちません。固定すべき安定したハッシュが存在しないからです。あなたがハッシュしたファイルを判断することもありません。忠実に配信されたスクリプトでも、設計上、詮索好きで、ずさんで、悪意があり得ますが、SRIは永遠に喜んでそれを検証します。他のスクリプトが実行時に注入するスクリプトはカバーせず、あなた自身のインフラから配信されるファーストパーティファイルも保護せず、実行された正当なスクリプトが収集するデータについても何もしません。SRIは1つの機械的な保証 — まさにこのバイト列、でなければ何もなし — であり、CSP、ベンダーレビュー、そしてそもそもセッションレベルのアクセスを得る第三者を最小化することの代わりではなく、それらと並んでその場所を獲得します。このサイトのセキュリティヘッダーチェックは、そのペアのCSP側を採点します。
バージョンを固定せよ、でなければハッシュは立たない
SRIには、悪意よりも多くの監査を失敗させる前提条件があります。URLは常に同じバイトを返さなければなりません。latest のアドレス、浮動するメジャーバージョン、あるいはベンダーが再生成する顧客別ファイルの上に固定されたハッシュは、ベンダーが最初に更新を出荷した時点で壊れるハッシュです。そして、自傷のSRI失敗に一度起こされたチームは、アドレスを直す代わりに属性を削除しがちで、ページを未測定より悪い状態に残します。恒久的な順序は逆です。まずURLを正確なバージョンを名指すものに変え（[email protected]、/v2.4.0/）、そのバージョンを一度レビューし、それからまさにそのファイルのハッシュを取ります。そうすれば、バージョンの引き上げは意図的なイベント — 新しいURL、新しいハッシュ、1つのコミット — になり、ユーザー経由で発見する環境の変化にはなりません。
固定にはコストがあり、正直さはそれを名指すことを求めます。固定されたライブラリはベンダーからの静かなセキュリティパッチを受けなくなるため、固定はリリースを追跡し意図的に引き上げる義務を生みます。それは、取り込んだ依存関係が持つ義務と同じです。それは扱える義務 — リリースノートとカレンダーのリマインダーでカバーできます — であり、それが置き換える代替案より厳密に優れています。その代替案では、更新はベンダーのペースでレビューなしに到着し、破損はあなたのペースで告知なしに到着します。このペアを1つの実践として扱ってください。固定が内容をアドレス可能にし、ハッシュが検証可能にし、監査がどちらも静かに腐っていないことを保証します — CMSの移行で編集されて消えたバージョン文字列は、欠けたハッシュと同じくらいありふれており、目で気付くのがわずかに難しいだけです。
自前ホスティングと、監査ルーチン
最も重要なスクリプトについては、より直截な選択肢があります。ファイルを自分で配信することです。自前ホスティングは、ベンダーのサーバー、アカウント、ドメインを実行時のサプライチェーンから完全に取り除き、通常のデプロイパイプラインにファイルのレビューとハッシュをさせ、ベンダーのCDNが動かないときにも動き続けます。トレードオフは実在します — ベンダーのエッジキャッシュと自動更新を手放し、そのセキュリティ修正を自分で出荷する義務を引き受け、一部のベンダーのライセンスや顧客別生成ファイルはそもそもそれを許しません — したがって、賢明な分割は重要度によります。機密なページの小さな固定ライブラリは自前ホスティングし、CDNに残るものは固定してハッシュし、固定もホスティングもできない動的タグはガバナンス（公開制限、変更レビュー、CSP）で統治し、誰も正当化できないスクリプトは見つけ次第削除します。削除したスクリプト1つごとに、あなたがもう持たないサプライチェーンが1つ減ります。
これを真実に保つルーチンは、実際に実行できるほど短いものです。四半ごとに — そして再設計、CMS移行、新しいベンダーのたびに — 主要なページテンプレートに対してサードパーティスクリプト＆SRI監査を実行してください。それは静的HTMLが参照するすべてのスクリプト、どれがサードパーティか、どれに完全性が欠けているか、どれが固定されていないかを一覧にし、取得できる最初の不足ハッシュについて貼り付け可能なsha384を計算します。影響の順に修正し — セッション、支払い、個人データのページを最初に —、次に SSLグレーダーとヘッダーチェックで伝送層とヘッダー層を確認し、最後にタグマネージャーで締めくくります。そこでは実行時に注入されるスクリプトを静的監査は見られません。その公開者リストと変更履歴を、デプロイログに与えるのと同じ疑いをもってレビューしてください。四半ごとに15分 — 報道されたケースでは約1時間で数百万に上ったインシデントクラスに対してです。