当组织或个人希望为CWE提交新内容时，CWE计划建议使用官方CWE内容Web提交表格开始过程。
所有新内容都必须遵守使用条款。
Web提交表有五个必需的元素：
- 提交者联系信息
- 提交详细信息
- 相关弱点
- 参考
- 评论和提交
单击“提交”后，您将收到一条确认消息，您的建议将被添加到CWE团队的工作队列中。
外部提交审查过程
| 阶段 |
描述 |
| 提交 |
外部贡献者将初始内容提交给Web服务器；提交提供给CWE内容团队。 |
| 审查 |
CWE团队审查Web表单提交，以确定是否适合CWE。 |
| 咨询 |
CWE团队与提交者合作，就如何管理建议的弱点达成共同的协议。当提交复杂或认为需要公众审查或讨论时，CWE团队将咨询CWE研究人员名单。 |
| 决定 |
CWE团队确定CWE中应包含哪些内容。在与提交者进行内部审议和沟通之后，CWE团队可能会由于几个原因决定建议的内容不适合CWE的范围（请参阅常见问题以下）。另外，CWE团队可以决定（1）创建一个新条目，（2）将提交的信息集成到现有条目中，/或（3）创建其他支持条目，以促进CWE的主要视图（开发，研究人员，研究人员，研究人员，和架构）。 |
| 支持分析 |
要求提交者通过通过电子邮件发送完整的.txt文件来向条目提供进一步的必需详细信息“ CWE详细内容提交表”。 |
| 收据和审查 |
CWE团队将收到其他详细信息并审查它们。如果需要任何澄清，CWE团队将与提交者联系。 |
| 新的进入创建 |
CWE团队分配官方ID，并在其内部（非公共）存储库中创建一个新的条目/条目，将提交内容转换为XML。 |
| 新版本出版物 |
CWE团队创建了CWE的官方版本并发布。这包括新内容以及必要的新版本的模式和/或支持文档。 |
目前，CWE程序每3或4个月发布一次新版本，尽管没有固定的发布时间表。
将内容建议集成到CWE中的常见问题
CWE团队已经从以前的内容建议中确定了以下因素，这些因素可能会延迟或最终影响您的内容建议是否集成到CWE中。
- 提交不是以弱点为中心的。有时根据缺乏特定保护机制表达的弱点有时会更容易理解弱点。这不是CWE条目的定义方式。它可能需要额外的努力来进行根本原因分析以识别潜在的弱点。
- 提交需要在CWE内进行其他重组。尽管已经对与数字计算，缓冲溢出，注入等相关的弱点进行了广泛的研究，并且在CWE中具有稳定的组织方案，但CWE的其他部分也不太成熟。与CWE的这些部分相关的提交可能需要更广泛地重组相关的关系，从多个视图中，可能迫使创建或贬值多个条目，而不仅仅是原始提交。
- 提交需要额外的研究才能包括。新发现的弱点尤其如此。在某些情况下，如果需要原始研究，则进行原始研究以快速解决提交或需要高度专业化的知识以了解问题可能太大了。
- 并非所有请求的信息提供。
- 描述不是清楚地写的。
- 提交元素缺失或不遵循指南。
其他支持信息
以下旨在作为补充指导信息，以帮助阐明遵循Web表格的总体提交过程。
目录
其他信息
| 话题 |
解释 |
| 词汇表 |
CWE中常用术语的词汇表。CWE试图使用受限制的词汇来最大程度地减少不一致。 |
| 脆弱性理论 |
该文档包括CWE如何分类和代表弱点的基础的一些核心概念。这些概念直接影响了CWE团队描述弱点的方式。 |
| 模式 |
CWE内容的XML模式定义（XSD）。这包括各种枚举，阐明CWE如何代表一些关键信息。 |
要包括的元素
以下是最终需要确定CWE语料库新条目的最小元素列表。
个人元素指南
以下是有关提交中要包含的每个最低预期元素的其他详细信息。
姓名
理想情况下，名称着重于弱点/错误 - 而不是攻击。最大程度地减少使用模棱两可的单词以使名称简短。在可行的地方，请使用CWE词汇表和/或漏洞理论文档中定义的术语。名称应包括：（1）代码的预期行为，（2）错误（即弱点），（3）受影响的资源（如果相关），以及（4）受影响的技术（如果相关）。
首选使用CWE特异性词汇，但不需要。
概括
摘要仅由一个或两个句子组成，这些句子描述了弱点本身，即犯的错误。通常，摘要会描述开发人员/设计师正在尝试做什么。摘要的关键部分包括：（1）代码的预期行为，（2）错误（即弱点），（3）受影响的资源（如果相关），以及（4）受影响的技术（如果相关）。每个摘要部分仅以单个单词或简短的短语表示；扩展描述的解释可能更全面。
首选使用CWE特异性词汇，但不需要。
摘要（和名称）应避免关注：（1）攻击，（2）缺乏缓解措施，或（3）技术影响。如果摘要对此信息有很大的依赖，则可能表明该条目不是针对弱点的。
扩展描述
扩展描述为弱点提供了其他解释。通常，预期的受众是开发人员/设计师，他可能不会立即了解弱点如何成为问题，或者可能对问题有过度简单的理解。
首选使用CWE特异性词汇，但不需要。
扩展描述可能由多个段落组成，但通常只有一两个段落。
扩展描述：
- 解释为什么弱点应该成为开发人员/设计师的关注。
- 简要总结可能导致的技术影响。
- 给出对问题更广泛理解所必需的微妙或变化。
介绍模式
这提供了有关如何以及何时引入给定弱点的信息。如果存在，则可以提供多个介绍点。
| 元素 |
描述 |
| 阶段 |
指示开发生命周期中可能引入弱点的点（或点）。该阶段可以覆盖一个或多个：政策，，，，要求，，，，建筑和设计，，，，执行，，，，构建和汇编，，，，测试，，，，文档，，，，捆绑，，，，分配，，，，安装，，，，系统配置，，，，手术，，，，修补和维护， 和移植。 |
| 笔记 |
（可选）在给定阶段可以引入弱点的典型情况。 |
潜在的缓解
该元素应涵盖一种或多种技术，以消除和/或降低弱点的频率或影响。
| 元素 |
描述 |
| 阶段 |
该元素表示可以应用特定缓解措施的发展生命周期阶段。从模式6.6开始，该阶段可以涵盖一个或多个：政策，，，，要求，，，，建筑和设计，，，，执行，，，，构建和汇编，，，，测试，，，，文档，，，，捆绑，，，，分配，，，，安装，，，，系统配置，，，，手术，，，，修补和维护，，，，移植，，，，一体化， 和制造业。 |
| 描述 |
缓解措施的免费形式描述。在可行的地方，应尽可能地写下缓解措施，以说明不同语言，框架，技术等的变化。但是，同时，它应该尽可能具体地对弱点进行特定。不建议使用模糊或通用短语，例如“验证输入”，“深入使用防御”或“使用安全算法”。 |
| 效力 |
缓解措施的有效性可能在预防弱点方面。
- 高的- 经常成功地消除弱点。
- 缓和- 将防止多种形式的弱点，但没有完全覆盖弱点。
- 有限的- 在有限的情况下可能很有用，或者仅适用于这种弱点类型的潜在错误的子集。
- 偶然- 通常无效，只会偶然提供保护，而不是以可靠的方式提供保护。
- 深入防御- 不一定会防止弱点，但它可能有助于最大程度地减少利用弱点的攻击者的潜在影响。
|
| 有效性注释 |
如果有用，则可以自由形式的文本描述缓解的有效性。 |
请注意，CWE模式还包括一个策略元素，但CWE团队将填写。它基于CWE开发的缓解策略分类。有关更多信息，请参见XSD中的MatigationStrateGyEnumeration。
常见后果
如果攻击者可以利用这种弱点，则此元素将涵盖发生的典型负面安全影响（或影响）。
| 元素 |
描述 |
| 范围 |
确定违反安全属性（或属性）。可接受的值包括保密，，，，正直，，，，可用性，，，，访问控制，，，，问责制，，，，验证，，，，授权，，，，非替代， 和其他。 |
| 影响 |
描述如果对手成功利用这一弱点，就会产生的技术影响。 |
| 可能性 |
确定相对于其他指定后果的预期特定后果的可能性。例如，可能会利用弱点来实现一定的影响，但很可能会利用它来实现不同的影响。可接受的值是高的，，，，中等的，，，，低的， 和未知。请注意，这些值未正式定义。 |
| 笔记 |
（可选）提供有关结果的其他评论。 |
适用的平台
此元素指定了通常发现这种弱点的编程语言（或语言家族），操作系统，框架，架构，技术和/或产品类。
尽管此元素在CWE模式中定义明确，但对于外部提交，它可能不必要地限制。请参阅适用的Platformstype和相关枚举以获取示例。
示例的例子
该条目应具有一个或多个示范示例。一个有用的示例包含几个不同的元素，如下所述。
警告：在CWE团队审查并接受已提交条目背后的一般概念之前，提交者不一定要付出大量的努力来创建这些示例。
| 元素 |
描述 |
| 介绍性文字 |
描述代码正在尝试执行的操作，可能会提供应查看代码的上下文或设置。 |
| “不好”代码片段 |
提供包含弱点的一个或多个代码段（或算法描述）。假定主要受众是对所使用语言知识渊博的程序员。
- 该代码应具有正确的语法。
- 摘要应仅关注最少的代码，以便读者了解代码正在尝试做什么；因此，例如，可以省略加载通用库的语句。
- 片段不应试图掩盖相关的弱点，因为这些示例对于读者来说很容易理解。
- 在可行的地方，摘要只能有一个弱点，除非例子有意证明链或复合材料。
|
| 解释性文字 |
在合理的情况下，解释性文本应指示错误发生的位置，包括程序员在此过程中可能做出的假设。这可以包括一些有关如何启动攻击的示例。 |
| “好”代码片段 |
显示或解释如何修改“不良”代码段以消除弱点。 |
请注意，这些详细信息不会遵循CWE使用的内部格式。如果接受提交的内容，CWE团队将执行适当的转换为XML。有关更多信息，请参见模式定义中的DixplyativeExamPlestype。
观察到的例子
众所周知，提交应确定表现出弱点的现实世界软件中的多个公开报告的漏洞。
| 元素 |
描述 |
| CVE标识符 |
应当提供可用的 |
| 关联 |
链接到参考。该链接不应需要注册。 |
| 概括 |
简短的句子或短语总结了弱点。摘要不一定必须命名受影响的产品或服务，而是涵盖导致弱点的错误，甚至可能是技术影响。优选地，摘要不应给出实际的供应商或产品名称，也不应成为关联CVE描述的逐字副本。 |
关系
确定应将此弱点分类的母公司CWE。确保这些父母是弱点类型，而不是类别。CWE团队将执行其他分析，以确保存在适当的关系。
如果无法识别出明确的父/子女关系，请确定类似的CWE，和/或包括有关如何缩小差距的建议。
提出关系时，请尝试考虑它们属于层次结构的发展视图（CWE-699），研究观点（CWE-1000）和/或硬件设计视图（CWE – 1194）。
参考
参考文献可以包括一篇或多个学术论文，白皮书，博客文章，幻灯片演示文稿或用URL描述弱点的视频。
- 通常，该参考应在网络上免费提供，而无需注册。
- 在可行的地方，应包括作为参考的弱点的原始公告。
- 参考文献不应公开“商业”或以营销为导向的语调。
- 在可行的地方，不太可能更改的URL应该受到优先选择。
| 元素 |
描述 |
| URL |
可以找到参考的URL。 |
| 标题 |
纸，书等的标题。 |
| 作者 |
参考的作者。 |
成熟CWE条目的示例
以下CWE条目已经成熟且经过精心审查。因此，他们提供了很好的例子来咨询您自己的意见书。
更换管理层
社区的内容建议遵守使用条款受到鼓励和欢迎。提交建议表后，CWE团队将对其进行审查，并确定是否将其摄入语料库。If selected, the CWE team will work with you to make sure it fits both your needs and aligns with the rest of CWE in terms of language, structure, etc. If the CWE team is considering a significant change to a submitter’s entry after its publication, the team will attempt to contact the original submitter to discuss those change requests / modifications before they are released. Modifications that would alter the underlying meaning of the CWE would result in deprecation (and the subsequent creation of a new CWE) enabling the long-term viability of the original CWE.
重要的考虑因素
确保已经进行了以下分析。
- 信息符合CWE/CAPEC使用条款。如果包含在CWE中，则任何提交的信息都将成为公共信息。确保该信息已被适当当局批准公开发布。
- 符合准则。您可以选择要与这些准则保持一致。但是，不遵循这些准则的提交可能需要更长的时间才能集成到CWE中，或者可能会大量修改。通常，CWE团队可以选择剥夺不合格的提交。
- 抽象。考虑提交是否处于CWE中表示的适当抽象水平。到目前为止，准则尚未明确定义，而是熟悉类，基础和变体（来自模式或词汇表，以及审查现有CWE内容）。通常，CWE团队更喜欢在基本级别上提交；但是，您可能只知道在较低的变体水平上存在弱点。
- 范围。确保提交在CWE的范围内。当不确定时，您可以就此事咨询CWE团队。
| 作者 |
CWE团队 |
| 电子邮件 |
cwe@mitre.org |
| 版本 |
2.0 |
| 上一次更改 |
2022年2月14日 |
