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回のクリーンなダウンロードは歴史的な安全性を証明しない。ある瞬間の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 と西オーストラリアサイバーセキュリティユニットは、事業者に参照を特定して削除し、必要に応じて管理された代替手段に移行し、サブリソース完全性やコンテンツセキュリティポリシーなどのブラウザ制御を検討するよう助言した。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]

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

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

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

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

範囲設定された母集団はその分母を保持すべきである。特定のブラウザバージョンやページフローのみがベンダーパスをトリガーできる場合、調査は潜在的なリーチを狭めることができる。そのブラウザグループのすべてのメンバーが悪意のあるコンテンツを受け取ったことを示唆すべきではない。逆に、パスが稀だったという事実は、それを削除しなかったことを正当化しない。稀なパスは日常的なテストを受けることが少なく、依存関係が気付かれずに存続する魅力的な場所になる可能性がある。

Jellyfish はまた、共有されているが代替不可能な責任を示している。ベンダーはコードを管理し、インクルージョンを削除できた。Jellyfish はベンダーエスカレーション、顧客向け調査、修復の受理を管理した。インフラおよびセキュリティプロバイダーはテレメトリーを提供できた。これらの当事者のどれも、別の当事者に完全に代わることはできなかった。

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

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

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

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

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

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

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

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

SRI と CSP は管理策であり、魔法の答えではなかった

サブリソース完全性 (SRI) は、ページ作成者が外部リソースの暗号化ダイジェストを提供できるようにする。対応するブラウザはリソースをフェッチし、返されたバイトが期待されるダイジェストと一致しない場合、実行を拒否できる。W3C の仕様と MDN の実装ガイダンスは、SRI を、内包するサイトが固定されたままであることを期待するリソースを、侵害されたサードパーティホストが静かに変更するのを防ぐ方法として提示している。[18][19]

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

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

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

コンテンツセキュリティポリシー (CSP) は異なるレイヤーに対処する。ポリシーはスクリプトを提供できるオリジンを制限し、nonce、ハッシュ、または関連ディレクティブを使用して実行を制約できる。予期しないドメインをブロックし、インジェクションされたマークアップが新しいリソースを読み込む自由を減らすことができる。しかし、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 かもしれないが、運用関係を生み出す。その行の背後にある所有者が変わると、ソフトウェア関係も変わる。ウェブサイトの説明責任は、訪問者がそれを明らかにする前にその変更を認識することから始まる。