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