漏洞披露政策

快速概览

本页说明 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）