安全與隱私白皮書（總覽）第 11 章
第 11 章：漏洞揭露與安全更新
FileBolt 鼓勵負責任的揭露，並透過可預期的修復與溝通機制建立信任。 同時，安全能力必須能持續演進：包括 Web 安全政策、伺服器端驗證機制，以及端對端加密與協定實作（例如 cryptoVersion 升級）。本章概述公開聯絡管道、處理流程、修復發布與公告原則，並說明版本化演進與棄用策略。
11.0 摘要
- MUST：提供公開的漏洞提交管道（例如 security.txt 與支援電子郵件）。
- SHOULD：提供加密提交機制（例如 PGP 金鑰），以便安全地提交詳細資訊。
- SHOULD：訂定明確的回應與修復節奏（SLA／目標時程），必要時透過狀態頁溝通。
- MUST：將可能影響零知識承諾的漏洞（XSS、供應鏈注入、日誌片段洩漏）視為最高優先。
- MUST：實施版本化演進（
cryptoVersion），並訂定相容性、遷移與棄用策略。
11.1 漏洞提交管道與聯絡方式
11.1.1 公開入口
- MUST：在
/.well-known/security.txt中提供漏洞提交管道、有效期限與政策連結。 - MUST：提供可聯絡的安全聯絡信箱（例如
support@filebolt.net或專用的security@filebolt.net）。 - SHOULD：在安全與隱私頁面提供簡要說明與提交指引。
11.1.2 加密提交與敏感資訊處理
- SHOULD：提供 PGP 公鑰（或同等機制），讓研究人員能安全地提交重現細節。
- MUST：內部對漏洞細節實施最小權限可見性，僅向修復所需的人員揭露。
- MUST：禁止研究人員在報告中附上使用者明文、CEK、URL 片段或可推導出的金鑰材料；若不慎附上，團隊 MUST 將其視為敏感事件並限制擴散。
11.2 回應時程與溝通原則
時程取決於團隊規模與問題複雜度，但專案 SHOULD 提供可預期的目標節奏，並在未達標時及時溝通。 建議目標（可依實際情況調整，並公布於 /security 或 security.txt）：
- 首次回應：例如在 48 小時內確認收到並指派追蹤編號。
- 初步評估：例如在 7 天內完成嚴重程度分級與影響範圍評估。
- 發布修復：依嚴重程度推進；P0／P1 優先快速修復並發布。
SHOULD：處理期間維持必要的溝通（例如已重現／無法重現、需要更多資訊、預估修復時間窗），並避免公開披露可被利用的細節。
11.3 揭露流程
- 受理：記錄報告資訊、重現步驟、影響與研究人員聯絡方式；指派負責人並開始追蹤。
- 驗證：在隔離環境中重現；評估影響範圍、可利用性與受影響的元件（前端／後端／邊緣／儲存）。
- 修復：實作修補，新增測試與回歸案例，必要時加入防護規則（WAF／速率限制／政策收緊）。
- 發布：先以金絲雀方式發布並監控關鍵指標；確認沒有回歸或新風險後再全面發布。
- 公告：公開說明影響、修復內容與使用者需採取的行動（如有），且不擴大攻擊面。
對於嚴重漏洞或對使用者影響較大的事件，SHOULD 透過 /status 發布事件更新或事後檢討，並與第 10 章的事件回應流程一致。
11.4 影響零知識邊界的漏洞
零知識承諾的核心是：伺服器無法取得 CEK，且下載／解密環境盡可能隔離、不含第三方腳本。 因此，以下類別 MUST 視為最高優先：
- XSS／注入：能在下載／解密頁面執行任意腳本，讀取片段或記憶體中的金鑰材料。
- 供應鏈注入：依賴套件投毒、建置產物遭替換、CDN／邊緣注入，導致腳本被竄改。
- 日誌／監控洩漏：URL 片段、CEK、權杖或明文被意外記錄且可被存取。
- 資源載入政策不當：下載／解密頁面引入第三方腳本，或 CSP 放寬而擴大執行面。
處置應包括：立即圍堵（下線有風險的程式碼／收緊政策／封鎖攻擊途徑）、快速發布修復、回溯影響分析， 並在公告中明確說明「金鑰材料或明文是否可能已暴露」。
11.5 安全更新與回歸驗證
- MUST：為安全相關變更（驗證、存取控制、CSP、日誌過濾、加密流程）建立回歸案例。
- SHOULD：對關鍵頁面（下載／解密）執行自動化檢查，確保沒有第三方腳本，且標頭政策符合預期。
- SHOULD：修復發布後，重新測試可由外部驗證的項目（例如 TLS／安全標頭掃描）。
- SHOULD：在文件中清楚記載修復所帶來的相容性變更（例如舊連結／舊 manifest）。
與第 12 章一致：第三方掃描可驗證部分 Web 基線，但無法直接證明完整的零知識／E2EE 實作細節； 因此，回歸驗證應同時涵蓋協定實作與可見的基線。
11.6 協定與密碼學版本控制（cryptoVersion）
FileBolt 的加密與協定實作 MUST 支援版本控制，以利演算法升級、修復實作缺陷，以及引入更強的隔離。 建議使用明確欄位（例如 cryptoVersion），並綁定在 manifest／中繼資料中。
- 明確版本：每次傳輸／manifest MUST 宣告其
cryptoVersion，以決定演算法、參數與編碼規則。 - 不做隱含推斷：用戶端 MUST 依據 manifest 中的明確欄位決定解析與解密邏輯，不得猜測或採用備援啟發式判斷。
- 失敗即關閉：遇到未知版本或不一致的參數時 MUST 失敗並關閉，絕不降級到不安全的模式。
11.7 相容性、遷移與棄用
11.7.1 向後相容
- SHOULD：在過渡期內支援讀取舊版傳輸，以將對使用者歷史連結的影響降到最低。
- MUST：公開說明舊版的安全邊界、限制與棄用計畫。
11.7.2 遷移（維持零知識）
- SHOULD：若需要從舊版遷移到新版，提供使用者端的「重新上傳／重新加密」路徑。
- MUST：遷移期間維持零知識：重新加密在用戶端進行，伺服器無法取得 CEK 或明文。
11.7.3 棄用與終止支援（EOL）
- MUST：為被認定不再安全的版本提供明確的終止支援（End-of-Life）時程。
- SHOULD：在介面／文件中提示使用者重新上傳，並提供足夠的遷移期間。
- MUST：EOL 之後，用戶端遇到已棄用的版本時應明確提示，且不得嘗試解密。
11.8 相關聲明 ID（預留）
本章涵蓋「漏洞揭露管道、流程、版本控制與棄用」。 對應的聲明 ID 將新增至 附錄：聲明 ID 總表 ，該附錄為唯一的權威來源。