W3C、威胁建模与CRA：GDC 2026参会报告

2026年9月2日，我参加了在日内瓦举行的全球数字协作大会（GDC 2026），与来自ETSI和Red Hat的贡献者共同参与了题为“将《网络弹性法案》付诸实施：制造商、开源管理方和安全团队现在需要做什么”的专题讨论。

Simone Onofri在此前关于GDC的博文中，介绍了W3C为本次会议带来的标准组织、实施方及其他社区之间的协作。在专题讨论中，我介绍了自己对ETSI EN 304 617的贡献。这是一份欧洲统一标准草案，依据《网络弹性法案》（CRA）为浏览器规定网络安全要求和评估标准。

负责EN 304 617的ETSI报告人联系了W3C征求反馈，Simone Onofri、Luca Lumini和我以W3C安全兴趣组（SING）成员的身份作出回应，并各自署名提交了我们的联合意见。ETSI随后决定重构该草案，我参与了这项工作，相关内容我们已在2026年3月的W3C分组讨论上做过介绍。

尽早将威胁建模引入标准

我在发言中提出的论点是：威胁建模应当从最早期阶段就纳入技术标准化工作。在产业界，这有助于在技术开发过程中纳入安全和隐私考量，而此时缓解措施尚可实施。同样的道理也适用于Web和ICT标准：威胁建模让我们能够在整个生态广泛采用之前，先审视潜在问题。

我介绍了W3C现有的将威胁与危害建模引入技术标准化的各项工作，包括《威胁建模指南》《Web威胁模型》和《去中心化凭证威胁模型》。这些已发布为W3C小组备忘草案，旨在帮助审视系统、识别威胁与危害并考虑应对措施。

从一条评审意见到修订后的浏览器草案

为支持我的论点，我讲述了一段个人经历。我参与CRA的ETSI浏览器标准制定，始于对该标准成熟草案提出意见。2026年2月，我与Simone Onofri、Luca Lumini合作，联合提交了建设性反馈意见。我们提出了若干修改建议，包括更清晰的产品边界、通过安全结果体现需求，以及引用那些已经定义了Web安全机制的规范。

我们呼吁将威胁建模明确纳入第4条以及与风险相关的附件，作为风险评估的前置步骤。其思路是通过浏览器的组件、数据流和信任边界来描述该产品，并将威胁和适用的要求与该模型关联起来。

包括主要浏览器厂商在内的其他组织和利益相关方，也对这份成熟草案提出了意见。例如，关于流程架构的公开反馈对可能限制浏览器设计演进的要求提出了质疑。负责该工作项的ETSI小组接受了部分反馈，最终决定重启该标准，并邀请我以及其他人士参与这项工作。

我撰写了第4条和附件B，两者均为该标准的资料性内容。我特别引用了W3C《威胁建模指南》作为威胁建模方法论的参考，包括对已识别威胁的应对。我还引用了W3C《Web威胁模型》作为资产和威胁的参考。自7月份的草案以来，第4条描述了浏览器产品及其背景和架构。附件B提出将威胁建模作为风险分析和风险接受的前置步骤。

当已有现成工作时，引用它远比重新发明或照搬要容易得多。对于浏览器网络安全要求而言，直接引用W3C安全兴趣组发布的《Web威胁模型》是顺理成章的选择。

我从这段经历中的收获

在我看来，修订后的草案已有明显改善。该草案在推进过程中已将威胁建模纳入其结构。截至2026年9月10日，ETSI将1.0.0版列为处于公开征询（Public Enquiry）阶段。

我认为这一进展是一个令人鼓舞的信号，说明威胁建模能够融入既有的标准化流程。这并不能证明结果是仅靠威胁建模取得的：此次修订反映了许多改动以及其他贡献者的工作。我在专题讨论中的主张是，这项工作应当更早开始，而不是等到成熟草案需要大幅重构时才着手。