提供一个容易找到的报告入口
有人在您的网站上发现疑似问题，希望向您反映。如果对方需要在销售、客服与多个服务商之间寻找联系人，就会产生不必要的延误。清晰的报告渠道能让双方受益：报告者知道发给谁，企业也能收到便于判断的信息。
RFC 9116 描述了 security.txt。对于 Web 服务，文件通过 HTTPS 发布在 /.well-known/security.txt，Contact 和 Expires 是必填字段。
可以先做一份简单清单：企业拥有哪些公开域名、分别由谁运营、各域名的安全报告应发往何处。在公开联系方式前，与实际处理报告的人确认这些安排。 [1]
让收件箱有明确负责人
指定一位负责人和一位替补。约定谁查看新消息、谁判断技术问题，以及负责人不在时由谁接手。如果涉及多家服务商，应事先明确每家负责的服务。
安排一次经过明确同意、内容无害的送达测试，并使用容易识别的邮件主题。不要只确认发件成功：消息是否进入指定收件箱、是否进入处理流程、负责人能否回复？仅凭文件可以访问，无法确认这些环节。
共享工单或内部编号就可以作为起点。记录接收时间、受影响的服务、负责人和下一步行动。避免把敏感内容转发给不必要的大范围收件人。
看清报告的处理路径
图中区分了四项工作：公开文件指明联系方式；入口接收报告；被指定的负责人确认报告是否涉及企业系统；回复让沟通能够继续。
小型团队同样可以采用这种安排。关键是交接清楚：现在由谁处理、还有什么问题未解决、何时确认下一步？如果受影响的服务由外部服务商运营，也要明确转交给服务商的过程。
/.well-known/security.txt
公开可查
Contact:报告地址或表单
Expires:公开信息的有效期
接收
记录报告并确认收到。
责任分配
确认受影响的服务及负责人。
反馈
记录下一步行动和回复渠道。
文件帮助报告者找到入口。责任分配与后续回复需要企业内部安排。
同时写清联系方法与测试规则
仅仅公开一个联系地址，并不等于委托对方进行安全测试。应当区分报告已有观察与获得进一步测试的授权。
NCSC 建议制定清晰的漏洞披露政策，说明联系渠道、所需信息、预期回复及允许开展调查的边界。
对于首次联系，我们建议提供受影响的地址、简短描述和观察时间。此时不需要密码或大量个人数据。如果确实需要补充证据，再约定合适的传输方式。公开承诺的回复时限，应当是团队能够稳定履行的。 [2]
发生变化时一并复核
把安全联系方式作为日常运营资料维护。域名迁移、更换 IT 服务商或人员离职时，都应将它纳入检查清单，并在公开信息到期前安排复核。
初步复核可以很简洁：访问公开文件，将其中信息与内部责任分工核对，再检查约定的报告渠道。记录检查日期和结果。这样，文件就不只是一次性上传的文本，而是持续维护、能够接收有效安全报告的入口。
同时检查字段与 HTTP 响应
对于 Web 服务，文件应通过 HTTPS 在 /.well-known/security.txt 提供，使用 UTF-8 文本和 text/plain 媒体类型。返回 200 状态的 HTML 错误页面并不是有效的 security.txt。需要同时核对正文与响应头。
适用范围有明确边界：example.com 上的文件不会自动覆盖其子域名。请逐一记录目标主机。下表仅列出部分字段，不构成完整的 RFC 9116 合规检查。 [1]
左右滑动可查看完整表格。
| 字段 | 要求 | 实际检查 |
|---|---|---|
| Contact | 必填；至少一个联系 URI。 | 电子邮件使用 mailto:；事先约定并验证投递测试。 |
| Expires | 必填；恰好一个 RFC 3339 时间戳。 | 检查有效期并安排到期前更新；建议距离当前时间少于一年。 |
| Preferred-Languages | 可选；实际支持的语言。 | 只列出能够处理安全报告的语言。 |
| Canonical | 可选；文件预期的 HTTPS 地址。 | 与实际访问地址比对。 |
| Policy | 可选；漏洞披露政策链接。 | 说明联系渠道、允许的范围和回复流程。 |
记录检查结果并明确负责人
此清单将公开文件与内部报告流程关联起来。每个域名使用一份副本，填写实际观察结果并安排复核。它不是自动扫描器，也不能单独证明配置安全。