简介

处理安全问题有两个方面：一个是安全问题在项目中进行报告和修复的过程，另一个是公众如何了解问题以及可用的补救措施。

PSR 9 解决了前者， 而后者，则由 PSR 10 则处理

因此，PSR 10 的目标是定义如何向公众披露安全问题，以及此类披露应遵循何种格式

特别是在当下，PHP 开发人员比以往更多地跨项目共享代码，这个 PSR 旨在缓解所有依赖项中的安全问题概述以及解决这些问题所需的步骤

本篇规范中的 必须，不得，需要，应，不应，应该，不应该，推荐，可能 和 可选 等词按照 RFC 2119 中的描述进行解释

目标

该 PSR 的目标是为项目主管提供明确的方法，让最终用户能够使用明确定义的结构化的格式来发现这些披露的安全问题

披露发现

每一个项目 必须 在明显的位置提供一个链接用于披露其安全漏洞。理想情况下，这个位置应该在项目主域名的根页面上

如果是一个较大项目中的子目录，这也 可能 是一个子域名 ，如果项目有的专门的披露页面，那么这也被视为是放置链接的好地方

链接可以使用自定义链接引用 php-vuln-disclosure 即

<link rel="php-vuln-disclosure" href="http://example.org/disclosures"/>

注意，项目可以选择将其披露文件托管在主项目页面以外的其它域名中

建议不要将披露信息保存在 VCS 中，因为这会混淆哪个分支机构是其相关的机构

如果使用 VCS，则应采取其它方法清楚地向用户记录哪个分支包含所有版本的所有漏洞。如果有必要，可以将漏洞披露文件按主要版本号分开，这样就能够清楚地记录下来

披露格式

披露格式使用基于 XML 的 Atom, 然后使用了 It leverages the "The Common Vulnerability Reporting Framework (CVRF) v1.1" 2. Specifically it leverages its dictionary 3 as its base terminology.

TODO: 我们是否还应该提供 JSON 格式的数据来降低项目的栏数。这样聚合服务可以根据这些 JSON 提供 ATOM 格式的披露

Atom 扩展 允许对漏洞进行结构化的描述，以便于自动化工具能够检查安装是否可能收到漏洞的影响。但是，可阅读性往往是最重要的，所以，不能只使用完整的 CVRF

TODO: 审阅 Atom 格式和提供的 XSD

请注意，对于每个漏洞，只能创建一个条目。如果有任何信息发生变化，原始文件必须与最后更新字段一起更新

使用 entryType 的任何公开披露都可以使用下表列出的 ATOM 命名空间下标签 ( 所有必须标签都有 「 必须 」 字样 ):

此外，添加了下表列出的标签