gitlabcis

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

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

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

        

 基本 13/13 ●

  • 识别

    A Python-based CLI tool designed to scan GitLab projects for compliance against the CIS GitLab Benchmark.

    用什么编程语言实现项目？

  • 基本项目网站内容


    足够获得徽章！

    项目网站必须简明扼要地描述软件的作用（它解决了什么问题？）。 [description_good]

    An overview of what the tool is, and what it attempts to solve, can be found in the root directory "README.md" file. - https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/#overview


    足够获得徽章！

    项目网站必须提供有关如何获取和提供反馈（错误报告或增强功能）以及如何贡献的信息。 [interact]

    The README.md in the root (also displayed on pypi.org) points to contributing and security docs which focus on: how to contribute & how to raise bugs - https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/blob/main/docs/CONTRIBUTING.md - https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/blob/main/docs/SECURITY.md


    足够获得徽章！

    关于如何贡献的信息必须解释贡献流程（例如，是否使用拉请求？） (需要网址) [contribution]

    This doc shows how to setup a local dev environment in order to contribute to the project. It points out pre-commit, commit-msg enforcements and more.


    足够获得徽章！

    关于如何贡献的信息应包括对可接受的贡献的要求（例如，引用任何所需的编码标准）。 (需要网址) [contribution_requirements]

    This doc shows how to setup a local dev environment in order to contribute to the project. It points out pre-commit, commit-msg enforcements and more.


  • FLOSS许可证

    项目使用什么许可证发布？


    足够获得徽章！

    项目生产的软件必须作为FLOSS发布。 [floss_license]

    https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/blob/main/LICENSE The MIT license is approved by the Open Source Initiative (OSI).


    足够获得徽章！

    建议由项目生成的软件的任何必需的许可证是由开放源码促进会（OSI）批准的许可证（英文）。 [floss_license_osi]

    The MIT license is approved by the Open Source Initiative (OSI).


    足够获得徽章！

    项目必须将其许可证在其源代码存储库中的标准位置发布。 (需要网址) [license_location]

    https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/blob/main/LICENSE


  • 文档


    足够获得徽章！

    项目必须为项目生成的软件提供基本文档。 [documentation_basics]

    https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/tree/main/docs


    足够获得徽章！

    项目必须提供描述项目生成的软件的外部接口（输入和输出）的参考文档。 [documentation_interface]

  • 其他


    足够获得徽章！

    项目网站（网站，存储库和下载URL）必须使用TLS支持HTTPS。 [sites_https]

    足够获得徽章！

    该项目必须有一个或多个讨论机制（包括建议的更改和问题），可搜索，允许通过URL访问消息和主题，使新人能够参与一些讨论，并且不需要客户端安装专有软件。 [discussion]

    https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/issues


    足够获得徽章！

    项目应该提供英文文档，并能够接受英文的代码的错误报告和评论。 [english]

    https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/blob/main/docs/SECURITY.md


    足够获得徽章！

    必须维护该项目。 [maintained]

    There are 3 maintainers on the project, also automation for dependency bumping. - https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/tree/main/docs#gitlabcis-authors



（高级）哪些用户还有额外权限编辑此徽章条目？目前：[]



  • 安全开发知识


    足够获得徽章！

    该项目必须至少有一个主要开发人员知道如何设计安全软件。 [know_secure_design]

    足够获得徽章！

    该项目的主要开发人员中，至少有一个必须知道导致这类型软件漏洞的常见错误类型，以及至少有一种方法来对付或缓解这些漏洞。 [know_common_errors]

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

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

    足够获得徽章！

    项目生成的软件默认情况下，只能使用由专家公开发布和审查的加密协议和算法（如果使用加密协议和算法）。 [crypto_published]

    足够获得徽章！

    如果项目生成的软件是应用程序或库，其主要目的不是实现加密，那么它应该只调用专门设计实现加密功能的软件，而不应该重新实现自己的。 [crypto_call]

    足够获得徽章！

    项目所产生的软件中，所有依赖于密码学的功能必须使用FLOSS实现。 [crypto_floss]

    足够获得徽章！

    项目生成的软件中的安全机制使用的默认密钥长度必须至少达到2030年（如2012年所述）的NIST最低要求。必须提供配置，以使较小的密钥长度被完全禁用。 [crypto_keylength]

    足够获得徽章！

    项目产生的软件中的默认安全机制不得取决于已被破解的密码算法（例如，MD4，MD5，单DES，RC4，Dual_EC_DRBG）或使用不适合上下文的密码模式（例如，ECB模式几乎不适当，因为它揭示了密文中相同的块，如 ECB企鹅所示。CTR模式通常是不合适的，因为如果重复输入状态，则它不执行认证并导致重复）。 [crypto_working]

    足够获得徽章！

    由项目产生的软件中的默认安全机制不应该依赖于具有已知严重弱点的加密算法或模式（例如，SHA-1密码散列算法或SSH中的CBC模式）。 [crypto_weaknesses]

    足够获得徽章！

    项目产生的软件中的安全机制应该​​对密钥协商协议实施完美的前向保密（PFS），如果长期密钥集合中的一个长期密钥在将来泄露，也不能破坏从一组长期密钥导出的会话密钥。 [crypto_pfs]

    足够获得徽章！

    如果项目产生的软件存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法（例如，PBKDF2，Bcrypt或Scrypt）将密码存储为每用户盐值不同的迭代散列 。 [crypto_password_storage]

    足够获得徽章！

    由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数，并且不得使用密码学不安全的生成器。 [crypto_random]

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


    足够获得徽章！

    该项目必须使用一种针对MITM攻击的传递机制。使用https或ssh + scp是可以接受的。 [delivery_mitm]

    We sign our builds: https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/blob/main/.gitlab/.gitlab-ci.yml#L119 they can be hash verified.

    A user can download via SSH/HTTPS from Gitlab.com or pypi.org


    足够获得徽章！

    不得通过http协议获取加密散列（例如，sha1sum）并直接使用，而不检查密码学签名。 [delivery_unsigned]

  • 修正公开的漏洞


    足够获得徽章！

    被公开了超过60天的中等或更高严重程度的漏洞，必须被修复。 [vulnerabilities_fixed_60_days]

    足够获得徽章！

    项目在得到报告后应该迅速修复所有致命漏洞。 [vulnerabilities_critical_fixed]

  • 其他安全问题


    足够获得徽章！

    公共存储库不得泄漏旨在限制公众访问的有效私人凭证（例如，工作密码或私钥）。 [no_leaked_credentials]

    We run secret scanning in the GitLab pipeline.


  • 静态代码分析


    足够获得徽章！

    如果至少有一个FLOSS工具以所选择的语言实现此条款，则至少需要将一个静态代码分析工具应用于软件发布之前任何提议的主要生成版本。 [static_analysis]

    足够获得徽章！

    建议至少有一个用于static_analysis标准的静态分析工具包括在分析语言或环境中查找常见漏洞的规则或方法。 [static_analysis_common_vulnerabilities]

    足够获得徽章！

    使用静态代码分析发现的所有中，高严重性可利用漏洞必须在确认后及时修复。 [static_analysis_fixed]

    During pre-commit, MR phase and merge on main we identify any security vulns.


    足够获得徽章！

    建议每次提交或至少每天执行静态源代码分析。 [static_analysis_often]

    CI Pipeline SAST scan on each commit: - https://gitlab.com/gitlab-org/govern/compliance/engineering/cis/gitlabcis/-/blob/main/.gitlab/.gitlab-ci.yml#L20


  • 动态代码分析


    勉强够获得徽章。

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

    We don't run DAST scans.


    勉强够获得徽章。

    建议如果项目生成的软件包含使用内存不安全语言编写的软件（例如C或C++），则至少有一个动态工具（例如，fuzzer或web应用扫描程序）与检测缓冲区覆盖等内存安全问题的机制例行应用。如果该项目生成的软件没有以内存不安全语言编写，请选择“不适用”（N / A）。 [dynamic_analysis_unsafe]

    We don't run DAST scans.


    勉强够获得徽章。

    建议由项目生成的软件包括许多运行时断言，在动态分析期间检查。 [dynamic_analysis_enable_assertions]

    We don't run DAST scans.


    足够获得徽章！

    通过动态代码分析发现的所有严重性为中，高的可利用漏洞必须在确认后及时修复。 [dynamic_analysis_fixed]

    We don't run DAST scans.



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 Neil McDonald and the OpenSSF Best Practices badge contributors.

项目徽章条目拥有者： Neil McDonald.
最后更新于 2024-11-21 21:39:49 UTC, 最后更新于 2024-11-21 22:45:43 UTC。 最后在 2024-11-21 22:45:43 UTC 获得通过徽章。

后退