漏洞揭露政策

快速概覽

本頁說明 NextPDF 的協調式漏洞揭露政策，包含回報者如何私下聯絡維護者、可預期的回應時程，以及禁制期的運作方式。

界線。 揭露政策是一項流程承諾，並非對時程或結果的保證。以下目標是維護者基於善意向回報者做出的承諾；它們描述的是專案遵循的流程，並不構成任何特定回報必定會在某個日期前獲得確認、分流、修復或揭露的契約義務。協調揭露的時點來自協商，而非單方面保證。

安裝

不適用。回報漏洞不需要安裝任何東西。機器可讀的聯絡資訊發布於 /.well-known/security.txt（RFC 9116）。具權威性、供人閱讀的政策則是儲存庫中的 SECURITY.md。

概念總覽

本政策依 ISO/IEC 29147 的定義實施協調式漏洞揭露，並採用 ISO/IEC 30111 的處理流程（iso_iec_30111#x9.x43.p2）：私下通報、分流與嚴重性評估、禁制期內的修補階段，以及共同協調公開發布。當某個漏洞影響多家廠商時，公告時點會由受影響各方協調決定，而非單方面訂定（iso_iec_29147#x3.x110.p13）。

本流程也與歐盟網路韌性法（EU Cyber Resilience Act）對製造商的漏洞處理義務（eu_cra#x1.p191），以及 NIST Secure Software Development Framework（NIST 安全軟體開發框架）的「回應漏洞」實務做法（nist_sp_800_218#x15）一致。兩者都將這些義務視為可重複執行的流程職責，而非保證任何個別結果必定達成的擔保。

API 介面

不適用。揭露是一套流程，而非 API。機器可讀的探索介面是 RFC 9116 的 security.txt 檔案；工具會剖析其中的 Contact: 與 Expires: 欄位。除下方列出的管道外，本頁不重複該檔案內容。

程式碼範例 — 快速上手

不適用。回報漏洞不需要執行任何程式碼。請使用私密管道：

GitHub Security Advisories（首選 — 靜態加密儲存、保留稽核紀錄）：在專案的 GitHub Security 頁籤開立一份草稿公告。
電子郵件：寄至 [email protected]，並在主旨加上 [SECURITY]。如果你需要端對端加密，而 security.txt 中尚未列出已發布的 OpenPGP 金鑰，請改用 GitHub Security Advisory 管道。

請不要透過公開 issue、公開郵件群組、社群媒體或聊天室回報。在修復之前公開揭露，會危及仍在使用未修補版本的使用者。

程式碼範例 — 正式環境

不適用。

邊界案例與陷阱

目標是承諾，而非 SLA。 下方時程說明的是專案追求的目標。複雜的多元件問題，或需要與上游協調的問題，可能會耗時更久；過程中會持續向回報者說明進度。
禁制期長度可協商，但有上限。 預設禁制期從分流持續到修復發布。若回報者需要更長的時間，必須在開立公告時明確提出要求。超過上限後，無論修復是否完成，專案都會發布公告；這與業界協調揭露的慣例一致，此舉是為了保護使用者，避免公告被無限期擱置。
嚴重性決定時程。 嚴重且正遭實際利用的問題會以壓縮時程處理；低嚴重性的強化建議則不會。嚴重性會在分流時評估，之後也可能修訂。
CVE 申請屬於分流的一部分。 維護者會在分流步驟中，透過專案在 GitHub Security Advisory 的 CNA 註冊來申請 CVE；回報者不需要另行申請。

效能

不適用。

安全性注意事項

回應時程目標是對回報者的承諾，也構成專案處理漏洞的基準。這些是目標，而非保證：

階段	目標
確認收到回報	1 至 2 個工作天內
初步分流與嚴重性評估	約 5 個工作天 / 7 個日曆天內
修補開發與私下審查	通常為 14 個工作天；已確認的複雜 CVE 視嚴重性需 30 至 90 天
CVE 指派（若獲接受）	與修補同時進行，透過 GitHub CNA 管道
協調式公開揭露	於修補發布時，依與回報者共同議定的日期
禁制期（從分流到發布）	預設約 90 天，遭實際利用時會縮短；明確提出要求時，可延長至固定上限

審查者可以逐項核對以下流程規則：

私密優先。 沒有任何公開管道會被視為可接受的通報來源。唯一接受的管道是 GitHub Security Advisory 與安全聯絡信箱。
協調而非單方面。 揭露時點會與回報者及任何共同受影響廠商協商議定（iso_iec_29147#x3.x110.p13）。
禁制期有界限。 禁制期設有預設值與硬性上限；公告不會被無限期擱置。
可依要求署名致謝。 研究人員會在禁制期解除後獲得致謝，除非他們要求匿名。

這些陳述描述的是專案承諾遵循的流程。它們並不保證任何特定回報必定會在特定日期前得到修復、CVE 或揭露。

符合性

這不是符合性規範。本政策與 ISO/IEC 29147、ISO/IEC 30111，以及上文引用的 CRA/SSDF 流程職責對齊；「對齊」是刻意使用的措辭，專案並未宣稱已通過上述任何方案的認證。它們界定的是健全流程應有的樣貌；本頁記載的是專案承諾落實的流程。

另請參閱

信任中心
引擎威脅模型
簽章與加密安全模型
儲存庫中的 SECURITY.md 與 /.well-known/security.txt（RFC 9116）