BadgeApp

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

如果这是您的项目，请在您的项目页面上显示您的徽章状态！徽章状态如下所示： 项目1的徽章级别为gold 这里是如何嵌入它：

这些是黄金级别条款。您还可以查看通过或白银级别条款。

        

 基本 5/5 ●

  • 识别

    BadgeApp is the web application that allows developers to provide information about their project and (hopefully) get an Open Source Security Foundation (OpenSSF) Best Practices badge. This project was originally known as the Core Infrastructure Initiative (CII) best practices badge project.

    The Open Source Security Foundation (OpenSSF) is managed by The Linux Foundation. The OpenSSF Best Practices badge online application (aka the BadgeApp) enables developers to quickly determine whether they are following best practices and to receive a badge they can display on GitHub and other locations. The application and its criteria are an open source project to which developers can contribute.

    You can see the program running, and use it to try to get a badge, by visiting: https://bestpractices.coreinfrastructure.org/

    The BadgeApp is written in Ruby on Rails and Javascript.

    See the development site on GitHub for more about how we secure this application.

    Note that the BadgeApp gets its own badge!

  • 先决条件


    足够获得徽章！

    该项目必须拥有银级徽章。 [achieve_silver]

  • 项目监督


    足够获得徽章！

    项目必须具有2个或更多的“公交车因子”。 (需要网址) [bus_factor]

    David A. Wheeler, Jason Dossett, and Dan Kohn are all very familiar with the software and could easily continue its maintenance if necessary. Many other people have contributed per CREDITS and several of them could also probably maintain it if absolutely necessary. See GitHub contributors statistics for the latest statistics on contributors.


    足够获得徽章！

    该项目必须至少有两个不相关的重要贡献者。 (需要网址) [contributors_unassociated]

    There are at least 22 contributors, and at least three significant contributors today: David A. Wheeler (IDA), Jason Dossett (IDA), and Dan Kohn (Linux Foundation). For this work, IDA works for the Core Infrastructure Initiative (CII), which is a project of the Linux Foundation (LF). However, the LF is itself a nonprofit mutual benefit corporation (specifically a Section 501(c)(6)). As a nonprofit mutual benefit corporation, the LF is directed by other organizations which actually provide funding to do this work, and thus the LF and CII can be viewed as "pass through" organizations as described in this criterion.


  • 其他


    足够获得徽章！

    项目必须在每个源文件中包含许可证声明。这可以通过在每个文件开头附近的注释中加入以下内容来实现： SPDX-License-Identifier: [SPDX license expression for project]。 [license_per_file]

    Each source file has a copyright statement in its header (MIT). See CONTRIBUTING.md for the instructions for Ruby source files (nearly all source files are in Ruby).


  • 公开的版本控制的源代码存储库


    足够获得徽章！

    必须使用通用的分布式版本控制软件（例如，git，mercurial）作为项目的源代码存储库。 [repo_distributed]

    Uses git. Repository on GitHub, which uses git. git is distributed.


    足够获得徽章！

    该项目必须清楚地识别新的或临时贡献者可以执行的小型任务。 (需要网址) [small_tasks]

    We use the "up-for-grabs" tag. This is noted on the front page of the repo.


    足够获得徽章！

    项目必须要求开发人员使用双因素身份验证（2FA）来更改中央存储库或访问敏感数据（如私密漏洞报告）。这种2FA机制可以使用没有密码学机制的方案，如SMS（短消息），尽管不推荐。 [require_2FA]

    The Core Infrastructure Initiative (CII) requires two-factor authentication for all organization members and outside collaborators as described in Requiring two-factor authentication in your organization.


    足够获得徽章！

    项目的双因素身份认证（2FA）应该使用加密机制来防止仿冒。基于短消息服务（SMS）的2FA本身不符合此标准，因为它不被加密。 [secure_2FA]

    Project governance specifically documents that SMS is not acceptable; see governance.md.


  • 编码标准


    足够获得徽章！

    该项目必须记录其代码检视需求，包括代码检视是如何进行的，必须检查的内容以及哪些是可接纳的内容。 (需要网址) [code_review_standards]

    The file CONTRIBUTING.md describes the code review requirements. E.G., changes to the code built on Rails must follow the Rails community style guide. The continuous integration tasks run a large number of checks, e.g., all Ruby code must go through Rubocop, and all JavaScript code must go through ESLint (with the given conditions). We absolutely require that the Ruby code have at least 90% statement coverage, but we typically don't accept statement coverage less than 100%.


    足够获得徽章！

    该项目必须至少有50％的修改（作者之外的人提出的）在发布之前审查，以确定是否是一个有价值的修改，并且没有已知的问题，会反对其包含 [two_person_review]

    We have a policy in CONTRIBUTING.md that modifications other than low-risk modifications be reviewed by someone else, and a stated goal of having at least 50% of all proposed modifications to be reviewed.


  • 可工作的构建系统


    足够获得徽章！

    该项目必须具有可重复构建。如果没有发生构建（例如，直接使用源代码而不是编译的脚本语言），请选择“不适用”（N/A）。 (需要网址) [build_reproducible]

    The code is written in Ruby and Javascript, which are not delivered as compiled executables.


  • 自动测试套件


    足够获得徽章！

    测试套件必须以该语言的标准方式进行调用。 (需要网址) [test_invocation]

    Yes. "rake test" invokes the automated test suite. The default "rake" command includes "rake test". This is documented in CONTRIBUTING.md.


    足够获得徽章！

    该项目必须实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 (需要网址) [test_continuous_integration]

    Code is frequently integrated back into GitHub; CircleCI and several other tools are then run on the result to determine if there's a problem. If a problem is found, the tools provide feedback via GitHub. For more information, see the BadgeApp's status on CircleCI.


    足够获得徽章！

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少90％语句覆盖率。 [test_statement_coverage90]

    As of this writing, we have 100% statement coverage, see Codecov.io.


    足够获得徽章！

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少80％分支覆盖率。 [test_branch_coverage80]

    There are no top-to-bottom FLOSS tools available in Ruby which can measure branch coverage. Ruby version 2.5 was the first version that enabled capturing branch coverage, and it was only released on 2017-12-25. Other tools on top of Ruby need to be modified so that they can use this information, e.g., simplecov issue 412 proposed adding branch coverage support to simplecov.


  • 使用基础的良好加密实践

    请注意，某些软件不需要使用加密机制。

    足够获得徽章！

    项目生成的软件必须支持所有网络通信的安全协议，如SSHv2或更高版本，TLS1.2或更高版本（HTTPS），IPsec，SFTP和SNMPv3。默认情况下，FTP，HTTP，Telnet，SSLv3或更早版本以及SSHv1等不安全协议必须被禁用，只有在用户专门配置时才启用。如果项目生成的软件不支持网络通信，请选择“不适用”（N/A）。 [crypto_used_network]

    https://github.com/linuxfoundation/cii-best-practices-badge


    足够获得徽章！

    由项目生成的软件必须，如果支持或使用TLS，至少支持TLS版本1.2。请注意，TLS的前身称为SSL。如果软件不使用TLS，请选择“不适用”（N/A）。 [crypto_tls12]

    Github uses TLS 1.2, see https://github.com/linuxfoundation/cii-best-practices-badge.


  • 安全交付防御中间人（MITM）的攻击


    足够获得徽章！

    项目网站，存储库（如果可通过网络访问）和下载站点（如果单独）必须包括具有非允许值的密钥加固头。 (需要网址) [hardened_site]

    We use GitHub, and securityheaders.io verifies that our sites meet this criterion.


  • 其他安全问题


    足够获得徽章！

    该项目必须在过去5年内进行安全审查。此审查必须考虑安全需求和安全边界。 [security_review]

    We have performed a self-assessment of our security, and it is documented in security.md. This considered the security requirements and security boundary, and examined the high-level architecture. We used static & dynamic tools, as well as human review (especially of the major design components). This was not an independent evaluation, but the criterion doesn't require that.


    足够获得徽章！

    加固机制必须用于项目生产的软件，以便软件缺陷不太可能导致安全漏洞。 (需要网址) [hardening]

    We use various HTTP headers for hardening, including a rigorous Content Security Policy (CSP) setting. For more information, see security.md which discusses the hardening mechanisms.


  • 动态代码分析


    足够获得徽章！

    必须在发布之前，至少将一个动态分析工具应用于软件任何候选发布的主要生产版本。 [dynamic_analysis]

    Analyzed with OWASP ZAP by Emily Ratliff


    勉强够获得徽章。

    项目应该在其生成的软件中包含许多运行时断言，并在动态分析期间检查这些断言。 [dynamic_analysis_enable_assertions]

    Instead of embedding run-time assertions, there are many external tests with assertions that are checked during automated testing.



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit David A. Wheeler and the OpenSSF Best Practices badge contributors.

项目徽章条目拥有者： David A. Wheeler.
最后更新于 2015-10-23 22:02:10 UTC, 最后更新于 2025-01-03 20:27:50 UTC。 最后在2023-09-19 06:10:11 UTC丢失通过徽章。 最后在 2023-09-19 06:10:30 UTC 获得通过徽章。

后退