建立並治理第三方網站相依關係圖

最實用的做法，是以代表性使用者旅程為主軸，建立一份持續維護的第三方相依登記表。先從瀏覽器觀察各個重要狀態真正發出的請求，再用架構、設定、採購、合約、供應商與內部訪談資料補齊看不見的平台及上游關係。每一列都要連結服務目的、適用範圍、負責人、資訊流、具情境的效能證據、失效症狀、替代路徑、監控與下次審查條件，讓團隊能依證據決定保留、替換、隔離、延後、自行託管或移除。

哪些項目算第三方網站相依關係，又該如何找出來？

只要某項外部控制的程式碼、內容、服務、基礎設施、憑證、資料來源或供應商關係，在變更、延遲、無法使用、遭破壞或改變資料處理方式時，足以實質影響範圍內的網站旅程，就應納入相依關係圖。不同來源是實用線索，卻不是定義本身：外部服務可能透過第一方網址代理，同公司來源也可能有不同負責人與失效邊界。這份圖處理的是旅程依賴，不是原始碼套件清單。

第一輪從瀏覽器出發，但不要只錄首頁第一次載入。選定查詢、比較、登入、填表、預約或確認等代表性步驟，涵蓋不同裝置、同意選擇、互動前後及適用的驗證狀態。網路紀錄應保留請求類型、啟動來源、狀態、傳輸大小、耗時、瀑布位置、被封鎖情形與下游請求關係。第三方指令碼可能增加網路、執行及繪製成本，也可能再載入資源；影響必須連同頁面、裝置、網路與快取條件實測，不能看到網域就直接評分。

把每次觀察標上旅程、狀態、日期與測試條件，才能知道這筆證據代表什麼。HAR 與請求紀錄可能含有權杖、標頭、查詢內容或表單資料，因此只擷取工作所需範圍、限制存取與分享，使用可用的清理功能後仍須人工複查，再決定是否放入登記表或附在工作單。

瀏覽器看不到的相依服務，要如何補齊？

第二輪要從組織紀錄反向核對旅程，才能補出瀏覽器不會直接顯示的服務。依序檢查網域註冊、DNS、憑證簽發與更新、CDN 與邊緣服務、主機、CMS、身分識別、站內搜尋、表單、交易通知、伺服器對伺服器整合、可觀測性與狀態通報，再把採購系統、合約、架構圖、實際設定、保證資料及供應商說明放在一起比對。任何一份掃描、合約或圖表都只能提供部分視角。

供應商圖除了服務名稱，還可記錄重要性、資訊流、保證聯絡人、評估狀態、分包商及共用上游服務。盤點深度應與旅程影響相稱：先追查可能使關鍵旅程集中失效的鏈條，不必假設能窮舉供應商的所有商業關係。每找到一項服務，就連回受影響的旅程，並標出誰能確認用途、操作方式、契約、保證狀態及移除權限；無法回答的欄位本身就是待處理事項。

第三方相依登記表應記錄哪些資料？

登記表應讓讀者從同一列看懂這項依賴是什麼、為何存在、由誰負責、如何影響旅程，以及目前決定為何。識別欄納入服務與供應商、端點、啟動來源、下游服務、環境、頁面、元件、旅程步驟、狀態、裝置及啟動或同意條件；權責欄則清楚區分業務負責人、技術操作人、相關資安或隱私夥伴、採購聯絡人，以及核准變更或移除的權限。

資訊流欄要列出送出與接收的資料、參與者、目的地、目的、啟動條件及已審查的契約或隱私紀錄。資料最小化、目的限制與透明度可作為決策問題，但登記表只支援審查，不作法律結論；告知、同意、保存、跨境傳輸與個人權利仍須交由合格角色依情境判斷。效能數據也要綁定旅程、裝置、網路、快取狀態及日期，因為跨來源政策與平台條件可能使 Resource Timing 的大小或計時細節不完整。

如何安全測試第三方服務失效後的網站旅程？

安全做法是在測試環境或明確核准的瀏覽器工具內，先定義旅程失效時仍應保有的可用狀態，再一次處理一個已觀察到的請求或元件；不要製造未經核准的正式環境中斷。瀏覽器封鎖能揭露部分使用者可見行為，卻無法重現所有延遲、異常內容、伺服器端故障或正式環境條件。滲透測試、破壞性韌性測試及正式環境故障注入，都應交由具權責的人員另行授權與控管。

1. 選定代表性旅程，預先寫下內容、導覽、表單、驗證、確認訊息與替代聯絡管道應維持的狀態。
2. 在相關且可安全重現時，分別觀察延遲、失敗、拒絕同意、空白回應或過期資料，不要同時改動多項依賴。
3. 檢查鍵盤操作、標示、錯誤處理、逾時、無障礙替代方式及監控告警，而不只查看供應商端點。
4. 記錄使用者看到的症狀、營運訊號、復原動作，以及設計中的替代路徑是否真的可用。

以一個純屬假設的預約元件為例：瀏覽器擷取在預約步驟看到 iframe 及其啟動的請求，供應商紀錄再補上業務負責人與上游服務。團隊記錄待確認的資料流，並在核准工具中封鎖元件。假設結果是頁面內容與可存取的替代聯絡方式仍可使用，但即時預約消失，既有監控也沒有察覺；此時可把該旅程記為「降級」，同時將監控缺口與已驗證的替代路徑帶入處置決策。

關鍵、降級、選用及僅影響量測，是方便共同分流的四個編輯標籤，不是通用的風險或營運持續標準。即使使用者仍能完成主要任務，量測失效也可能使監控、歸因或實驗證據缺漏。供應商端點回應或 HTTP 200 狀態只是證據之一，不能單獨證明完整旅程及替代路徑可用。

相依關係圖真正有用之處，不只在於列出網站呼叫了什麼，更在於說清楚依賴失效時，使用者與營運人員會經歷什麼。

該保留、替換、隔離、延後、自行託管，還是移除？

處置應由已記錄的目的、權責、資訊流、效能成本、失效結果與替代方案共同決定，而不是由單一分數或對第三方服務的偏好決定。以下六種選項是實務框架，並非通用標準；每個決定都要附上理由、負責人、接受條件與重新審查的事件。在假設的預約案例中，可條件式保留元件，但要求增加旅程層級監控、維持已測試的無障礙替代管道，並設定審查觸發條件。

• 保留：用途明確、權責完整，而且在該旅程的重要性下，觀察到的成本、資訊流與失效行為皆已被明確接受。
• 替換：能力仍有必要，但經驗證的替代方案能改善目前不可接受的成本、控制、支援、資料處理、失效行為或集中風險。
• 隔離：服務仍需存在，但應縮小存取或影響範圍；實作方式及功能代價須由技術與資安角色審查。
• 延後：選用型嵌入內容不必早於主要內容或互動載入，可改用輕量替代介面並在使用者啟動後載入。
• 自行託管：組織能合法且持續承擔交付、更新、完整性、授權、隱私、維護與支援責任時才採用。
• 移除：目前無人能說明用途、項目未使用或重複，或其可接受價值已不足以支持觀察到的成本與風險。

直接引入的第三方 JavaScript 可能在自身發布流程之外變更，並於頁面環境執行；實際能力仍取決於整合與瀏覽器控制。iframe 的隔離效果則取決於來源、sandbox 與權限設定。Content Security Policy、相容的完整性檢查、伺服器中介或脫離關鍵路徑可降低部分暴露，卻不會消除供應商風險。Subresource Integrity 只能核對受支援資源的預期位元組，不能驗證所有 API、iframe 或業務行為；自行託管也只是轉移交付責任，不會讓上游維護與授權問題消失。

如何讓相依關係圖持續反映網站現況？

把更新登記表納入既有網站營運流程，才能避免它迅速變成歷史文件。審查可由發布、標籤管理器變更、新元件、採購或續約、供應商變更與停用通知、事件、隱私審查及經核准的定期旅程檢查觸發，不必為所有項目硬套同一週期。每次更新都確認最近使用證據、合約或保證狀態、上次決定、決策負責人、未結行動及下一個觸發事件。

1. 第一週先選一條對業務重要、範圍又可控制的旅程，寫出主要步驟與應維持的可用狀態。
2. 擷取初始載入、互動、同意與適用的登入或交易狀態，建立第一批請求與啟動鏈證據。
3. 用架構、設定、採購、合約及已知供應商紀錄補齊平台、伺服器端與上游服務。
4. 建立初始登記列、指派暫定負責人，將未知用途、資訊流或權限明確列為待辦。
5. 規劃一項經授權的失效測試，驗證使用者症狀、替代路徑、無障礙與監控訊號。

新相依項目在採用前，就應提出用途、權責、資訊流、預期成本、可能的失效行為、替代方式、監控及審查條件。監控要盡量對準使用者可見的旅程症狀與量測缺口，供應商或端點可用性只能作為其中一項證據。從一條旅程開始，先讓負責人與失效結果變得可見，再按影響擴大；資安、隱私、法律、採購、無障礙及營運持續夥伴，則應在各自權責範圍內參與需要專業判斷或具約束力的決定。