Polyfill.io ドメイン所有権とウェブサイトの説明責任

要約

cdn.polyfill.ioを読み込んだサイトは、単にオープンソースプロジェクトを引用する以上のことを行っていた。それは、ライブリモートサービスが JavaScript を選択し、サイトのブラウザコンテキストで実行するために返すことを許可していた。したがって、信頼オブジェクトには、ドメイン、オペレーター、ルーティング、応答パスが含まれ、他の場所で検査できるソースコードだけではなかった。[15][16][17]
Polyfill.io ドメインと関連プロジェクトのプレゼンスの管理は2024年2月に変更された。Fastly、Cloudflare、FormatJS プロジェクトの issue がその時対応し、悪意のある配信が6月に公に報告される前に下流での再評価が可能であったことを示している。移管自体は悪意の証拠として記述されるべきではない。[2][3][4]
Sansec は6月25日、このサービスが選択的に修正された JavaScript を返し、該当する訪問者をリダイレクトしていたと報告した。Cloudflare は Page Shield の指標が6月8日からの一致を含んでいたと述べ、Akamai はサーバー側サンプリングとそれに続くクライアント側チェックを説明した。これらの観察はリダイレクトキャンペーンを立証するものであり、リモートで JavaScript を供給するあらゆるアクションが理論的に実行可能であるというわけではない。[1][5][9]
Sansec の推定10万以上のサイトという数字は、同サービスを埋め込んだり使用したりしているサイトを指している。Cloudflare は使用率がウェブサイトの約4%に近いと述べた。どちらの数字も、悪意のあるブランチを提供した、訪問者をリダイレクトした、または損失を被ったウェブサイトの確認済み数ではない。[1][5]
Cloudflare による自動書き換えと Namecheap によるドメインの保留は配信経路を制約した。これらは下流コードから古い参照を削除したわけではなく、以前のすべての訪問者が受け取ったものを確定させたわけでもなく、各ウェブサイト所有者の調査を完了させたわけでもない。[5][6][10]
Fides、Jellyfish、Wordfence は3つの異なる証拠タスクを示している：条件付きパスが到達可能かどうかを判断する、推移的ベンダーを追跡する、削除を確認する、そしてエンドポイントへの参照を悪用の証拠として扱わないこと。[11][12][13][14][22]
ここでの説明責任は法的結論でも平等な責任の主張でもない。すべての当事者が実際に行使できる管理に対して責任を負うべきであるという意味である。ウェブサイト所有者は、必要性、インベントリ、プロバイダー選択、セルフホスティング、所有権監視、ブラウザ側観察、調査、修復、コミュニケーションに対する管理を保持していた。

スクリプトタグは委任された権限であり、単なる便利さではない

中心的な技術的決定は普通に見えた。ウェブサイトはページにscript要素を配置し、それをcdn.polyfill.ioに向けた。訪問者がそのページを読み込むと、ブラウザはリモートサービスに JavaScript を要求した。サービスはリクエストの特性を検査し、ブラウザに適したポリフィルを提供することができ、古いブラウザがネイティブに実装していないウェブ機能を使用できるようにした。

この取り決めは実用的な互換性問題を解決した。すべての互換関数をすべての訪問者に送信する代わりに、サイトは専門サービスに特定のブラウザが必要と思われるものを返すよう依頼できた。結果はユニバーサルローカルバンドルよりも小さく、保守が容易になる可能性があった。しかし、その効率性は応答を動的に保つことから来ていた。ウェブサイトは開発中に固定パッケージをダウンロードし、レビュー済みのバイトを自社インフラから配備したわけではなかった。別のオペレーターに、ページ読み込み時にどのバイトを訪問者が実行するかを決定させるよう招いていた。

この区別が説明責任の枠組みを決定する。オープンソースリポジトリは検査可能なコードと履歴である。ホステッドサービスは運用関係である。ライブサービスはドメイン、DNS、ルーティング、ホスティング、証明書、デプロイアクセス、そして応答を変更できる人物や組織に依存する。ウェブサイトは公開コードを信頼しながらも、訪問者に提供するエンドポイントが同じ管理下にあり、同じプロセスに従い、同じ種類の出力を返すかどうかを検査することを怠る可能性がある。

HTTPS はこれらの疑問を解消しない。ブラウザが要求されたドメインの有効な権限保持者に到達したことを認証し、転送中の応答を保護するのに役立つ。ドメイン保持者が変わっていないこと、返されるプログラムが善意であること、あるいはコンテンツがリクエスト間で不変であることを約束するものではない。ドメイン管理が正当に変更された場合、HTTPS は設計通りに機能し続け、新しい運用実態を認証することができる。

ブラウザはリモートで読み込まれた JavaScript に、そのページに対する広範な実質的影響力を与える。正確な範囲はページとブラウザの制御に依存するが、基本的な弱点はよく確立されている：サードパーティの機能はファーストパーティのウェブコンテキスト内で実行される。MITRE の CWE-830 はこの種の包含を別のドメインからのコードへの信頼の移転として説明し、OWASP はサードパーティ JavaScript をガバナンス問題として扱っている。GitHub CodeQL のガイダンスは信頼されていないドメインから読み込まれた機能に同じ論理を適用している。[15][16][17]

だからこそ、このインシデントを「オープンソースが危険になった」と単純化すべきではない。元のオープンソースコード、レビュー済みのセルフホストコピー、ライブドメイン管理サービスはそれぞれ異なる信頼オブジェクトであった。固定ローカルコピーを使用するウェブサイトは、cdn.polyfill.ioから変化する応答を要求するウェブサイトと同じランタイム委任を行っていなかった。代替ホストも、同じプロジェクトから派生したコードを提供していても、異なる運用関係を生み出していた。

したがって、最初の説明責任の問いは、開発者がすべての外部ライブラリを信頼すべきでないかどうかではない。それは、ウェブサイトが使用時にどの当事者が訪問者のために実行可能バイトを選択できるかを知っていたかどうかである。有用なインベントリは少なくとも5つの質問に答えるだろう：どのページがスクリプトを要求したか、包含が直接的か推移的か、どのユーザーとブラウザパスが到達可能か、どのビジネス機能が必要としたか、そして現在誰がエンドポイントを管理しているか。

これらの質問はウェブサイト所有者に属する。なぜなら、ウェブサイトが包含を有効にしたからである。訪問者は Polyfill.io と交渉したり、そのオペレーターを選択したりしなかった。訪問者はウェブサイトからページを要求し、返されたスクリプトをそのページの一部として合理的に経験した。テーマ、プラグイン、タグマネージャー、ベンダーが参照を挿入した場合でも、下流組織はユーザーに複合体験を提供する当事者であり続けた。

これはウェブサイト所有者を悪意のあるコードの作者にするものではなく、サービスオペレーターの制御を消去するものでもない。委任された力がファーストパーティの説明責任を排除しないことを意味する。サービスオペレーターは応答を選択できた。ウェブサイト所有者はそのオペレーターがページに留まるかどうかを選択できた。これらは異なる制御であり、インシデントは両方をテストした。

2月の移管はソフトウェアガバナンスイベントであった

公開された時系列は異常に重要な警告間隔を提供する。2024年2月、Polyfill.io ドメインと関連 GitHub プレゼンスの管理が Funnull に移った。情報源は管理と信頼基盤の変更を立証している。それらは、その事実だけで、新しいオペレーターの動機、犯罪計画、法的違反、あるいは後に配信に影響を与えたすべての人物の最終的な身元を立証するものではない。

従来の情報提供ウェブサイトにとって、ドメイン移管は主に公開権限を変更する可能性がある。他のウェブサイトに実行可能 JavaScript を返すドメインにとって、移管はそれらの下流ページ全体で実行されるソフトウェアに誰が影響を与えるかを変更する。これにより、所有権情報は依存関係状態の一部となる。エンドポイントの新しい所有者は、ソースリポジトリが見慣れたものであっても、運用上は新しいメンテナー、署名権限、リリースチャネルに匹敵する。

Fastly の2月28日の通知はガバナンスの重要性を可視化している。代替ドメインを発表し、移行、セルフホスティング、またはサービスの削除を含むオプションをユーザーに提供した。これらのオプションは単なるブランディングの代替ではなかった。それぞれが訪問者に配信されるバイトを誰が管理するかを変更した。移行は異なるサービス関係を選択した。セルフホスティングは配信をウェブサイト自身のデプロイ管理下に置いた。削除は不要になった場合の互換性依存を排除した。[3]

Cloudflare は2月29日に cdnjs ホストの代替案で続いた。その説明はプロバイダー移行をサプライチェーンリスクに結びつけた：ウェブサイトは、ページ内でコードを実行できるサービスを維持し保護するために別の当事者に依存していた。Cloudflare の代替案はサードパーティホスティングをリスクフリーにしたわけではないが、インフラプロバイダーが所有権変更を新たな信頼決定の根拠として理解していることを示した。[2]

2月28日に開かれた FormatJS の issue は、同時期の下流プロジェクト記録を提供する。所有権と CNAME 関係に関する懸念を提起し、プロジェクトにエンドポイントの推奨を停止するよう求めた。この記録が重要なのは、公に報告された悪意のあるキャンペーンの前にメンテナーがドキュメント依存関係に基づいて行動したことを示しているからだ。推奨を削除しても、以前にそれに従ったすべてのウェブサイトを修復するわけではないが、将来の伝播を制限し、追跡可能な警告を生み出す。[4]

これらの記録は、下流所有者が6月25日まで何の信号も持っていなかったという過度に便利な物語を防ぐ。すべてのサイト所有者が Fastly の通知、Cloudflare の投稿、FormatJS の issue を見たわけではない。情報源は普遍的な通知を立証しておらず、公開可能性をすべての組織が実際に知っていたという証明に変換するのは不公平であろう。しかし、所有権変更が観察可能であり、代替案が利用可能であり、一部の責任ある当事者がインシデント報告の数ヶ月前にエンドポイントを再評価したことを立証している。

その区別は説明責任に不可欠である。監視の義務は全知を意味しない。高い権限を持つ依存関係に対して関連する変更を受け取ることができるプロセスを設計することを意味する。サイトはパッケージアドバイザリを追跡しながら、ドメイン所有権、DNS、ホスティングの変更を無視するかもしれない。バージョン管理されたパッケージの場合、リリースと脆弱性フィードが重要なシグナルである可能性がある。リモートスクリプトエンドポイントの場合、登録、DNS、オペレーター、応答動作も監視モデルに属する。

2月のイベントは、一度限りのベンダーレビューの限界も明らかにする。チームは何年も前に、オペレーター、インフラ、プロジェクトの評判、その時のブラウザニーズに基づいて Polyfill.io を承認したかもしれない。承認記録にcdn.polyfill.ioという文字列だけが含まれていた場合、チームは URL が変わらない限り依存関係は不変であると誤って扱う可能性がある。実際には、安定した名前の背後にある当事者が変わっていた。

説明責任のある承認は、アドレスだけでなく信頼の根拠を記録すべきである。その根拠には、オペレーター、サービスの目的、期待される応答特性、契約上またはコミュニティ上の関係、利用可能な監査証拠、フォールバック計画、レビュートリガーが含まれる。所有権の移管は、承認を無効にするか、少なくとも再開させるだろう。そのような記録がなければ、組織は前提が変わった後もなぜ委任が正当化され続けたかを容易に説明できない。

必要性の問いも再開されるべきであった。ポリフィルはブラウザの能力に結びついている。ブラウザ人口は進化し、製品サポートポリシーは変化し、かつて不可欠だった互換性コードは残存する可能性がある。ページレベルの権限を持つリモート依存関係は、誰もその削除を所有していないという理由だけで存続すべきではない。2月の通知は、古いブラウザサポートが依然としてエンドポイントを必要とするかどうか、より小さなローカルバンドルが残りのニーズを満たせるかどうかを問う瞬間を提供した。

これらは、参照を保持しているすべてのサイトが過失で行動したことを証明するものではなく、ドメイン移管自体を攻撃に変えるものでもない。それはより狭い点を立証する：有害な出力が観察される前でも、移管は重要なソフトウェア管理を変更した。ウェブサイトの説明責任は、その重要な変更が検出可能でレビュー可能であったかどうかから始まる。

選択的配信により、カジュアルな検査は信頼性を失った

6月25日、Sansec はcdn.polyfill.ioがそれを埋め込んだウェブサイトを通じて修正された JavaScript を配信していたと報告した。観察された行動は、選択された訪問者を Google Analytics を模倣するように設計されたドメインを通じて、詐欺や賭博の宛先にリダイレクトするものだった。Sansec はモバイルターゲティング、サーバー側とクライアント側のチェック、時間ベースの行動、一部の管理者や分析コンテキストの回避を含む条件を説明した。[1]

観察された行為には正確な名詞が必要である。それは、修正された JavaScript を通じて配信されたリダイレクトキャンペーンであった。記録は、その観察を資格情報の盗難、ページデータの盗難、ホストの侵害、ブラウザ外のコード実行、または定量化された金銭的損失に格上げすることを支持しない。リモートで制御されるスクリプトエンドポイントは、原理的にははるかに広範囲のブラウザアクションが可能な JavaScript を返すことができる。CNCF TAG Security、CWE-830、一般的なブラウザ実行モデルはその能力の結論を支持する。能力は、可能な各行動が発生したという証拠ではない。[8][16]

Cloudflare は Page Shield データが指標を裏付け、6月8日からの一致を含んでいたと述べた。これは Cloudflare のデータセットで説明された最も早い一致である。すべての悪意のある活動がその日に始まったこと、同じブランチが継続的にすべてのサイトに届いたこと、あるいは Cloudflare の可視性の範囲外でそれ以前の配信がなかったことの証明ではない。[5]

Akamai は別途、リクエストヘッダーに基づくサーバー側選択が何を送信するかを決定し、その後にクライアント側チェックがリダイレクトの前に行われる2段階パターンを説明した。このアーキテクチャは、なぜ通常の検査が問題を見逃す可能性があるかを説明している。デスクトップブラウザからスクリプトを要求する開発者は、期待されるポリフィルを受け取るかもしれない。異なるヘッダー、場所、タイミング、ページ状態を持つモバイル訪問者は、別のブランチを受け取ったり活性化したりするかもしれない。[9]

選択的配信は証拠の負担を変える。単一のクリーンダウンロードは過去の安全性を証明しない。ある時点の1つのブラウザからのソースコード比較は、そのリクエストに対して選択された応答のみを示すかもしれない。検索エンジンクローラー、アップタイムモニター、セキュリティスキャナーは、配信ロジックによって意図的に除外された特性を持つかもしれない。ログイン中にテストする管理者は、初回訪問者とは異なる行動を見るかもしれない。

これは検出が不可能だったことを意味しない。監視は依存関係の変動性に一致しなければならなかったことを意味する。有用な観察は、ブラウザ、デバイス、場所、リクエスト条件をサンプリングし、応答本文とハッシュを経時的に保存し、新しいドメインとリダイレクトチェーンを検出し、実際のクライアントが見た行動をサービスの表明された目的と比較する。結果的なプログラムがブラウザで組み立てられ実行されるため、クライアント側監視は重要な役割を担っていた。

このインシデントは、最適化がどのようにカモフラージュになり得るかも示している。動的ブラウザターゲティングは Polyfill.io の正当なサービスモデルの一部だった：サービスはブラウザの能力に応じて互換性コードを選択した。悪意のあるブランチは、応答が自然に異なるという期待を利用することができた。変動性自体は悪用の証明ではなかった。単純な「既知のハッシュ = 安全なサービス」モデルを適用しにくくし、選択的配信が受け入れられた運用パターン内に隠れる余地を与えた。

したがって、説明責任は期待される変動性を定義することに依存する。ウェブサイトは、プロバイダーが正当に使用するリクエスト属性、返される可能性のあるコードファミリー、スクリプトが連絡する可能性のある宛先、目的外のページアクションを明示できるべきである。そのベースラインがなければ、監視は変化を観察しても、その変化が許可されているかどうかを知ることができない。

サーバー側サンプリングは遡及的調査も複雑にする。サイトの静的リポジトリにはスクリプト URL のみが含まれ、訪問者が受け取った悪意のあるバイトは含まれないかもしれない。バイトはリクエスト時に別のシステムから提供され、封じ込め後は利用できなくなるかもしれない。ブラウザテレメトリ、CDN ログ、保存された応答、コンテンツセキュリティレポート、エンドポイント記録だけがリーチを再構築するための唯一の証拠かもしれない。これらの記録が決して収集されなかったり、短期間しか保持されなかったりした場合、サイトはどの訪問者がブランチに遭遇したかを答えられないかもしれない。

その不確実性を、誰もが安全だった、または全員が侵害されたという広範な主張で隠すべきではない。説明責任のあるインシデント声明は、代わりに何が見つかったかを定義できる：エンドポイントが参照されていた；特定の条件付きパスが到達可能であったか、または到達可能でなかった；テレメトリは特定の日付と人口をカバーしていた；観察されたリダイレクトは既知の指標と一致した、または一致しなかった；そして保持された証拠の範囲外のリクエストについてはギャップが残る。

選択的配信は、したがって責任テストの中心である。それは、有害な出力が良性の検査とどのように共存し得るか、なぜエンドポイント参照が被害者数ではないか、なぜ検証済み修復にはドメインが停止された後に一度ページを読み込むだけでは不十分かを説明する。

規模の推定は被害者数ではなかった

Sansec は10万以上のサイトがサービスを埋め込んだり使用したりしていると説明した。Cloudflare は Polyfill.io がウェブサイトの約4%に出現するという推定を引用した。これらの数字は広く再利用されたサービスの潜在的な広がりを伝えている。それらは同じ分母を共有しておらず、確認された侵害の完全なセットを確立するものでもない。[1][5]

いくつかの母集団は区別されなければならない。1つは、現在または過去のコードが Polyfill.io エンドポイントを参照したウェブサイトのセットである。別のものは、関連する包含パスが本番環境で到達可能であったセットである。3つ目は、キャンペーン中に悪意のある応答を要求したセットである。4つ目は、訪問者がサーバー側とクライアント側の条件を満たしたセットである。5つ目は、実際にリダイレクトされた訪問者である。6つ目は、後に測定可能な損失を被った人口である。

入手可能な公開記録は、これらのグループのほとんどについて確認された数を提供していない。したがって、すべての参照を被害者と呼び、すべての包含サイトを侵害されたと呼び、すべての訪問者を露出されたと呼ぶのは不正確であろう。選択的配信が普遍的な観察を妨げたという理由だけで、参照を無害として却下することも同様に不正確であろう。参照は信頼パスを確立する。到達可能性、配信、影響を確立するためには追加の証拠が必要である。

この語彙は下流通知にとって重要である。「私たちのコードに参照が含まれていた」と「私たちのテレメトリはスクリプトが要求されたことを示している」は異なる。両方とも、「私たちは悪意のあるブランチを観察した」や「訪問者がリダイレクトを報告した」とは異なる。これらを組み合わせると、不必要な警報や誤った安心感を生む可能性がある。それらを分離することで、ユーザーは組織が何を知っているかを理解できる。

Wordfence による影響を受けた WordPress プラグインパターンの扱いは、この境界を強化している。そのカタログは Polyfill.io の使用を特定したが、すべてのプラグインインスタンスが悪意のあるコンテンツを配信したと仮定することに対して警告した。プラグインは多くのサイトにエンドポイントを導入する可能性があり、インベントリ作業を緊急にさせる一方で、コードの存在は各インストールでの悪意のある実行を証明するにはまだ不十分だった。[14]

政府の報告は深刻な規模の懸念を繰り返しながら、運営者に削除と調査に集中するよう促した。CERT-AGID は買収とヘッダー依存の配信を説明し、10万以上の数字に言及した。その独立した警告は広範な防御的注意を支持するが、分母を確認された影響を受けた訪問者に変えるものではない。[21]

したがって、最も強い規模の声明は最も限定されたものでもある：エンドポイントには大きな下流フットプリントがあり、観察された選択的キャンペーンはそのフットプリント全体にリスクを生み出した。正確な影響はサイトごと、訪問者人口ごとに確立されなければならなかった。

封じ込めは経路を変えたが、修復を完了しなかった

対応にはさまざまな種類の管理を持つ当事者が関与した。Cloudflare はプロキシされた顧客ページ上の Polyfill.io 参照を Cloudflare ホストのミラーに自動的に書き換えた。同社は、単に元のドメインをブロックすると、まだサービスに依存しているサイトが壊れる可能性があると説明した。書き換えは、変更されたエンドポイントへの即時依存を削除しながら、期待される互換性を維持しようと試みた。[5]

その介入は実際の運用トレードオフを示している。セキュリティチームは疑わしいリソースの即時削除を好むことが多い。プロダクトチームは、互換性レイヤーを突然排除すると、一部の訪問者にとってサイトが使用できなくなる可能性があることを知っている。配信チェーンにおける Cloudflare の位置は、すべてのウェブサイト所有者が変更をデプロイするのを待たずに、異なるソースを代用することを可能にした。

代用は封じ込めであり、完全な修復の証明ではなかった。それはメカニズムでカバーされるトラフィックに対して信頼できるオペレーターと応答パスを変更した。すべてのブラウザに対して代替が同一の動作を持つこと、すべてのページと配信パスがカバーされたこと、下流リポジトリに古い参照がもはや含まれていないことを確立したわけではない。また、書き換えの前に訪問者が何を受け取ったかについても答えなかった。

その後 Namecheap は Polyfill.io ドメインを保留し、政府の勧告はエンドポイントが6月27日までに停止されたと説明した。ドメインレベルの行動は即時のサービスパスを削除したが、まだ応答を期待しているサイトを壊す可能性もあった。保留はレジストラが持っていた重要な封じ込めレバーであった。下流のテンプレート、プラグイン設定、キャッシュされたページ、タグマネージャー設定、ベンダー製品をクリーンアップしたわけではない。[6][10]

ドメインが利用できなくなると、違いはより明確になる。ブラウザが疑わしいスクリプトを取得できなくなるため、サイトは保護されているように見えるかもしれない。しかし、古い参照は未解決の依存関係として残る。管理状況が再び変わったり、代替ホスト名が持続したり、内部コピーが検査されなかったりすると、根本的なガバナンス問題は残る。永久に死んだエンドポイントでさえ、パフォーマンス、エラーハンドリング、互換性コストを課す可能性がある。

CERT-FR と西オーストラリア州サイバーセキュリティユニットは、運営者に参照を特定して削除し、必要な場合は管理された代替に移行し、Subresource Integrity や Content Security Policy などのブラウザ制御を検討するよう助言した。Semgrep も同様に、ドメイン停止を十分と見なすのではなく、リポジトリ全体の検出に焦点を当てた。[6][7][20]

そのシーケンスは4つの異なる閉鎖主張を示唆している。「封じ込められた」は、既知の有害な配信パスが中断されたことを意味する。「削除された」は、下流参照と推移的挿入パスがなくなったことを意味する。「調査された」は、利用可能な証拠を使用して歴史的なリーチと影響を評価したことを意味する。「検証された」は、テストと監視が現在のサイトがもはや古いパスに依存しておらず、代替が意図された範囲内で動作することを示すことを意味する。

ウェブサイト所有者は最初の主張をインフラプロバイダーに依存しつつ、他の3つを自ら所有することができた。Cloudflare はそれが見たトラフィックを書き換えることができた。Namecheap はそれが登録したドメインを停止できた。どちらも、顧客が URL を埋め込んだすべての場所、プラグイン内のすべての条件付きブラウザパス、あるいはウェブサイトが調査する必要があるすべての訪問者人口を知ることはできなかった。

この分離はまた、サードパーティの介入を誇張することを防ぐ。レジストラの保留は属性判断ではない。自動書き換えは、保護されたすべての顧客が悪意のあるブランチを提供したことを確立するものではない。検出ベンダーの指標一致は、各サイトの完全なフォレンジックレポートではない。各行動は、それが行使した制御とそれが生み出した証拠に従って説明されるべきである。

運用上、下流の修復は完全な検索から始まるべきである。リテラルなホスト名は、ソースファイル、生成されたバンドル、コンテンツ管理フィールド、プラグインコード、タグマネージャー、テンプレート、アーカイブされた設定、ベンダー応答に現れる可能性がある。検索ツールは既知の文字列を見つけることができるが、依存関係インベントリは誰が参照を導入したか、どのビルドまたはランタイムパスがそれをアクティブにしたかも説明しなければならない。

削除には機能的な決定が必要である。ポリフィルがもはや不要であれば、それを排除することが権限の最もクリーンな削減である。レガシーブラウザサポートが依然として必要な場合は、レビュー済みのローカルバンドルか明示的に承認されたプロバイダーが適切かもしれない。代替は、その URL が便利だからという理由だけで選ばれるべきではない。そのオペレーター、更新プロセス、応答変動性、監視モデルが新しい信頼基盤の一部となる。

最後に、歴史的評価にはサイトのリスクに比例した証拠が必要である。ブラウザ側の観察、ネットワークログ、セキュリティレポート、顧客からの苦情、保存されたスクリプト応答は、既知のリダイレクト指標が現れたかどうかを判断するのに役立つかもしれない。証拠の欠如はカバレッジに関連付けられるべきである。クライアントテレメトリを保持していないサイトは、利用可能な記録に報告や指標が見つからなかったと言えるが、記録の欠如を訪問者がブランチを受け取らなかった証明に変換することはできない。

Fides は条件付きブランチがなぜ依然として重要かを示した

CVE-2024-38537 は Fides における下流の問題を記録している。関連するfides.jsパスはレガシーブラウザ向けに Polyfill.io を読み込む可能性があった。記録は影響を受けるバージョンを特定し、バージョン2.39.1が露出を削除したと述べている。また、Fides を通じた悪用は確認されていないという重要な境界も保持している。[11][12]

そのケースは、2つの反対の誤りに抵抗するため有用である。1つ目は、古いブラウザパスだけがエンドポイントを読み込むという理由で問題を却下することである。条件付き到達可能性は依然として到達可能性である。本番ページがサポートされている訪問者人口のためにリモート JavaScript を要求できる場合、その依存関係はほとんどの開発者がそれをトリガーしなくても、製品のセキュリティインベントリに属していた。

2つ目の誤りは、CVE を Fides ユーザーが悪用された証拠として扱うことである。脆弱性記録は、危険な包含パスと影響を受けるバージョンを確立できるが、悪意のあるブランチが特定のデプロイに到達したことを確立するわけではない。「読み込む可能性があった」と「悪用が観察された」は異なる質問に答える。Fides の記録はその区別を明示的に維持した。

修復はまた、バージョン管理された修理がなぜ重要かを示している。名前付きリリースでリモート依存を削除することで、下流オペレーターに具体的な行動と追跡可能な境界が与えられる。彼らはデプロイされたバージョンを特定し、アップグレードし、残りの参照をスキャンし、レガシーパスをテストできる。Polyfill.io に注意するようにという一般的な警告は、同じ閉鎖証拠を提供しないだろう。

レガシー条件は検証を形成すべきである。最新のデスクトップブラウザのみをテストしても、影響を受けるブランチが実行されないかもしれない。検証は、元々それを選択した条件を再現または検査する必要がある。これには、バンドルされたコードのレビュー、古いユーザーエージェントのシミュレーション、ネットワークリクエストの確認、修理されたバージョンがエンドポイントを構築または要求しなくなったことの確認が必要になるかもしれない。

SingCERT の速報も下流の Fides ケースについて議論し、悪用が観察されていないという境界を保持した。国家 CERT による繰り返しは問題の可視性を高めるが、可能性を観察された悪用に変換するものではない。[22]

したがって、Fides の教訓は、すべての条件付きサードパーティリクエストが同じ重大度に値するということではない。それは、メンテナーが条件、影響を受けるバージョン、到達可能な人口、修復バージョン、証拠の境界を知るべきであるということである。説明責任は、何が起こり得るかと何が観察されなかったかの両方を形式的な脆弱性記録が述べるときに最も強くなる。

Jellyfish は推移的依存関係を追跡する方法を示した

Jellyfish の勧告は異なるパスを文書化した。そのサービスは、特別な条件下で Polyfill.io を読み込む可能性のあるベンダーに依存していた。Jellyfish は推移的関係を特定し、ベンダーに連絡し、削除を確認し、そのパスに到達した可能性のあるブラウザ人口をスコープした。[13]

このシーケンスは、非難ではなくアーキテクチャから始まるため、実用的なモデルである。顧客対応組織は、自社のリポジトリに直接スクリプトタグを配置していないかもしれない。参照は、分析コンポーネント、同意ツール、プラグイン、サポートウィジェット、または別のベンダーのコードから来る可能性がある。ラインの直接所有権は、ユーザー体験に対する制御と同じではない。

推移的依存関係は証拠問題を生み出す。ビルド時にインストールされるパッケージを対象としたソフトウェア部品表は、ベンダーがブラウザ内で動的に要求するドメインを含まないかもしれない。契約インベントリはベンダーを挙げるが、ベンダー自身のスクリプト供給業者は挙げないかもしれない。ネットワーク監視はホスト名を見るが、それを導入したビジネスオーナーを特定しないかもしれない。リクエストを説明責任のある関係に結びつけるには、3つのビューすべてが必要である。

Jellyfish の対応シーケンスはこれらのギャップに対処する。第一に、依存関係が存在し、それが呼び出される条件を特定する。第二に、それをベンダー関係にマッピングする。第三に、コード制御を持つ当事者に削除を依頼する。第四に、ベンダーの保証を問題の終わりとして扱うのではなく、変更を検証する。第五に、利用可能な最良のブラウザと製品証拠を使用して人口をスコープする。

検証は特に条件が異常な場合に重要である。ベンダーは可視参照を削除する一方で、フォールバック、古いバンドル、キャッシュされたアセットにまだ含まれている可能性がある。顧客は内部確認を受け入れるだけでなく、外部からテストすべきである。関連するブラウザ間でのネットワークキャプチャ、リポジトリまたはバンドルスキャン、クライアント側監視は、リクエストが実際に消えたかどうかを示すことができる。

スコープされた人口は分母を保持すべきである。特定のブラウザバージョンやページフローのみがベンダーパスをトリガーできる場合、調査は潜在的なリーチを狭めることができる。それは、そのブラウザグループのすべてのメンバーが悪意のあるコンテンツを受け取ったことを暗示すべきではない。逆に、パスが稀であるからといって、それを削除しない言い訳にはならない。稀なパスは日常的なテストを受けることが少なく、依存関係が気付かれずに存続する魅力的な場所になり得る。

Jellyfish はまた、共有されているが代替不可能な責任を示している。ベンダーは自身のコードを管理し、包含を削除できた。Jellyfish はベンダーエスカレーション、顧客対応調査、修復の受け入れを管理した。インフラとセキュリティプロバイダーはテレメトリを提供できた。これらの当事者は互いに完全に代用することはできなかった。

そのモデルはこのインシデントを超えて拡張可能である。下流組織は、実行可能コードを導入できるすべてのベンダーに対するエスカレーション経路を必要とする。契約または技術オンボーディングプロセスは、緊急の依存関係の質問に誰が答えられるか、サードパーティスクリプトをどのくらい早く無効にできるか、どのログが利用可能か、顧客が変更をどのように検証できるかを特定すべきである。

WordPress プラグインは参照と悪用を分離すべき理由を示した

Wordfence は様々な WordPress プラグインパターンにわたる Polyfill.io の使用をカタログ化した。この種のインベントリは、プラグインが1つの外部依存関係を多くの独立して運営されるウェブサイトに分散させる可能性があるため価値がある。小さなメンテナーの決定が、各サイト所有者が意識的にエンドポイントを追加することなく、広範な下流信頼関係になる可能性がある。[14]

カタログはまた重要な警告を伴っていた：エンドポイントの使用は、すべてのプラグインやサイトが悪意のあるコンテンツを配信したことを証明するものではなかった。参照は潜在的な実行パスを特定した。そのパスがアクティブかどうかは、プラグインバージョン、設定、ページレンダリング、キャッシング、ブラウザ条件、その時のリモート応答に依存していた。

WordPress サイト所有者にとって、正しい対応は、プラグイン作者かサービスオペレーターのどちらが「本当の」責任当事者かを議論することではない。当面のタスクはローカルである：インストールされアクティブなバージョンを特定し、どのページが参照をレンダリングするかを判断し、影響を受けるコンポーネントを更新または削除し、必要に応じて生成されたアセットをクリアし、公開サイトのネットワーク動作を検証する。

プラグインメンテナーは異なるタスクセットを持つ。依存関係を削除し、修正版を公開し、影響を受ける条件を説明し、ドキュメントを更新し、ユーザーに通知できる。プラグインリポジトリまたはセキュリティサービスは警告を配布できる。ウェブサイト所有者は依然として変更をデプロイしなければならない。インストールされていない修正リリースはブラウザパスを変更しない。

これは、規模の数字が被害を受けた組織の数として読まれるべきではないもう一つの理由である。1つのプラグインが数千の参照を作成する可能性がある。1つのサイトが同じホスト名を持つ複数のプラグインを含む可能性がある。休止中または無効なプラグインはスクリプトをレンダリングせずにディスクに残る可能性がある。キャッシュされた公開ページはソースコードの変更後も古い参照を提供し続ける可能性がある。文字列、インストール、アクティブなリクエスト、悪意のある配信を数えると、異なる数字が生成される。

説明責任のあるエコシステムは、これらの測定値にラベルを付けたままにする。セキュリティインテリジェンスは行動を加速するために広範な露出リストを公開できる。メンテナーは影響を受けるバージョンを明記できる。サイト所有者はデプロイされた到達可能性を報告できる。インシデント調査員は観察された指標を報告できる。どれも他のものから確実性を借りるべきではない。

SRI と CSP は制御であり、魔法の答えではなかった

Subresource Integrity（SRI）は、ページ作成者が外部リソースの暗号化ダイジェストを提供することを可能にする。対応ブラウザはリソースを取得し、返されたバイトが期待されるダイジェストと一致しない場合、実行を拒否できる。W3C の仕様と MDN の実装ガイダンスは、SRI を、侵害されたサードパーティホストが、包含サイトが固定されたままであると期待するリソースを黙って変更するのを防ぐ方法として提示している。[18][19]

これは安定したスクリプトに対する強力な制御である。それはオープンエンドの委任を特定のバイトの承認に変換する。ホストが他のものを返す場合、ブラウザは実行をブロックする。ウェブサイトは新しいバージョンをレビューした後、自身のデプロイプロセスを通じてダイジェストを更新できる。

Polyfill.io の正当な設計は、サービスがブラウザの能力とリクエストパラメータに応じて意図的に異なるバンドルを生成するため、そのモデルを複雑にする。1つの安定したダイジェストは、サイトがサービスの消費方法を変更しない限り、多くの有効なバイトシーケンスを承認できない。チームは一部のアーキテクチャで固定リソースの境界セットを事前計算して承認できるが、目的が動的応答選択であるエンドポイントに1つのハッシュを付けると、期待される動作が壊れるか、重要なバリエーションがバインドされないままになる可能性が高い。

正しい結論は SRI が役に立たないということではない。制御の選択がリソースモデルに一致しなければならないということである。サイトが整合性ピンニングを望む場合、リモートサービスに任意のリクエスト固有のバイトを生成させるのをやめる必要があるかもしれない。レビュー済みバンドルのセルフホスティング、固定バージョン付きバリアントの提供、またはサポートされるブラウザの絞り込みにより、バイトレベルの承認が実用的になる。

Content Security Policy（CSP）は別のレイヤーに対処する。ポリシーはスクリプトを提供できるオリジンを制限し、ノンス、ハッシュ、または関連ディレクティブを使用して実行を制約できる。予期しないドメインをブロックし、インジェクトされたマークアップが新しいリソースを読み込む自由を減らすことができる。しかし、cdn.polyfill.ioが信頼できるスクリプトオリジンとして明示的に許可されている場合、オリジン承認された悪意のある応答は許可リストに表示されることで信頼できるようにはならない。

CSP は依然として二次的な行動を封じ込めるのに役立つ。慎重に設計されたポリシーは攻撃チェーンに関与する接続、フレーム、ナビゲーションを制限する可能性があり、違反レポートは検出証拠を追加できる。正確な効果はポリシーとブラウザの動作に依存する。核心的な制限は変わらない：オリジン承認はコードがどこから来るかという質問に答えるが、承認されたオペレーターが常に許容可能なコードを返すかどうかには答えない。

ミラーリングは信頼境界を再び移動させる。ウェブサイトやインフラプロバイダーはコピーを取得または維持し、管理された場所から提供する。これにより、元のドメインがリクエスト時にバイトを変更するのを防ぐことができる。また、ミラーのソース、レビュー、更新、保護に関する義務を生み出す。Cloudflare のミラーへの自動書き換えは有用な封じ込めであったが、Cloudflare を新しい運用権限として選択したものであり、信頼の概念を排除したわけではない。

セルフホスティングはウェブサイト所有者により直接的な配信制御を与える。バージョンをレビューし、アプリケーションとともにデプロイし、通常のリリースプロセスを通じて変更を監視できる。セルフホスティングは安全なコードを保証するものではない。本番応答を変更できる者を狭め、デプロイされたバイトをリリースに結びつけやすくする。

機能が不要な場合、削除はより強力である。現在のブラウザサポートがもはやポリフィルサービスを必要としない場合、最もリスクの低いリモートスクリプトはページが要求しないものである。これが、ライフサイクルレビューがセキュリティ制御と並んで属する理由である。何年も前に行われた互換性決定が恒久的な権限付与になってはならない。

サンドボックス化は、機能を制約されたフレームや分離されたコンテキストで実行できる場合、サードパーティの影響を減らすことができる。すべてのスクリプトを製品を変えずにそこに移動できるわけではない。ページの JavaScript 環境を変更することを意図したポリフィルは特にメイン実行コンテキストに結びついており、分離の有用性を制限する。その制限は、利便性が権限に見合う価値があるかどうかに影響を与えるべきである。

コードスキャンツールは既知の参照を見つけるのに役立つ。CodeQL の Polyfill 固有のガイダンスは、所有権のデューデリジェンス、ログレビュー、セルフホスティング、動的コンテンツに対する整合性制御の限界を強調している。Semgrep はインシデント後に Polyfill.io の使用を特定するためのリポジトリ検索とルールを提案した。[15][20]

静的スキャンだけでは不十分である。なぜならランタイムインジェクションはコンテンツシステム、タグマネージャー、ベンダーから来る可能性があるからである。ランタイム観察だけでは不十分である。なぜなら稀な条件がサンプル期間中に発生しない可能性があるからである。成熟した制御スタックは、ソースとバンドルスキャン、サードパーティスクリプトインベントリ、DNS と所有権の監視、ブラウザ側テレメトリ、変更レビュー、緊急無効化メカニズムを組み合わせる。

スタックはまた失敗動作を指定すべきである。ポリフィルが読み込めなかった場合、ページはマイナーな拡張を失うのか、使用できなくなるのか、重要なトランザクションを妨げるのか？失敗の影響を理解しているチームは、インシデント中に即興で対応することなく、疑わしいリソースを迅速に削除またはブロックできる。継続性がリソースに依存する場合、テスト済みのローカルフォールバックは、レジストラがドメインを停止したときに依存関係を発見するよりも安全である。

したがって、制御は1つのファッショナブルな頭字語を選択できるメニューではない。それらは一連の決定である：不要な権限を削除し、可能な限り必要なコードを固定し、それがどこから来るかを制約し、それが何をするかを観察し、証拠を保存し、それを無効化または置き換えるテスト済みのパスを維持する。

説明責任は各当事者が持っていた制御に従うべきである

インシデントには、サービスオペレーター、ウェブサイト所有者、インフラプロバイダー、レジストラ、セキュリティ研究者、プラグインとプロダクトのメンテナー、コードがエンドポイントを導入したベンダーが関与した。それらの責任は重複していたが、代替可能ではなかった。

ホステッド Polyfill.io サービスを管理していたオペレーターは、そのサービスによって返される応答に対して最も直接的な権限を持っていた。これは元のオープンソースコードを維持することとは異なる。この層での説明責任は、ドメインとデプロイパスの管理、変更管理、応答整合性、配信の可視性、運用に関する正確なコミュニケーションに関するものである。利用可能な記録は、すべての個人関係者、企業関係、法的義務についての調査結果に拡張されるべきではない。

Fastly と Cloudflare はインフラと代替能力を持っていた。2月の通知は警告し、代替案を提供できた。Cloudflare の後の立場は、カバーされるトラフィックに対する自動書き換えとクライアント側テレメトリを可能にした。これらの制御は重要だったが、どのプロバイダーにもすべての下流サイトのソース、設定、訪問者影響に関する完全な知識を与えたわけではない。[2][3][5]

Namecheap はレジストラレベルの封じ込めレバーを持っていた。ドメインを保留することで、エンドポイントの解決または使用が中断された。その行動は即時露出を減らす一方で、依存するサイトを壊す可能性もあった。レジストラの制御はパスを止めることができたが、アプリケーションにパッチを当てたり、各ウェブサイトの歴史的配信を確立したりすることはできなかった。[10]

セキュリティ研究者と政府対応者は、検出、分析、警告能力を持っていた。Sansec は指標と観察された行動を公開した。Akamai と Cloudflare はテレメトリの視点を追加した。CERT-FR、西オーストラリア州、CERT-AGID、SingCERT はインシデントをそれぞれのオーディエンス向けの運営者ガイダンスに変換した。これらの当事者は可視性を高め、制御を推奨できたが、すべてのサイトに修正をデプロイすることはできなかった。[1][5][6][7][9][21][22]

プラグイン、ライブラリ、ベンダーのメンテナーは、推移的に依存関係を導入する可能性のあるコードを管理していた。彼らの説明責任のある行動には、影響を受けるバージョンと条件の特定、エンドポイントの削除、修正のリリース、範囲の伝達、潜在的な露出と観察された悪用の区別の維持が含まれる。Fides と WordPress プラグインの記録は、バージョンと到達可能性の証拠がなぜ重要かを示している。[11][12][14]

ウェブサイト所有者は最終的な包含決定を管理していた。それを実行するためにベンダーやメンテナーがコードを変更する必要があったとしても。彼らはサポートするブラウザを定義し、サードパーティスクリプトプロバイダーを承認し、インベントリを維持し、所有権を監視し、リソースをブロックまたは書き換え、レビュー済みコードをセルフホストし、ブラウザ証拠を保持し、苦情を調査し、訪問者とコミュニケーションできた。

これは同等の非難を意味するものではない。小規模サイト運営者は、グローバルインフラ企業よりもはるかに少ない可視性と専門知識を持つかもしれない。ベンダーだけがバンドルされたフォールバックを変更できる唯一の当事者かもしれない。レジストラだけがドメインを迅速に停止できる唯一の当事者かもしれない。説明責任は実用的な制御とそれを行使するために利用可能な証拠に従うものであり、すべての参加者が同じ能力を持っていたという仮定ではない。

有用な義務マップは6つの質問を中心に整理できる。

第一に、誰が不必要な露出を防ぐことができたか？ウェブサイトとプロダクトの所有者はブラウザサポートを再検討し、依存関係を削除できた。メンテナーは推奨またはバンドルを停止できた。プロバイダーはより安全な移行パスを提供できた。

第二に、誰が信頼の変更を検出できたか？ドメインとインフラのモニターは所有権、DNS、ルーティングの変更を観察できた。プロジェクトメンテナーはアカウント制御とドキュメントを追跡できた。ウェブサイト所有者は関連通知を購読し、オペレーターが変更されたときに高い権限を持つ依存関係をレビューできた。

第三に、誰が有害な配信を観察できたか？サービスオペレーターとインフラプロバイダーはサーバー側応答を見ることができた。ウェブサイト所有者とクライアント側セキュリティサービスはブラウザ動作を見ることができた。研究者は条件間でサンプルを比較できた。単一のビューが必ずしもキャンペーン全体をカバーしたわけではない。

第四に、誰がパスを封じ込めることができたか？オペレーターは配信を停止でき、レジストラはドメインを停止でき、インフラプロバイダーはトラフィックを書き換えまたはブロックでき、メンテナーは修正をリリースでき、ウェブサイト所有者は参照を無効化または削除できた。

第五に、誰が影響を調査できたか？各ウェブサイト所有者は自社のページアーキテクチャ、訪問者記録、苦情、デプロイ履歴を持っていた。ベンダーは推移的条件に関する情報を持っていた。インフラプロバイダーは選択されたトラフィックと応答テレメトリを持っていた。調査は、一方の当事者のデータセットがすべての訪問者を代表するふりをせずに協力を必要とした。

第六に、誰が修復を検証し、それを伝達できたか？メンテナーは修正をバージョンにバインドできた。ベンダーは削除を示すことができた。ウェブサイト所有者は公開パスをテストし、その証拠がカバーする範囲を述べることができた。政府とセキュリティ機関はガイダンスを更新できた。検証は当事者の可視性にスコープされたままでなければならなかった。

このマップは説明責任をテスト可能にする。誰がインシデントを引き起こしたかのみを問う代わりに、各当事者が予防、検出、封じ込め、調査、修復の各質問に答えられるかを問う。また、制御のギャップも明らかにする。ページレベルの権限を持つスクリプトのドメイン所有権を誰も監視していなかった場合、そのギャップは悪意のあるブランチが現れる前から存在していた。

下流ウェブサイトが証明できるべきこと

信頼できる下流応答は、一般的な保証ではなく証拠連鎖として表現できる。

連鎖はインベントリから始まる。組織はすべての直接的および推移的な Polyfill.io 参照、それを導入したコンポーネントまたはベンダー、それをレンダリングしたページ、それを到達可能にしたブラウザ条件を特定すべきである。検索結果はデプロイされた動作に結びつけられるべきであり、一致するファイルのリストとして放置されるべきではない。

次に必要性である。所有者は、互換性機能が意図的にサポートするブラウザに対して依然として必要かどうかを文書化すべきである。そうでない場合、削除が優先されるべきである。必要な場合、組織は選択された代替またはセルフホストバージョンがニーズに比例する理由を説明すべきである。

3番目のステップは信頼の再評価である。記録は、組織が所有権移行または6月のインシデントをいつ知ったか、誰がサービスを継続、ブロック、代替、削除する決定を下したか、その決定をどのような証拠が支持したかを示すべきである。2月のレビューと6月の緊急対応は異なるイベントであり、統合されるべきではない。

4番目のステップは歴史的範囲である。組織はどの日付、訪問者人口、テレメトリソースを調査したかを述べるべきである。エンドポイント参照、リクエスト、既知の指標一致、リダイレクト、報告された被害を分離すべきである。ログが欠落している場合、そのギャップは明示的なままであるべきである。

5番目のステップは修復である。所有者は変更をリリース、設定、またはベンダー確認にバインドすべきである。生成されたアセット、キャッシュ、プラグイン、タグマネージャー、条件付きブランチを考慮すべきである。停止されたドメインがもはや応答しないことを単に観察することは削除証拠ではない。

6番目のステップは検証である。テストは関連するブラウザ条件をカバーし、公開ページが古いエンドポイントにリクエストを行わないことを確認すべきである。監視は再導入、予期しないスクリプトオリジン、リダイレクト行動をチェックすべきである。ベンダーが修正を提供した場合、顧客は外部結果を検証すべきである。

7番目のステップはコミュニケーションである。通知は安定した定義を使用し、使用を被害者になることに変換すべきではない。どのような依存関係が存在したか、それが到達可能かどうか、悪意のある配信の証拠が見つかったか見つからなかったか、何が変わったか、どの不確実性が残っているかを説明すべきである。ユーザーは問題が「解決された」という広範な宣言ではなく、実用的な事実を必要としている。

最後に、所有者はライフサイクル管理を更新すべきである。高い権限を持つリモートスクリプトには、名前付き所有者、レビュー日、信頼基盤記録、ドメインとオペレーターの監視、緊急無効化パス、有用なブラウザ証拠の保持が必要である。さもなければ、同じガバナンスの失敗が別のホスト名で繰り返される可能性がある。

これらの証明は機密の防御詳細の開示を必要としない。応答を反証可能にするのに十分な具体性を必要とする。訪問者、顧客、またはレビューアは、「文字列を削除しました」と「すべてのアクティブパスを見つけました」を区別でき、「悪用を見ませんでした」と「私たちの証拠はカバーされた人口に対してそれを排除します」を区別できるべきである。

ドメイン移管はソフトウェア変更になり得る

Polyfill.io は単純な原則を無視しにくくした：ドメインが実行可能コードを返す場合、そのドメインの所有権はソフトウェアのセキュリティ状態の一部である。URL は安定したままで効果的な供給者が変わる可能性がある。リポジトリは公開されたままで、ホステッド応答が異なる管理下に移動する可能性がある。HTTPS は有効なままで、包含を正当化した信頼基盤がもはや存在しない可能性がある。

2月の通知は、この変更が可視的で行動可能であったことを示した。6月の報告はなぜそれが重要であったかを示した。選択的リダイレクト配信は、異なる訪問者が正当に異なるコードを受け取ることができるモデルを悪用し、カジュアルな検査を弱い保証にした。後の書き換えとドメイン停止はパスを制約したが、下流のインベントリ、削除、調査、検証だけが各ウェブサイトの部分的な問題を閉じることができた。

このインシデントは、10万以上のサイトを確認された被害者と呼ぶことを正当化しない。すべての参照が悪意のあるコンテンツを提供したこと、すべての訪問者が露出されたこと、すべての下流製品が悪用されたことを証明するものではない。また、元のオープンソースコードを普遍的に悪意があると説明したり、セルフホストコピーを侵害されたホステッド関係と同一視したりすることを正当化しない。

このイベントは、利用可能な記録からの法的評決や完全な属性ストーリーを支持するものでもない。ここでの説明責任はより狭く、より運用的である。それは、なぜ実行可能権限が委任されたか、変更された制御がどのように検出されたか、どの証拠がリーチを確立したか、どの行動が露出を減らしたか、修復がどのように検証されたかを説明する義務である。

サービスオペレーター、インフラ企業、レジストラ、メンテナー、ベンダー、ウェブサイト所有者はそれぞれその答えの異なる部分を保持していた。システムが共有されていたため責任は共有されたが、代替可能ではなかった。レジストラはドメインを停止できても、古いコードを残したままにする可能性があった。ベンダーは参照を削除できても、顧客の訪問者テレメトリを欠いていた。ウェブサイトはユーザーを調査できても、バンドルされたコンポーネントを変更するために上流の当事者に依存していた。

下流所有者にとって、耐久性のある基準は直接的である：訪問者のためにコードを選択できるすべての外部当事者を知ること。その当事者を信頼できるものにした事実を監視すること。もはや必要な機能を果たさない権限を削除すること。露出、配信、被害を区別するのに十分な証拠を保持すること。

スクリプトタグは1行の HTML かもしれないが、運用関係を生み出す。その行の背後にある所有者が変わるとき、ソフトウェア関係も変わる。ウェブサイトの説明責任は、訪問者がそれを明らかにする前にその変化を認識することから始まる。

Polyfill.io が問うドメイン所有権と下流ウェブサイトの説明責任

要約