in-toto

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

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

如果这是您的项目,请在您的项目页面上显示您的徽章状态!徽章状态如下所示: 项目1523的徽章级别为silver 这里是如何嵌入它:
您可以通过将其嵌入在您的Markdown文件中:
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/1523/badge)](https://bestpractices.coreinfrastructure.org/projects/1523)
或将其嵌入到HTML中来显示您的徽章状态:
<a href="https://bestpractices.coreinfrastructure.org/projects/1523"><img src="https://bestpractices.coreinfrastructure.org/projects/1523/badge"></a>


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



 基本 4/5

  • 识别

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

    in-toto is a framework to protect supply chain integrity.

  • 先决条件


    足够获得徽章!

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

  • 项目监督


    足够获得徽章!

    项目必须具有2个或更多的“公交车因子”。 (需要网址) [bus_factor]
    “公交车系数”(又名“卡车因子”)是指最少数量的项目成员,如果突然离开项目(“被公交车撞了”),项目会由于缺乏具备知识的或有能力的人员而暂停。 卡车因子 工具可以对GitHub上的项目进行估计。有关详细信息,请参阅Cosentino等人的评估Git存储库的卡车因子

    Three people mentioned in the MAINTAINERS.txt file have full ownership access to the in-toto GitHub Organization: https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt https://github.com/orgs/in-toto/people



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

    该项目必须至少有两个不相关的重要贡献者。 (需要网址) [contributors_unassociated]
    如果同一组织(作为雇员或承包商)支付工作费用,并且组织将从项目的结果中受益,则贡献者是相关联的。如果通过其他组织得到财务补助(例如,源自政府或非政府组织,支付给不同组织的科学补助金不会导致捐助者关联),不视为来自同一组织。重要贡献者定义为过去一年对项目做出了不平凡的贡献。一个重要贡献者的良好指标的例子是:编写至少1,000行代码,贡献50个提交或至少提交20页的文档。

  • 其他


    足够获得徽章!

    项目必须在每个源文件中包含许可证声明。这可以通过在每个文件开头附近的注释中加入以下内容来实现: SPDX-License-Identifier: [SPDX license expression for project][license_per_file]
    这可以通过在自然语言中包含许可证标识来完成。该项目还可以包括完整许可证文本,或者指向许可证文本的稳定URL。请注意,license_location条款要求项目许可证在标准位置。有关SPDX许可证表达式的更多信息,请参阅SPDX教程。请注意与 copyright_per_file 的关系,其内容通常在许可证信息之前。

    Each source file contains the following SPDX conformant license statement in a comment near the beginning of the file:

    # SPDX-License-Identifier: Apache-2.0


 变更控制 4/4

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


    足够获得徽章!

    必须使用通用的分布式版本控制软件(例如,git,mercurial)作为项目的源代码存储库。 [repo_distributed]
    Git不是必须,项目在合适场景可以使用集中版本控制软件(如subversion)。

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



    足够获得徽章!

    该项目必须清楚地识别新的或临时贡献者可以执行的小型任务。 (需要网址) [small_tasks]
    此标识通常通过在项目使用的一个或多个标签的问题跟踪器中标记所选问题来完成,例如 up- for-grabs 仅限第一时间,“小修复”,微任务或IdealFirstBug。这些新任务不需要添加功能;他们可以改进文档,添加测试用例或其他有助于项目的内容,并帮助贡献者更了解项目。

    Issue tracker has an "Up for grabs" label, identifying such tasks. https://github.com/in-toto/in-toto/issues?q=is%3Aissue+is%3Aopen+label%3A%22Up+for+grabs%22



    足够获得徽章!

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

    All developers who can merge to the main branch, "develop", have 2FA enabled on their GitHub accounts.



    足够获得徽章!

    项目的双因素身份认证(2FA)应该使用加密机制来防止仿冒。基于短消息服务(SMS)的2FA本身不符合此标准,因为它不被加密。 [secure_2FA]
    满足此条款的2FA机制将是一种基于时间的一次性密码(TOTP)应用程序,可自动生成在一段时间后更改的验证码。请注意, GitHub支持TOTP

    All developers who can merge to the main branch, "develop", have 2FA enabled on their GitHub accounts, using Time-based One-Time Password (TOTP).


 质量 7/7

 安全 5/5

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

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

    足够获得徽章!

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

    The software produced by the project does not employ network protocols.



    足够获得徽章!

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

    The software produced by the project does not use TLS.


  • 安全交付防御中间人(MITM)的攻击


    足够获得徽章!

    项目网站,存储库(如果可通过网络访问)和下载站点(如果单独)必须包括具有非允许值的密钥加固头。 (需要网址) [hardened_site]
    请注意,GitHub是已知满足的。 https://securityheaders.io/ 等网站可以快速查看。主要头加固包含:内容安全策略(CSP),HTTP严格传输安全性(HSTS),X-Content-Type-Options(“nosniff”),X-Frame-Options和X-XSS-Protection。

    All listed security headers are used on the project website and source code repository website: https://securityheaders.com/?q=https%3A%2F%2Fin-toto.io https://securityheaders.com/?q=https%3A%2F%2Fgithub.com%2Fin-toto%2Fin-toto


  • 其他安全问题


    足够获得徽章!

    该项目必须在过去5年内进行安全审查。此审查必须考虑安全需求和安全边界。 [security_review]
    这可以由项目成员完成和/或独立评估。此评估可能由静态和动态分析工具支持,但还必须进行人工审查,以确定工具无法检测到的问题(特别是设计问题)。

    The CNCF sig-security performed an assessment of the project. https://github.com/cncf/sig-security/tree/master/assessments/projects/in-toto



    足够获得徽章!

    加固机制必须用于项目生产的软件,以便软件缺陷不太可能导致安全漏洞。 (需要网址) [hardening]
    加固机制可能包括HTTP头,如内容安全策略(CSP),用于减轻攻击的编译器标志(如-fstack-protector)或用以消除未定义行为的编译器标志。对于此条款的目的,最小权限不被认为是一种加固机制(最少权限是重要的,但是另有条款)。

    The software produced by the project uses hardening mechanisms such as input validation (see above) and the Python-style EAFP error handling paradigm for library functions, translated to POSIX-style exit codes for command lines tools.

    https://docs.python.org/3/glossary.html#term-eafp


 分析 2/2

  • 动态代码分析


    足够获得徽章!

    必须在发布之前,至少将一个动态分析工具应用于软件任何候选发布的主要生产版本。 [dynamic_analysis]
    动态分析工具通过执行特定输入来检查软件。例如,项目可以使用模糊工具(例如, American Fuzzy Lop )或Web应用扫描程序(例如, OWASP ZAP w3af )。在某些情况下, OSS-Fuzz 项目可以对您的项目应用模糊测试。为满足此条款,动态分析工具需要以某种方式改变输入,以寻找各种问题,或者将其作为一个具有至少80%分支覆盖率的自动测试套件。 动态分析维基百科页面 OWASP的fuzzing页面 识别一些动态分析工具。分析工具可能专注于寻找安全漏洞,但这不是必需的。

    Dynamic analysis is automatically applied to every push to the repository:

    https://github.com/in-toto/in-toto/blob/v0.3.0/.travis.yml#L27 https://github.com/in-toto/in-toto/blob/v0.3.0/tox.ini



    足够获得徽章!

    项目应该在其生成的软件中包含许多运行时断言,并在动态分析期间检查这些断言。 [dynamic_analysis_enable_assertions]
    这个标准并不建议使生产过程中的断言;这完全取决于项目及其用户的决定。该标准的重点是部署之前的动态分析过程中改善故障检测。在生产使用中启用断言与在动态分析(例如测试)期间启用断言完全不同。在某些情况下,在生产中使用断言是极其不明智的(尤其是在高完整性组件中)。存在许多反对在生产环境中启用断言的论点,例如,库不应使调用程序崩溃,它们的存在可能会导致应用商店拒绝,和/或在生产环境中激活断言可能会暴露诸如私钥之类的私有数据。请注意,在许多Linux发行版中都未定义NDEBUG ,因此C / C ++缺省情况下,assert()将在这些环境中启用生产。对于那些环境中的生产,使用不同的断言机制或定义NDEBUG可能很重要。

    Run-time assertions are checked in the dynamic analysis test code using Python unittest's assert methods.

    https://github.com/in-toto/in-toto/tree/develop/tests https://docs.python.org/3.7/library/unittest.html#assert-methods



此数据在知识共享署名3.0或更高版本许可证(CC-BY-3.0 +) 下可用。所有内容都可以自由分享和演绎,但必须给予适当的署名。请署名为Lukas Puehringer和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者: Lukas Puehringer.
最后更新于 2018-01-03 16:15:50 UTC, 最后更新于 2021-11-03 16:11:05 UTC。 最后在 2018-01-05 21:31:54 UTC 获得通过徽章。

后退