波仔
🛡️ 第四章 系统漏洞的防范
📄 一句话概括

漏洞信息的共享有一条贯穿所有制度的铁律：先修好、再公开——因为漏洞信息一旦公布，就等于把一个"已经验证可行的攻击方案"发到了所有人手里。不同的制度差别只在于"流程怎么走"：中国规定了报送时限，国际指南规定了协调流程，欧盟把它写成了法定义务。

📝 本节和前面几节的关系

这一节是第四章的收尾，它把前面十三节的内容收束到"信息该怎么流转"这个问题上：前面讲的是"发现漏洞、评估漏洞、修复漏洞"，这一节讲的是"漏洞信息本身怎么管理"。

它也和 1-5 讲的信息安全基本属性呼应：漏洞信息是一种非常特殊的信息——它在修好之前是"危险品"，在修好之后是"公共品"，而这个"危险品 → 公共品"的转换时机，就是所有制度的争点所在。

一、三种制度的时间线对比

先把三种制度摆在一起看（中国《网络产品安全漏洞管理规定》、国际协调披露指南、欧盟网络弹性法案）。它们要处理的是同一件事：一条漏洞从被报告到被公开，中间该经过哪些环节。

环节 中国《规定》 国际协调披露指南
厂商报送监管 发现后 2 日内 无对应环节
确认收到报告 — 2~3 个工作日内
修复与验证 厂商负责修补 厂商修复并回传给报告者验证
公开时点 必须晚于补丁发布 与报告者协商后协调披露
发布内容 须同步发布修补或防范措施 公告加 CVE 编号加 CVSS v4.0
不得为之事 不得发布利用工具或向境外提供 不得静默修复、不得签一刀切保密协议

这张表的读法是"两个方向的政策取向"：

两者共同遵守的那条铁律是最后一列和倒数第二列的交叉点：公开必须晚于修复。 这就是"先修好、再公开"。

二、中国《规定》的具体条款

教材这一节提到"信息安全预警合作指南"这类合作机制，而在国内落地的最主要文件是《网络产品安全漏洞管理规定》（2021 年 9 月 1 日施行，由工信部、网信办、公安部联合发布）。它的核心条款有六条，都值得记住：

第 ① 条的"2 日"是这些条款里最硬的一条——它是一个明确的时间约束。第 ③ 条和第 ⑤ 条则是"行为禁止"，它们约束的是漏洞信息的扩散方向。第 ⑥ 条是对"平台"的要求（备案与日志留存），它意味着"漏洞收集"这件事本身也是被监管的行为。

三、动手 Demo：三种制度的差别在哪

下面这段脚本把三种制度在"六个环节"上的做法排成一张表：

rows = [
    ("厂商报送监管", "发现后 2 日内",           "无对应环节"),
    ("确认收到报告", "—",                       "2~3 个工作日内"),
    ("修复与验证",   "厂商负责修补",             "厂商修复并回传给报告者验证"),
    ("公开时点",     "必须晚于补丁发布",         "与报告者协商后协调披露"),
    ("发布内容",     "须同步发布修补或防范措施", "公告加 CVE 编号加 CVSS v4.0"),
    ("不得为之事",   "不得发布利用工具或向境外提供", "不得静默修复、不得签一刀切保密协议"),
]
for step, cn, intl in rows:
    print(step, "|", cn, "|", intl)

实跑输出：

一、一张时间线看清三种制度的差别
  环节                中国《规定》                  国际协调披露指南
  ----------------------------------------------------------------------------------------------
  厂商报送监管        发现后 2 日内                 无对应环节
  确认收到报告        —                             2~3 个工作日内
  修复与验证          厂商负责修补                  厂商修复并回传给报告者验证
  公开时点            必须晚于补丁发布              与报告者协商后协调披露
  发布内容            须同步发布修补或防范措施      公告加 CVE 编号加 CVSS v4.0
  不得为之事          不得发布利用工具或向境外提供  不得静默修复、不得签一刀切保密协议

二、必须记住的具体条款（中国《网络产品安全漏洞管理规定》，2021-09-01 施行）
  ① 厂商：发现或获知漏洞后【2 日内】向工信部平台报送
  ② 任何组织或个人：不得在厂商修补措施之前发布漏洞信息
  ③ 不得发布或提供【专门用于利用漏洞的程序和工具】
  ④ 国家重大活动期间，未经公安部同意不得擅自发布
  ⑤ 不得把【未公开】的漏洞信息提供给境外组织或个人
  ⑥ 漏洞收集平台须向工信部备案；接收日志留存不少于 6 个月

三、国际上的协调披露多了哪两样
  ① 安全港：善意的研究不追究法律责任。2026-07-15，CISA、NSA、
     JPCERT/CC、NCSC-NL、NCSC-UK 联合发布了建立协调披露程序的指南
  ② 机读公告与溯源信息：CVE 编号、CWE 根因、CVSS v4.0、CSAF 格式

四、欧盟把报告写成了硬时限
  2026-09-11 起：主动被利用的漏洞与严重事件，
  24 小时内早期预警，72 小时内正式通知，14 天内最终报告。

  → 三种制度的共同点：都要求【先修好、再公开】。
     差别在于：中国规定了报送时限，国际指南规定了协调流程，
     欧盟把两者都写成了法定义务。

读这个输出：

四、⚠️ 2026 现状

30 秒实验

今天做两个动作，各 15 秒：

  1. 在浏览器地址栏里试一下：在你常用的一个网站后面加上 /.well-known/security.txt（比如 https://example.com/.well-known/security.txt）。如果能看到内容，说明这个网站公开了"发现安全问题该联系谁"；如果打不开，说明它没有。这个文件就是 4-11 里"漏洞披露政策"那一项的具体形式——它是一个很小的文件，但它决定了"有人发现漏洞时，知道该找谁"。
  2. 找到你常用软件或系统的"安全公告"页面，订阅它的更新提醒（大部分厂商都有专门的 security advisory 页面或邮件列表）。理由很实际： 从"厂商发布公告"到"新闻开始报道"之间，通常有几小时到几天的差——而那段时间正好是你打补丁的黄金窗口（4-2）。

这一节要带走的一句是：漏洞信息在修好之前是危险品、在修好之后是公共品——所以所有制度的争点都是同一个：这个转换的时机由谁来定、按什么流程走。

常见误区

  1. 错误：发现了漏洞，应该马上公开，让大家都知道去防。——纠正："马上公开"在没有补丁的情况下，实际效果是"把攻击方案发给所有人"——包括那些本来还不知道这个漏洞的人。 这就是所有制度都写"先修好、再公开"的原因（中国《规定》第 ② 条：不得在厂商修补措施之前发布）。更现实的一层是： 公开的漏洞会被自动扫描器在 15 分钟内开始试探（4-2）——也就是说，"公开"这个动作本身就是一次攻击的开始信号。 正确的做法是"协调披露"：报告给厂商（或平台），约定一个公开时间点，等补丁就绪后一起发布；如果厂商长期不回应，则按行业惯例（比如 90 天）到期公开——这个"到期公开"的压力，正是督促厂商修复的机制。
  2. 错误：我只是个用户，报告漏洞这种事跟我没关系。——纠正："报告"不是只有安全研究者才做的事。你遇到一个疑似漏洞的现象（比如输入一个单引号就报出数据库错误、某个页面能未授权访问、密码重置链接能被复用），把它交给厂商，就是一次有效的报告——门槛比想象的低得多。 而且从制度上看，"任何组织或个人"都是这条链上的一环（中国《规定》第 ② 条约束的是"任何组织或个人"）。实际的做法很朴素： ① 找厂商的安全响应中心（security advisory 页面或 security.txt）；② 描述现象和复现步骤，不要公开细节；③ 留一个联系方式等回复。
  3. 错误：静默修复（不声不响地修掉漏洞）是好事，反正问题解决了。——纠正："静默修复"在国际指南里被明确列为"不得为之事"（2026 年 7 月那版指南的要点之一）。原因是它破坏的是整个协作机制的动机：研究者花时间找到并报告了漏洞，如果厂商不声不响地修掉、连个致谢和 CVE 编号都不给，那么下次还有谁会报？ 这也是为什么"发布的公告要带 CVE 编号"是硬要求——编号是"这个漏洞被承认了"的凭据，它让下游（扫描器、资产管理系统、其他用户）能自动消费这条信息。所以"静默修复"看似省事，实际是在消耗整个生态的信任储备。
  4. 错误：我是小公司/个人，这些法规跟我没关系。——纠正：这些制度的约束对象确实主要是"网络产品提供者"和"平台"，但它们间接决定了你每天用的软件怎么被维护。具体影响有三层：① 你用的产品的补丁发布节奏会被这些时限影响（比如欧盟的 24/72 小时时限，会让厂商在漏洞处理上更及时）；② 你能获取的漏洞信息格式在变好（机读公告、CVE 编号、CVSS v4.0 评分，让自动化的补丁管理成为可能）；③ 如果你自己对外提供软件或服务，那你就是"网络产品提供者"——这时 2 日内报送、不得提前公开这些条款就直接适用了。 所以"跟我没关系"这个判断的前提是"我不提供任何软件或服务"——而对大多数组织来说，这个前提并不成立。
自测三问（点开对答案） 1. "先修好、再公开"这条铁律，为什么所有制度都要坚持？ —— **因为漏洞信息有一个特殊的性质：它在"修好之前"是一份完整的攻击方案**。**一旦公开，看到它的人里既包括要防御的人，也包括要利用的人**——**而两者的行动速度完全不对等：防御方要走完"评估 → 测试 → 排期 → 部署"，攻击方只要"照着试"。** **所以"先修好、再公开"不是形式上的顺序，而是把这段时间差还给防御方**。**现实数据也支持这一点：** **公开之后，全网自动扫描平均 15 分钟内就开始**（4-2）——**也就是说，公开的那一刻，"没人注意到"这个缓冲期就结束了。** **而"到期强制公开"（比如 90 天）是这条铁律的必要补充：** **它防止厂商用"保密"来逃避修复。** 2. 为什么"发布公告要带 CVE 编号"这样的细节，会被写进指南？ —— **因为它是"自动化"的前提**。**今天的漏洞量级已经不可能靠人读公告来处理**（**一年 6 万个以上**，**4-1**）——**下游的资产管理系统、漏洞扫描器、补丁管理平台，都是靠"编号"来匹配"我有没有这个组件、这个版本"的。** **没有编号，这条漏洞信息就只能被人读到，无法进入任何自动化流程。** **《规定》里那条"发布内容须同步发布修补或防范措施"，讲的是同一个道理的另一面：** **公告必须带上"怎么办"，否则收到信息的人除了紧张什么都做不了。** **所以这些看似格式化的细节，实际决定的是"这条信息能不能变成行动"。** 3. 中国《规定》和国际协调披露指南，两者的侧重有什么不同？ —— **中国《规定》侧重"监管可见性与信息流向控制"**：**明确要求在 2 日内向主管部门报送（让监管方及时知情）；明确禁止在修补前公开、禁止发布利用工具、禁止向境外提供未公开信息（约束信息的扩散方向）；对收集平台提出备案和日志留存要求（管理信息集散的载体）。** **国际指南侧重"研究者与厂商之间的协调流程"**：**规定厂商的确认时限（2~3 个工作日）、规定修复后回传验证、反对静默修复、反对一刀切保密协议、提倡安全港（让研究者不必担心被追究）。** **两者的共同点是那条铁律："先修好、再公开"**；**差别在于：一个管"信息报给谁、能不能往外流"，一个管"厂商和研究者之间怎么配合"。** **欧盟的做法是把两者都写成了硬时限（24/72/14 天）并建了单一报告平台**——**可以看作是这两条路线的合流。**

相关笔记