W3C 感谢研究人员对其
工作所作的评论。W3C 的回应将取决于
问题所在的技术报告类型、问题的严重性以及
解决方案的复杂性。
W3C 将尽力尽快解决和纠正安全问题。它遵循的流程基于
ISO/IEC 29147（漏洞披露 - VD）和 ISO/IEC 30111（漏洞
处理 -
VH）的推荐步骤。
W3C 根据报告安全问题的文档类型和
成熟度来处理并路由报告。
如果你认为自己在 W3C
文档中发现了漏洞，请联系 standards-vulnerability@w3.org 以进行
协调
披露。
此电子邮件是由 W3C 团队和相关小组组成的、被指定用于协调
漏洞披露与处理的小组进行评估和采取行动的参考点。
建议使用 PGP 密钥向 standards-vulnerability@w3.org 发送加密消息。此
电子邮件
没有公开归档。
为促进流程，你的安全通报应包括
ISO/IEC
29147 和 NIST SP 800-216 推荐的详细信息，例如：
- 存在漏洞的具体文档（例如其标题、
稳定 URL 和
发布日期）。
- 对漏洞类型的简明描述（例如，使用不安全的
加密
算法）。
- 重现漏洞的步骤，最好是良性、非破坏性的概念
验证。
- 利用此漏洞的影响以及它如何用于攻击
场景。
- 拟议的纠正或缓解措施，如有。
- 你的联系方式（可选，以支持匿名报告，但有助于后续
澄清）。
请注意：
- 没有“漏洞赏金”： W3C 不会为报告的
漏洞支付
“漏洞赏金”。
- 保密性：参与本政策的报告者和协调者
将
尊重在履行其任务过程中获得的信息和数据的保密性，特别是
涉及
知识产权、商业机密信息以及公共和国家安全
利益。
敏感漏洞信息应以保密方式传达，以最大限度降低风险。
- 研究人员保护：W3C
认识到善意安全研究的重要性。W3C
将为信息安全研究人员提供不起诉信息和民事责任豁免，
针对其活动，承认漏洞研究人员面临的挑战。此
政策旨在与常见漏洞负责任披露良好实践
兼容，并且不
允许以违反适用法律的方式行事。
一旦收到，安全问题将在 3 个工作日内得到确认，并与报告者建立
沟通渠道。
在确认之后，将评估安全问题，以确定其有效性、技术
关键性、
重要性和潜在影响。
W3C 将力求验证问题的有效性并在
15 个工作日内通知报告者。如果
需要更多信息来验证安全问题，W3C 将向来源请求更多详细信息。
安全通报将根据其所指文档的类型进行处理。
W3C 随后将与报告者以及受安全问题影响的小组
合作，这将
主要涉及更新相关文档。
这些是已经完成并经过社区审阅的标准。
根据 W3C 流程，第 3 类或第 4 类变更可能触发
更广泛的审查和专利政策影响。
该问题将在 GitHub 上的安全问题功能中处理。
这些是已被 W3C 工作组采纳、
但尚未最终确定的文档。
- W3C 工作组应及时正式处理关于
技术报告的任何实质性审阅意见。
该问题将在相关工作组邮件列表或 GitHub 上的安全问题
功能中处理。
这些不是 W3C 中正式采纳的文档。
尚未作为 W3C
规范发布的编辑草案没有官方地位。
- 该问题应与文档编辑一起处理和讨论。
- 尽管未被正式采纳，该问题也可以在相关工作组
邮件
列表或 GitHub 上的安全问题功能中讨论。
该问题将在相关工作组邮件列表或 GitHub 上的安全问题
功能中处理。
- 被标记为已停止、过时或已撤销的 W3C 技术报告
不太可能
针对其采取行动来回应安全问题报告。尽管如此，团队
仍应评估
是否在文档状态（SOTD）中列出这些问题。
该问题将在 GitHub 上的安全问题功能中处理。
这些不是 W3C 中正式采纳的文档。
成员提交是由成员提出以供考虑的文档。
该问题将根据该成员的政策处理。
一旦更新已经可用，并且已经留出足够时间来实施
相关技术的更新和
发布，W3C 鼓励共享
并公开披露已修复
漏洞的信息，包括对漏洞的描述、允许用户
识别
受影响标准的信息、影响、严重性，以及帮助
实现者和
用户补救的清晰、可访问的信息。在某些情况下，如果发布的安全风险超过安全收益，
披露可能会
推迟到实现者和用户有机会应用相关
对策之后。
W3C 欢迎在漏洞
已解决后披露你的报告的请求，并力求协调
公开发布。如果报告者希望获得公开认可，W3C 将致谢其报告
该漏洞，前提是报告者希望被公开署名。