vFeed - The Correlated Vulnerability And Threat Database

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法；如果规范或假设是错误的，即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是，遵循最佳做法可以帮助改善项目的成果。例如，一些做法可以在发布之前进行多人评估，这可以帮助您找到其他难以找到的技术漏洞，并帮助建立信任，并希望不同公司的开发人员之间进行重复的交互。要获得徽章，必须满足所有“必须”和“禁止”的条款，满足所有“应该”条款或有合适的理由，和所有“建议”条款必须满足或未满足（至少希望考虑）。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目，请在项目页面上显示您的基准徽章状态！基准徽章状态如下所示： 项目115的基准徽章等级为in_progress 以下是如何嵌入基准徽章：
您可以通过将其嵌入到Markdown文件中来显示您的基准徽章状态：
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/115/baseline)](https://www.bestpractices.dev/projects/115)
或者将其嵌入到HTML中：
<a href="https://www.bestpractices.dev/projects/115"><img src="https://www.bestpractices.dev/projects/115/baseline"></a>


这些是基准等级3的标准。

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本

  • 识别

    请注意，其他项目可能使用相同的名称。

    vFeed Framework is a CVE, CWE and OVAL Compatible naming scheme concept that provides extra structured detailed third-party references and technical characteristics for a CVE entry through an extensible XML/JSON schema. It also improves the reliability of CVEs by providing a flexible and comprehensive vocabulary for describing the relationship with other standards and security references.

    vFeed utilizes XML-based / JSON-based format outputs to describe in detail vulnerabilities. They can be leveraged as input by security researchers, practitioners and tools as part of their vulnerability description. In fact, the standard syntax is easy to interpret by humans and systems.

    The associated vFeed.db (The Correlated Vulnerability and Threat Database) is a detective and preventive security information repository used for gathering vulnerability and mitigation data from scattered internet sources into an unified database.

 控制 0/20 ●

  • 控制


    未知的所需信息，不足以用于徽章。

    当在CI/CD管道中为作业分配权限时，源代码或配置必须仅分配相应活动所需的最低权限。 [OSPS-AC-04.02]
    配置项目的CI/CD流水线，默认为用户和服务分配最低可用权限，仅在特定任务需要时才提升权限。在某些版本控制系统中，这可以在组织或代码仓库级别实现。如果不行，请在流水线的顶层设置权限。

    未知的所需信息，不足以用于徽章。

    当创建正式发布版本时，该发布版本中的所有资产必须明确关联到发布标识符或资产的其他唯一标识符。 [OSPS-BR-02.02]
    为项目生成的每个软件资产分配唯一的版本标识符，遵循一致的命名约定或编号方案。示例包括SemVer、CalVer或git提交ID。

    未知的所需信息，不足以用于徽章。

    项目必须定义管理项目使用的秘密和凭证的策略。该策略应包括存储、访问和轮换秘密和凭证的指南。 [OSPS-BR-07.02]
    记录项目内如何管理和使用秘密和凭证。这应包括如何存储秘密（例如，使用秘密管理工具）、如何控制访问以及如何轮换或更新秘密的详细信息。确保敏感信息不会硬编码在源代码中或存储在版本控制系统中。

    未知的所需信息，不足以用于徽章。

    当项目已发布版本时，项目文档必须包含验证发布资产完整性和真实性的说明。 [OSPS-DO-03.01]
    项目中的说明应包含所使用技术、要运行的命令以及预期输出的信息。如果可能，避免将此文档存储在构建和发布流水线的相同位置，以避免单一漏洞同时危及软件和验证软件完整性的文档。

    未知的所需信息，不足以用于徽章。

    当项目已发布版本时，项目文档必须包含验证软件发布作者的预期身份的说明。 [OSPS-DO-03.02]
    预期身份可能采用用于签名的密钥ID、来自sigstore证书的颁发者和身份或其他类似形式。如果可能，避免将此文档存储在构建和发布流水线的相同位置，以避免单一漏洞同时危及软件和验证软件完整性的文档。

    未知的所需信息，不足以用于徽章。

    当项目已发布版本时，项目文档必须包含关于每个发布版本支持范围和持续时间的描述性声明。 [OSPS-DO-04.01]
    为了传达项目发布的软件资产的支持范围和持续时间，项目应有SUPPORT.md文件、SECURITY.md中的"支持"部分或其他文档，说明支持生命周期，包括每个发布版本的预期支持持续时间、提供的支持类型（例如，错误修复、安全更新）以及获取支持的任何相关策略或程序。

    未知的所需信息，不足以用于徽章。

    当项目已发布版本时，项目文档必须提供描述性声明说明何时发布版本或版本将不再接收安全更新。 [OSPS-DO-05.01]
    为了传达安全修复的支持范围和持续时间，项目应有SUPPORT.md或其他文档，说明项目的安全更新策略。

    未知的所需信息，不足以用于徽章。

    在活跃期间，项目文档必须有一个策略，要求在授予对敏感资源的提升权限之前审查代码协作者。 [OSPS-GV-04.01]
    在项目文档中发布可执行的策略，要求在授予对敏感资源（例如合并批准或访问秘密）的提升权限之前审查和批准代码协作者。建议审查包括建立可证明的身份血统，例如确认贡献者与已知可信组织的关联。

    未知的所需信息，不足以用于徽章。

    当项目已发布版本时，所有编译的已发布软件资产必须附带软件物料清单。 [OSPS-QA-02.02]
    建议在构建时使用经过准确性审查的工具自动生成SBOM。这使用户能够以标准化的方式将此数据与其环境中的其他项目一起提取。

    未知的所需信息，不足以用于徽章。

    当项目已发布包含多个源代码仓库的版本时，所有子项目必须执行与主代码库一样严格或更严格的安全要求。 [OSPS-QA-04.02]
    项目生成并编译到发布版本中的任何其他子项目代码仓库必须根据相应代码库的状态和意图执行安全要求。除了遵循相应的OSPS基线要求外，这还可能包括要求进行安全审查、确保其没有漏洞以及确保其没有已知的安全问题。

    未知的所需信息，不足以用于徽章。

    在活跃期间，项目文档必须清楚地记录测试何时以及如何运行。 [OSPS-QA-06.02]
    在贡献文档中添加一个章节，说明如何在本地运行测试以及如何在CI/CD管道中运行测试。文档应说明测试的测试内容以及如何解释测试结果。

    未知的所需信息，不足以用于徽章。

    在活跃期间，项目的文档必须包含一项政策，即对项目生成的软件的所有重大更改都应该在自动化测试套件中添加或更新功能测试。 [OSPS-QA-06.03]
    在贡献文档中添加一个章节，说明添加或更新测试的政策。该政策应说明什么是重大更改以及应该添加或更新哪些测试。

    未知的所需信息，不足以用于徽章。

    当向主分支提交时，项目的版本控制系统必须在合并之前要求至少一名非作者人工审批更改。 [OSPS-QA-07.01]
    配置项目的版本控制系统，要求在合并到发布分支或主分支之前至少有一名非作者人工审批更改。这可以通过要求拉取请求在合并之前必须由至少另一位协作者审查和批准来实现。

    未知的所需信息，不足以用于徽章。

    当项目发布版本时，项目必须执行威胁建模和攻击面分析，以理解和防护针对系统内关键代码路径、函数和交互的攻击。 [OSPS-SA-03.02]
    威胁建模是一项活动，其中项目查看代码库、相关流程和基础设施、接口、关键组件，并"像黑客一样思考"，集思广益探讨系统可能如何被破坏或受到损害。每个识别的威胁都会被列出，以便项目可以考虑如何主动避免或关闭可能出现的任何漏洞/脆弱点。确保为新功能或破坏性更改更新此分析。

    未知的所需信息，不足以用于徽章。

    在活跃期间，软件组件中不影响项目的任何漏洞必须在VEX文档中予以说明，并以不可利用性细节补充漏洞报告。 [OSPS-VM-04.02]
    建立VEX供给源，传达已知漏洞的可利用性状态，包括评估细节或任何阻止易受攻击代码执行的缓解措施。

    未知的所需信息，不足以用于徽章。

    在活跃期间，项目文档必须包含一项政策，定义与漏洞和许可证相关的SCA发现的修复阈值。 [OSPS-VM-05.01]
    在项目中记录一项政策，定义与漏洞和许可证相关的SCA发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

    未知的所需信息，不足以用于徽章。

    在活跃期间，项目文档必须包含一项政策，在任何发布之前解决SCA违规问题。 [OSPS-VM-05.02]
    在项目中记录一项政策，在任何发布之前解决适用的软件组成分析结果，并添加状态检查以验证在发布之前符合该政策。

    未知的所需信息，不足以用于徽章。

    在活跃期间，对项目代码库的所有更改必须根据记录的恶意依赖项和依赖项中已知漏洞的政策自动评估，然后在违规的情况下阻止，除非声明并抑制为不可利用。 [OSPS-VM-05.03]
    在项目的版本控制系统中创建一个状态检查，对代码库的所有更改运行软件组成分析工具。要求状态检查在更改可以合并之前必须通过。

    未知的所需信息，不足以用于徽章。

    在活跃期间，项目文档必须包含一项政策，定义SAST发现的修复阈值。 [OSPS-VM-06.01]
    在项目中记录一项政策，定义静态应用程序安全测试（SAST）发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

    未知的所需信息，不足以用于徽章。

    在活跃期间，对项目代码库的所有更改必须根据记录的安全弱点政策自动评估，并在违规的情况下阻止，除非声明并抑制为不可利用。 [OSPS-VM-06.02]
    在项目的版本控制系统中创建一个状态检查，对代码库的所有更改运行静态应用程序安全测试（SAST）工具。要求状态检查在更改可以合并之前必须通过。


此数据在知识共享署名3.0版本许可证（CC-BY-3.0）下可用，并依据核心基础设施计划 使用条款。所有数据都可以自由分享和演绎，但必须给予适当的署名。请署名NJ. Ouchn和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： NJ. Ouchn.
最后更新于 2016-05-05 09:05:41 UTC, 最后更新于 2016-05-19 15:28:55 UTC。