摘要

  • RFC 9116 规定了漏洞报告联系信息的发现位置、格式和失效时间，但不会证明邮件真正送达、表单真正建单，或队列已经有人负责。
  • 一份可信的披露通道回执，应把抓取到的文件及其期限，与无敏感内容的端到端探测、投递结果、收件确认、责任归属、升级目标和重测触发条件绑定起来。

分析

一家机构的 /.well-known/security.txt 每年按时更新。文件能通过语法检查，Contact 指向安全邮箱，Policy 可以打开，Expires 还有十个月才到期。资产看板因此显示绿色。可在一次组织调整中，原来的邮箱组被删除，新团队以为旧别名会自动迁移。直到外部研究人员提交真实报告，永久退信才暴露出断点。

这里失效的不是发现标准，而是对标准能力边界的理解。

RFC 9116 解决的是一个重要而具体的问题：研究人员不必在客服页面、销售表单和社交媒体之间猜测报告入口。有效文件至少要有一个 Contact，也必须且只能有一个 Expires。用于网站时，它应位于 /.well-known/security.txt，通过 HTTPS 提供，并采用 UTF-8 纯文本。IANA 的知名 URI 注册表把 security.txt 列为永久条目，变更控制方为 IETF。这些规定建立了可互操作的发现面。

失效日期也不是装饰。RFC 9116 规定，超过 Expires 后，文件内容应被视为陈旧；它建议期限不要放到一年以后。安全注意事项直接指出，错误或过时的信息可能让报告无法到达机构，甚至送到错误的一方。定期重新审阅公开坐标因此是标准价值的一部分。

但未来日期是发布者对文件内容的声明，不是邮件系统、表单服务或工单平台给出的运行证据。把日期顺延，只能说明有人改过文件，不能说明外部邮件可进入，也不能说明收到的报告会被分派。

两只时钟不能互相代替

第一只是发布时钟：何时生成文件，何时核对字段，何时失效。第二只是服务时钟：报告何时被传输系统接受，何时收到确认，何时进入初评，何时分配给系统负责人，何时升级并告知结果。文件刷新不能替第二只时钟走完流程。

从发现到处置，至少有五道边界。

第一道是适用范围。RFC 9116 说明，文件通常只适用于获取它的域名或 IP 地址，不会自动覆盖上级域和子域。政策页面可以说明更多产品或服务，但必须明确建立联系。集团主站的安全地址，不当然代表新收购业务已经接入同一队列。

第二道是传输。一个格式正确的 mailto: 可能只允许内部发件人；表单首页可能正常，提交动作却因验证码、存储或接口故障而失败；第三方平台可能建了工单，却没有把通知送给客户。成功下载文件，对这些环节都没有证明力。

第三道是保密。Encryption 字段指向密钥位置或指纹，不把密钥本身装进文件。RFC 9116 还明确提醒研究人员自行核实密钥真实性。即便公开密钥可获取，也不能推断当班团队仍掌握解密能力，更不能推断密钥交接已在人员变动后完成。

第四道是收件确认。稳定的工单编号或可追踪回执，才把“某个传输节点接受了消息”推进到“机构开始保管报告”。自动回复有帮助，但只有当它对应真实受监控的队列，并能与之后的处置记录对应时，价值才完整。

第五道是处理权责。谁做初评？超出范围的报告转给谁？谁协调修复？何时通知报告人？CISA 的第 20-01 号约束性运行指令，为其适用的美国联邦文职机构展示了这一层。指令要求把报告跟踪到解决，协调内部修复，评估影响与优先级，处理范围外报告，并与报告人及其他相关方沟通；还要求为确认、初评和解决设定目标时限。这不是 RFC 9116 的新增条款，也不是全球通用法律，而是公开入口之后还需运行治理的官方例证。

回执不能伪装成漏洞报告

最小修复工具是一份披露通道存活回执。它先记录公开事实：规范抓取地址、文件指纹、抓取时间、声明的 Expires、对应主机或服务范围，以及按 Contact 排序选用的首选入口。如果使用表单或加密，还要保存表单版本或当时看到的密钥指纹。

然后是一条经过收件团队授权的合成探测。探测内容明确标识为路由检查，不含真实漏洞、利用代码、账号秘密、个人资料或夸大严重性的描述，并告诉收件方如何关闭测试。回执记录发送时间、传输接受或拒绝、确认时间、工单编号、当前队列负责人和替补负责人，以及初评、升级和结果沟通的目标。

每个结果必须保持狭义。SMTP 的成功响应，只证明某一跳接受了邮件，不证明分析师看到它；表单显示“谢谢”，只证明页面返回，不证明数据库持久化；自动回复只证明规则触发，不证明有人接管。没有测试的升级路径应写“未测试”，不能继承邻近字段的绿色。

测试也不能成为骚扰。频率应由风险和变更驱动，而不是不断制造假警报。邮件或 DNS 迁移、表单发布、身份系统替换、密钥轮换、供应商交接、队列负责人变更、政策重写、新域名上线，都应触发有针对性的重测。平时只需在公开期限内采用克制的周期。收件方应预先认可探测标识，避免它与真实报告争抢处置资源。

让文件继续做它擅长的事

增加回执并不会削弱 security.txt。文件仍是面向公众的统一发现入口，Canonical、Policy、Preferred-Languages 和 Encryption 分别减少适用地址、授权政策、语言和保密方面的歧义；数字签名还可增强来源与完整性证据。

回执回答的是另一个问题：公开声明的路径，上一次在何时完成了从发现到组织接管的最小闭环？“文件有效，邮件已接受，未收到确认”是有用结果；“表单已建单，负责人存在，替补未确认”也是有用结果。部分成功比一个总分更能指向修复位置。

面向看板的摘要可以很短：9 月 7 日抓取规范文件；次年 3 月 1 日失效；首选联系人接受探测；14 分钟后收到工单确认；队列负责人已核验；升级路径未测试。每一项有自己的证据和观察时间，没有一项声称未来的真实漏洞一定有效、一定会被正确排序或按期修复。

来源

  1. RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure
  2. IANA 知名 URI 注册表
  3. CISA 第 20-01 号约束性运行指令