Guardian

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

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

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

        

 基本 13/13 ●

  • 识别

    The Guardian is an innovative open-source platform that streamlines the creation, management, and verification of digital environmental assets. It leverages a customizable Policy Workflow Engine and Web3 technology to ensure transparent and fraud-proof operations, making it a key tool for transforming sustainability practices and carbon markets.

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

  • 基本项目网站内容


    足够获得徽章！

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

    The landing README page in github https://github.com/hashgraph/guardian/blob/main/README.md of the project describes the objective and philosophy of the project and contains various links including the official published documentation https://docs.hedera.com/guardian


    足够获得徽章！

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

    The https://github.com/hashgraph/guardian/blob/main/CONTRIBUTING.md document describes the process and requirements for contribution to the project.


    足够获得徽章！

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

    The https://github.com/hashgraph/guardian/blob/main/CONTRIBUTING.md file describes the contribution process for bug reports, enhancement requests and code contributions.


    足够获得徽章！

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

    The https://github.com/hashgraph/guardian/blob/main/CONTRIBUTING.md file specifies requirements to PRs from external contributors such as code license, readiness, presence of tests etc.


  • FLOSS许可证

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


    足够获得徽章！

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

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).


    足够获得徽章！

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

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).


    足够获得徽章！

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

    Non-trivial license location file in repository: https://github.com/hashgraph/guardian/blob/main/LICENSE.


  • 文档


    足够获得徽章！

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

    Some documentation basics file contents found.


    足够获得徽章！

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

    Reference documentation is provided https://docs.hedera.com/guardian, this URL is included in the README.


  • 其他


    足够获得徽章！

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

    Given only https: URLs.


    足够获得徽章！

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

    GitHub supports discussions on issues and pull requests.


    足够获得徽章！

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

    The documentation is in English https://docs.hedera.com/guardian, so are the bug reports and issues (and their corresponding templates) https://github.com/hashgraph/guardian/issues.


    足够获得徽章！

    必须维护该项目。 [maintained]


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



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


    足够获得徽章！

    该项目必须有一个版本控制的源代码存储库。它必须是公开可读的并可通过URL访问。 [repo_public]

    Repository on GitHub, which provides public git repositories with URLs.


    足够获得徽章！

    项目的源代码存储库必须跟踪所做的更改，谁进行了更改，何时进行了更改。 [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


    足够获得徽章！

    为了实现协作检视，项目的源代码存储库必须包括临时版本，以便检视版本之间的变化；它不得仅包括最终版本。 [repo_interim]

    The interim version of the release is created in the develop branches, tested and discussed there and then merged into main for release. https://github.com/hashgraph/guardian/tree/develop


    足够获得徽章！

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

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


  • 唯一版本编号


    足够获得徽章！

    项目生成的用于每个用户使用的版本必须具有唯一版本标识符。 [version_unique]

    Guardian uses semantic version numbering scheme, see here: https://github.com/hashgraph/guardian/releases.


    足够获得徽章！

    建议使用语义版本控制（SemVer）格式进行发布。 [version_semver]

    足够获得徽章！

    建议项目识别其版本控制系统中的每个版本。例如，建议使用git的项目，使用git标签识别每个版本。 [version_tags]

    Each release is tagged and versioned - see here: https://github.com/hashgraph/guardian/releases.


  • 发行说明


    足够获得徽章！

    该项目必须在每个版本中提供发布说明，这是该版本中主要变化的可读的摘要，以帮助用户确定是否应升级，升级影响将如何。发行说明不能是版本控制日志的原始输出（例如，“git log”命令结果不是发行说明）。其产出不适用于多个地点的项目（如单个网站或服务的软件），并采用持续交付，可以选择“N/A”。 (需要网址) [release_notes]

    Release notes are published in github (e.g. https://github.com/hashgraph/guardian/releases/tag/v2.26.0) and correspondingly in Zenhub https://app.zenhub.com/workspaces/guardian-618c27c08661c0001461263a/reports/release?release=Z2lkOi8vcmFwdG9yL1JlbGVhc2UvNjg0ODE


    足够获得徽章！

    发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞，选择“不适用”。 [release_notes_vulns]

    To date we have not had any published vulnerabilities, however the process is setup such that all changes to the codebase are tracked via github tickets (issues, bugs) and a fix would be featured in the release report.


  • 错误报告流程


    足够获得徽章！

    项目必须为用户提交错误报告（例如，使用问题跟踪器或邮件列表）提供相关流程。 (需要网址) [report_process]

    The project accepts issues in github from contributors, e.g. https://github.com/hashgraph/guardian/issues/3780. The rules are described in https://github.com/hashgraph/guardian/blob/develop/CONTRIBUTING.md


    足够获得徽章！

    项目必须使用问题跟踪器来跟踪每个问题。 [report_tracker]

    Using github issues https://github.com/hashgraph/guardian/issues


    足够获得徽章！

    该项目必须响应过去2-12个月内（含）提交的大多数错误报告；响应不需要包括修复。 [report_responses]

    All issues are acknowledged and tracked in the https://github.com/hashgraph/guardian/issues?q=is%3Aissue+label%3Abug+


    足够获得徽章！

    该项目应该对过去2-12个月内（包括）的大部分（> 50％）的增强请求作出回应。 [enhancement_responses]

    All issues are acknowledged and responded to, see: https://github.com/hashgraph/guardian/issues?q=is%3Aissue


    足够获得徽章！

    该项目必须有一个公开的报告和回复的档案供后续搜索。 (需要网址) [report_archive]

    All information publicly available in https://github.com/hashgraph/guardian/issues, as well as searchable discord common channel.


  • 漏洞报告流程


    足够获得徽章！

    项目必须在项目网站上发布报告漏洞的流程。 (需要网址) [vulnerability_report_process]

    Vulnerabilities are reported as bugs as per https://github.com/hashgraph/guardian/blob/develop/CONTRIBUTING.md.


    足够获得徽章！

    如果支持私有漏洞报告，项目必须包括如何以保密的方式发送信息。 (需要网址) [vulnerability_report_private]

    All project information is public in github https://github.com/hashgraph/guardian


    足够获得徽章！

    该项目在过去6个月收到的任何漏洞报告的初始响应时间必须小于或等于14天。 [vulnerability_report_response]

    The github repository is constantly monitored and new github issues are reviewed and responded to within 24 hours.


  • 可工作的构建系统


    足够获得徽章！

    如果项目生成的软件需要构建使用，项目必须提供可以从源代码自动重新构建软件的可工作的构建系统。 [build]

    Non-trivial build file in repository: https://github.com/hashgraph/guardian/blob/main/Makefile.


    足够获得徽章！

    建议使用通用工具来构建软件。 [build_common_tools]

    Non-trivial build file in repository: https://github.com/hashgraph/guardian/blob/main/Makefile.


    足够获得徽章！

    该项目应该仅使用FLOSS工具来构建。 [build_floss_tools]

    It is the policy of the project to only use FLOSS software. The project is buildable using 'docker compose up -d --build' command on Linux systems.


  • 自动测试套件


    足够获得徽章！

    该项目必须使用至少一个作为FLOSS公开发布的自动测试套件（该测试套件可以作为单独的FLOSS项目维护）。 [test]

    The test suits are constantly evolving: https://github.com/hashgraph/guardian/tree/main/api-tests https://github.com/hashgraph/guardian/tree/main/e2e-tests


    足够获得徽章！

    测试套件应该以该语言的标准方式进行调用。 [test_invocation]

    CYPRESS and javascript.


    足够获得徽章！

    建议测试套件覆盖大部分（或理想情况下所有）代码分支，输入字段和功能。 [test_most]

    Both tests suits (API and product) cover inputs and functionality.


    足够获得徽章！

    建议项目实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 [test_continuous_integration]

    This is the case as evident from https://github.com/hashgraph/guardian/actions where tests are run on merges.


  • 新功能测试


    足够获得徽章！

    该项目必须有通用的策略（正式或非正式），当主要的新功能被添加到项目生成的软件中，该功能的测试应该同时添加到自动测试套件。 [test_policy]

    The project includes a dedicated QA team which develops automated testing and performs manual tests on new functionality. https://github.com/hashgraph/guardian/tree/main/api-tests https://github.com/hashgraph/guardian/tree/main/e2e-tests https://github.com/hashgraph/guardian?tab=readme-ov-file#unit-tests


    足够获得徽章！

    该项目必须有证据表明，在项目生成的软件的最近重大变化中，已经遵守了添加测试的条款： test_policy 。 [tests_are_added]

    Automated and manual tests are run on release merges https://github.com/hashgraph/guardian/actions


    足够获得徽章！

    建议您在更改提案的说明文档中添加测试策略要求（请参阅test_policy）。 [tests_documented_added]

    Described here https://github.com/hashgraph/guardian?tab=readme-ov-file#unit-tests


  • 警告标志


    足够获得徽章！

    该项目必须启用一个或多个编译器警告标志，“安全”语言模式，或者使用单独的“linter”工具查找代码质量错误或常见的简单错误，如果至少有一个FLOSS工具可以在所选择的语言实现此条款。 [warnings]

    The project uses linter and uses safe language mode.


    足够获得徽章！

    该项目必须处理警告。 [warnings_fixed]

    Guardian build process require developers to address warnings.


    足够获得徽章！

    建议在实际情况下，项目以最严格方式对待项目生成的软件中的告警。 [warnings_strict]

    The project build process requires the use of the strict warnings.


  • 安全开发知识


    足够获得徽章！

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

    The project includes a senior software architect who has the responsibility for security of the software. https://github.com/Pyatakov


    足够获得徽章！

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

    Core project developers are all senior developers, and use secure software development practices.


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

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

    足够获得徽章！

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

    Guardian uses standard libraries and protocols throughout, relying on Hedera blockchain system for cryptography.


    足够获得徽章！

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

    Guardian uses standard libraries and protocols throughout, relying on Hedera blockchain system for cryptography.


    足够获得徽章！

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

    Guardian uses FLOSS libraries and protocols throughout, including those belonging to Hedera blockchain system.


    足够获得徽章！

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

    Guardian uses recommended key lengths and conforms to NIST requirements.


    足够获得徽章！

    项目产生的软件中的默认安全机制不得取决于已被破解的密码算法（例如，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]

    足够获得徽章！

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

  • 修正公开的漏洞


    足够获得徽章！

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

    足够获得徽章！

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

  • 其他安全问题


    足够获得徽章！

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

  • 静态代码分析


    足够获得徽章！

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

    The project uses https://snyk.io/.


    足够获得徽章！

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

    The project uses https://snyk.io/.


    足够获得徽章！

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

    As per the development process these are addressed for every release.


    足够获得徽章！

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

  • 动态代码分析


    足够获得徽章！

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

    足够获得徽章！

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

    足够获得徽章！

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

    足够获得徽章！

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


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

项目徽章条目拥有者： Andrey (Envision).
最后更新于 2024-07-18 14:34:35 UTC, 最后更新于 2024-07-18 15:22:40 UTC。 最后在 2024-07-18 15:22:40 UTC 获得通过徽章。

后退