摘要

  • draft-bruhns-securitytxt-product-security-00 于 2026 年 9 月 10 日发布，提议为 RFC 9116 的 security.txt 格式增加两个可选字段：Product-Security 与 Product-Security-Policy。
  • 前者指向产品漏洞报告入口，可以重复并以排列顺序表达优先级；后者只能出现一次，指向一份 HTTPS 产品安全政策。
  • 这是一份个人 Internet-Draft，并非 IETF 工作组采纳文件、已批准标准或已登记扩展；IANA 当前字段表里还没有这两个名称。
  • 分开收件队列只能改善第一跳。它不能证明具体型号、版本、贴牌产品或第三方组件由哪支团队接手。

报告找到了门，产品还没有归属

设想一台仍在客户网络运行的路由设备。机身沿用被收购前的品牌，管理界面显示新的集团名称，固件里又打包了外部维护的组件。研究人员从集团官网找到 security.txt，把报告发到产品安全地址，并收到工单号。

从投递角度看，流程没有坏。真正的不确定性是：当前团队是否维护这个型号，问题落在自研代码还是第三方组件，旧版本是否仍有补丁责任，区域经销商能否代表制造商接受协调披露。若工单只留下“邮件已收”，这些问题一个也没有回答。

这与“漏洞披露信箱是否存活”不是同一个命题。入口可以畅通，责任仍可能在多个组织之间漂移。URI 决定报告从哪里开始，不会自动把研究人员手中的制品绑定到一个能作出修复决定的主体。

两个字段做的是分流

IETF Datatracker 页面把 Product Security Fields for security.txt 标为个人 Internet-Draft。历史记录截至观察时间只列出 9 月 10 日提交的第 00 版。个人可以提交 Internet-Draft；这不表示 IETF 已背书、工作组已采纳，更不表示它已经成为 RFC。

第 00 版文本允许 Product-Security 多次出现，每一项都是产品漏洞报告联系 URI，并沿用 Contact 的 URI 约束。发布者用先后顺序表达偏好。这样，网站自身的漏洞与所售产品的漏洞可以进入不同队列。

Product-Security-Policy 至多出现一次，而且必须使用 HTTPS。草案建议政策说明覆盖哪些产品、如何确认和分诊、预期响应时间、披露与禁运安排、匿名报告办法，以及对善意研究的保障。

这张清单把“范围”写进了治理问题，却没有把范围变成机器可验证的产品身份。政策页可以写清型号与生命周期，也可以只写一句宽泛承诺。字段本身不判断哪种情况发生了。

拟议登记不等于已经登记

草案请求 IANA 以 Expert Review 政策登记两个字段。截至证据截止时间，IANA 的 security.txt 字段表仍未列出 Product-Security 和 Product-Security-Policy。表中现有 Contact、Expires、Canonical、Encryption、Policy、Preferred-Languages，以及后来登记的 CSAF、Bug-Bounty、Hiring 等字段。

因此，新闻事实是“提出了登记请求”，不是“字段已经进入注册表”。RFC 8126所说的 Expert Review，是由指定专家按登记政策评估请求。草案中的 IANA Considerations 不能替代这个决定。

现阶段仍可试验，因为 RFC 9116要求解析器忽略不认识的扩展字段。新草案也因此建议普通 Contact 继续接收产品漏洞，以免旧解析器看不到专用入口后无路可走。这个兼容安排降低迁移风险，却不能证明新字段已获得普遍互操作性。

Web 来源不是产品目录

RFC 9116 把文件的通常适用范围系在其获取来源上：为某个域名或 IP 地址取得的文件适用于该资源，不会自动覆盖父域或子域。组织可以借它公布产品与服务的安全联系信息，但标准没有定义型号、版本、固件分支或维护者变更的产品注册表。

研究人员掌握的证据往往恰好在另一侧：包坐标、硬件型号、序列号范围、软件版本、构建号或 commit。发布者掌握的是域名、政策和队列。若没有一条记录说明这些标识为何落入某条政策，后来的人只会看到一封发往品牌域名的邮件。

贴牌销售会让品牌与制造责任分离；收购会让官网与旧产品团队分离；开源组件会让修复权分布在上下游；停止支持会让“曾经负责”与“现在接手”分离。产品边界会随版本移动，而 security.txt 文件所在的域名可能多年不变。

Product-Security-Policy 的价值正在这里：它给发布者一个地方说明这些边界。价值来自政策内容是否具体、是否留有版本，而不是字段是否出现。

到期、规范地址和签名各管一件事

RFC 9116 要求 Expires，让读取者识别过期信息；它提供 Canonical 来声明预期位置，也建议对文件签名。原因很实际：如果攻击者能篡改发布页面，就能把研究人员引向自己控制的联系地址。

这些控制保护的是发布证据。签名成功说明内容与某个密钥保持联系，不说明签名者维护某个组件；规范 URL 指定哪份文件是预期副本，不说明哪一代产品受覆盖；未过期说明联系信息仍在声明期内，不说明接收团队已经认领报告。

RFC 还明确把发现入口与测试授权分开。有没有 security.txt，都不会自动授予或拒绝测试许可。政策可以描述善意研究保障，但适用产品、行为和法域必须从具体文本中读取，不能从字段名推导。

给制品到责任人的交接留一张回执

一张可核查的回执，应先保留研究人员提交的制品标识：产品系列、型号、组件或包坐标、版本、构建、固件分支与分发渠道，能确认多少就记录多少。随后保存 security.txt 的来源与规范 URL、获取时间、Expires、签名结果，以及实际选用的 Product-Security 项和它的优先顺序。

回执还要固定 Product-Security-Policy 的 URL，并保存内容哈希或版本号。接收方需指出依据哪条范围条款接受、拒绝或转交，哪支团队取得保管责任，以及返回了什么工单或交接编号。漏洞细节不必公开，决策边界却不能只留在临时邮件里。

这张回执是 Daniel Kade 的编辑建议，不是第 00 版、RFC 9116 或 IANA 的要求。它也不重复“联系通道是否可用”的检查。通道回执回答报告有没有到达；制品回执回答到达以后，谁为哪一件东西作出了责任决定。

来源