OpenSandbox

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

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

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


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

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

        

 基本 13/13 ●

  • 常规

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

    Secure, Fast, and Extensible Sandbox runtime for AI agents.

    请使用 SPDX许可证表达格式;例子包括“Apache-2.0”，“BSD-2-Clause”，“BSD-3-Clause”，“GPL-2.0+”，“LGPL-3.0 +”，“MIT”和“(BSD-2-Clause OR Ruby)”。
    如果有多种语言，请将它们列为逗号分隔值（可选空格），并将它们从最多到最少使用。如果有长列表，请至少列出前三个最常见的列表。如果没有语言（例如，这是仅文档或仅测试项目），请使用单个字符“ - ”。请使用每种语言的常规大小写，例如“JavaScript”。
    通用平台枚举（CPE）是用于信息技术系统，软件和软件包的结构化命名方案。在报告漏洞时，它可用于多个系统和数据库。

  • 基本项目网站内容


    足够获得徽章！

    项目网站必须简明扼要地描述软件的作用（它解决了什么问题？）。 [description_good]
    必须采用潜在用户可以理解的语言（例如，它使用最少的术语/行话）。

    https://open-sandbox.ai/


    足够获得徽章！

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

    Obtain: https://github.com/alibaba/OpenSandbox
    Feedback: https://github.com/alibaba/OpenSandbox/issues
    Discussions: https://github.com/alibaba/OpenSandbox/discussions
    Contribute: https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md


    足够获得徽章！

    关于如何贡献的信息必须解释贡献流程（例如，是否使用拉请求？） (需要网址) [contribution]
    除非另有说明，否则我们假定 GitHub上的项目使用问题列表（Issues）和拉（Pull）请求。这些信息可以简短，例如，说明项目使用拉请求，问题跟踪器或邮寄到邮件列表中的哪一个。

    Non-trivial contribution file in repository: https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md.


    足够获得徽章！

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

    Contribution requirements are documented in CONTRIBUTING.md, including:


  • FLOSS许可证


    足够获得徽章！

    项目生产的软件必须作为FLOSS发布。 [floss_license]
    FLOSS是以符合开源定义或免费软件定义。此类许可证的示例包括 CC0 ， MIT ， BSD 2条款， BSD 3条款修订版， Apache 2.0 ， Lesser GNU通用公共许可证（LGPL），以及 GNU通用公共许可证（GPL）。为了我们的目的，这意味着许可证必须是：该软件也可以用其他许可证（例如，“GPLv2或专有”是可以接受的）。

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


    足够获得徽章！

    建议由项目生成的软件的任何必需的许可证是由开放源码促进会（OSI）批准的许可证（英文）。 [floss_license_osi]
    OSI （开放源代码促进会）使用严格的审批流程来确定哪些许可证是开源软件（OSS）。

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


    足够获得徽章！

    项目必须将其许可证在其源代码存储库中的标准位置发布。 (需要网址) [license_location]
    一种约定是将许可证发布为名为LICENSE或COPYING的顶级文件，其后可以带有扩展名，例如“ .txt”或“ .md”。另一种约定是使用一个名为LICENSES的目录，其中包含许可证文件。这些文件通常被命名为其SPDX许可证标识符，后跟适当的文件扩展名，如REUSE Specification中所述。请注意，此标准只是源存储库上的要求。从源代码生成某些内容（例如可执行文件，程序包或容器）时，无需包括许可证文件。例如，在为综合R存档网络（CRAN）生成R软件包时，请遵循标准CRAN惯例：如果许可证是标准许可证，请使用标准简短许可证规范（以避免安装另一文本副本）并列出排除文件（例如.Rbuildignore）中的LICENSE文件。同样，在创建Debian软件包时，您可以在版权文件中放置一个指向/ usr / share / common-licenses中的许可证文本的链接，并从创建的软件包中排除许可证文件（例如，通过在调用dh_auto_install之后删除文件） ）。我们鼓励在可行的情况下以生成的格式包含机器可读的许可证信息。

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


  • 文档


    足够获得徽章！

    项目必须为项目生成的软件提供基本文档。 [documentation_basics]
    该文档必须在某些媒体（例如文本或视频）中，包括：如何安装它，如何启动它，如何使用它（可能使用教程使用示例）以及如何安全地使用它（例如，做什么和不做什么），如果这是软件的一个适当的话题。安全文档不需要太长篇幅。项目可以使用非项目内容的超文本链接作为文档。如果项目不生产软件，请选择“不适用”（N/A）。

    Some documentation basics file contents found.


    足够获得徽章！

    项目必须提供描述项目生成的软件的外部接口（输入和输出）的参考文档。 [documentation_interface]
    外部接口的文档向最终用户或开发人员解释如何使用它。这将包括其应用程序接口（API），如果软件有。如果它是一个库，记录可以调用的主要类/类型和方法/函数。如果是Web应用程序，定义其URL接口（通常是其REST接口）。如果是命令行界面，请记录其支持的参数和选项。在许多情况下，最好是自动生成大部分文档，以便本文档随着软件的更改而保持同步，但这并不是必需的。项目可以使用非项目材料的超文本链接作为文档。文档可以自动生成（实际上这通常是最好的方法）。可以使用Swagger / OpenAPI生成REST接口的文档。代码界面文档可以使用 JSDoc （JavaScript）， ESDoc （JavaScript），pydoc（Python）和Doxygen（很多）。仅在实现代码中添加注释不足以满足本条款；在没有阅读所有源代码的情况下，需要一个简单的方法来查看信息。如果项目不生产软件，请选择“不适用”（N/A）。

    OpenSandbox provides reference documentation for multiple external interfaces, including:

    These documents describe the project's external input/output interfaces without requiring readers to inspect implementation code.


  • 其他


    足够获得徽章！

    项目网站（网站，存储库和下载URL）必须使用TLS支持HTTPS。 [sites_https]
    您可以从Let's Encrypt获取免费证书。项目可以使用（例如） GitHub页面实现此条款， GitLab页面，或 SourceForge项目页面。如果您使用具有自定义域的GitHub页面，则可以使用内容传送网络（CDN）作为代理来支持HTTPS，例如博客文章“使用CloudFlare安全加速GitHub页面”，以满足此条款。如果您支持HTTP，我们敦促您将HTTP流量重定向到HTTPS。

    Given only https: URLs.


    足够获得徽章！

    该项目必须有一个或多个讨论机制（包括建议的更改和问题），可搜索，允许通过URL访问消息和主题，使新人能够参与一些讨论，并且不需要客户端安装专有软件。 [discussion]
    可接受机制的示例包括归档邮件列表，GitHub问题和拉请求讨论，Bugzilla，Mantis和Trac。如果满足这些标准，异步讨论机制（如IRC）是可以接受的；确保有一个URL可访问归档机制。允许专有JavaScript，但不鼓励。

    GitHub supports discussions on issues and pull requests.


    足够获得徽章！

    项目应该提供英文文档，并能够接受英文的代码的错误报告和评论。 [english]
    英语是计算机技术的通用语言；支持英语增加了全球不同潜在开发者和检视者的数量。即使核心开发人员的主要语言不是英文，项目也可以达到这个标准。

    OpenSandbox provides substantial project documentation in English, including the main repository README, contribution guide, API/specification documentation, CLI documentation, and SDK documentation. The project also accepts bug reports, pull requests, and code review comments through GitHub in English.

    Key URLs:
    https://github.com/alibaba/OpenSandbox
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md
    https://github.com/alibaba/OpenSandbox/blob/main/specs/README.md
    https://github.com/alibaba/OpenSandbox/blob/main/cli/README.md
    https://github.com/alibaba/OpenSandbox/issues
    https://github.com/alibaba/OpenSandbox/discussions


    足够获得徽章！

    必须维护该项目。 [maintained]
    至少，项目应尝试响应重大问题和漏洞报告。可能正在维护一个积极追求徽章的项目。所有项目和人员的资源都有限，典型项目必须拒绝某些提议的更改，因此有限的资源和提议拒绝本身并不表示未维护的项目。

    当项目知道将不再维护该项目时，应将此标准设置为“未满足”，并使用适当的机制向其他人指示该项目将不会得到维护。例如，使用“ DEPRECATED”作为其自述文件的第一个标题，在其主页开头附近添加“ DEPRECATED”，在其代码存储库项目说明的开头添加“ DEPRECATED”，在其中添加无需维护的标志其自述文件和/或主页，在任何软件包存储库中将其标记为已弃用（例如npm deprecate ），和/或使用代码存储库的标记系统对其进行归档（例如GitHub的“ archive”设置，GitLab的“ archived”标记， Gerrit的“只读”状态，或SourceForge的“已放弃”项目状态）。可以在这里找到更多讨论。

    OpenSandbox is actively maintained. The project has ongoing public development, open issue tracking, active CI workflows, public release automation, and recent releases across multiple components. It also has a documented security reporting process.

    Key URLs:
    https://github.com/alibaba/OpenSandbox
    https://github.com/alibaba/OpenSandbox/releases
    https://github.com/alibaba/OpenSandbox/actions
    https://github.com/alibaba/OpenSandbox/issues
    https://github.com/alibaba/OpenSandbox/blob/main/SECURITY.md


 变更控制 9/9 ●

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


    足够获得徽章！

    该项目必须有一个版本控制的源代码存储库。它必须是公开可读的并可通过URL访问。 [repo_public]
    该URL可以与项目URL相同。该项目可能在特定情况下使用私人（非公开）分支，而更改不会公开发布（例如，在向公众披露漏洞之前修复漏洞）。

    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]
    项目可以选择从其公共源代码库中删除特定的临时版本（例如，修复特定的未公开安全漏洞，可能永远不会公开发布的内容，或者包括不能合法发布而且不是最终版本的内容）。

    OpenSandbox uses a public Git repository for ongoing development, with interim commits, pull requests, reviews, issues, and release tags published in the same repository. Development is not limited to final release drops.

    Key URLs:
    https://github.com/alibaba/OpenSandbox
    https://github.com/alibaba/OpenSandbox/commits/main
    https://github.com/alibaba/OpenSandbox/pulls
    https://github.com/alibaba/OpenSandbox/releases


    足够获得徽章！

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

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


  • 唯一版本编号


    足够获得徽章！

    项目生成的用于每个用户使用的版本必须具有唯一版本标识符。 [version_unique]
    本条款可以通过各种方式来满足，包括提交ID（例如git提交ID或者Mercurial 更改列表id）或版本号（包括使用语义版本或基于日期的方案，如YYYYMMDD的版本号）。

    OpenSandbox is a monorepo with multiple independently released deliverables. Each user-facing release target has a unique version identifier, for example:

    • server/v0.1.11
    • docker/egress/v1.0.8
    • docker/execd/v1.0.12
    • python/sandbox/v0.1.7

    Key URLs:
    https://github.com/alibaba/OpenSandbox/tags
    https://github.com/alibaba/OpenSandbox/releases
    https://github.com/alibaba/OpenSandbox/blob/main/docs/release-automation.md


    足够获得徽章！

    建议使用语义版本控制（SemVer）格式进行发布。 [version_semver]
    其他版本编号方案，如提交ID（例如git commit id或mercurial changeset id）或基于日期的方案，如YYYYMMDD，可以用作版本号，因为它们是唯一的。一些备选方案可能会导致问题，因为用户可能无法轻松确定是否是最新的。如果所有目标客户仅运行最新版本，则SemVer可能不太有助于识别软件版本（例如，它是通过持续交付不断更新的单个网站或互联网服务的代码）。

    足够获得徽章！

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

    OpenSandbox identifies releases using git tags. The repository uses tag-driven release automation for multiple release targets, and releases are published from those tags.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/tags
    https://github.com/alibaba/OpenSandbox/releases
    https://github.com/alibaba/OpenSandbox/blob/main/docs/release-automation.md


  • 发行说明


    足够获得徽章！

    该项目必须在每个版本中提供发布说明，这是该版本中主要变化的可读的摘要，以帮助用户确定是否应升级，升级影响将如何。发行说明不能是版本控制日志的原始输出（例如，“git log”命令结果不是发行说明）。其产出不适用于多个地点的项目（如单个网站或服务的软件），并采用持续交付，可以选择“N/A”。 (需要网址) [release_notes]
    发行说明可以以各种方式实施。许多项目将它们添加到名为“NEWS”，“CHANGELOG”或“ChangeLog”的文件中，可选的包含“.txt”，“.md”或“.html”等扩展名。历史上，术语“更改日志”是指每个更改的日志，但为了满足这些条款，需要的是可读取的摘要。发行说明可以由版本控制系统机制提供，例如 GitHub发布工作流程。

    OpenSandbox provides human-readable release notes through GitHub Releases for published release targets. These release notes summarize user-visible features, bug fixes, breaking changes (when applicable), and contributors, rather than only listing raw commit logs.

    Examples:
    https://github.com/alibaba/OpenSandbox/releases/tag/server%2Fv0.1.11
    https://github.com/alibaba/OpenSandbox/releases/tag/docker%2Fegress%2Fv1.0.8
    https://github.com/alibaba/OpenSandbox/releases/tag/docker%2Fexecd%2Fv1.0.12

    Release note generation and format are documented here:
    https://github.com/alibaba/OpenSandbox/blob/main/docs/release-automation.md


    足够获得徽章！

    发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞，选择“不适用”。 [release_notes_vulns]
    如果用户通常不能在自己的计算机上实际更新软件，而必须依靠中间人来执行升级（对于内核和与内核交织的底层软件通常是这种情况），项目可以选择“不适用”（N/A）。

    N/A because we are not aware of any release in this project that fixed a publicly known run-time vulnerability with an assigned CVE (or similar identifier) at the time of release creation. This criterion applies only when such vulnerabilities exist and are fixed in a release.

    Project releases:
    https://github.com/alibaba/OpenSandbox/releases

    Security policy:
    https://github.com/alibaba/OpenSandbox/blob/main/SECURITY.md


 报告 8/8 ●

  • 错误报告流程


    足够获得徽章！

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

    Non-trivial SECURITY[.md] file found file in repository: https://github.com/alibaba/OpenSandbox/blob/main/SECURITY.md. [osps_do_02_01]


    足够获得徽章！

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

    OpenSandbox uses GitHub Issues as its public issue tracker for tracking individual issues, including bugs, feature requests, and documentation or implementation questions.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/issues
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md


    足够获得徽章！

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

    OpenSandbox acknowledges bug reports in its public GitHub issue tracker through triage, comments, linked fixes, and issue closure. Recent bug reports in the last 2-12 months show active maintainer response and follow-up.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/issues?q=is%3Aissue+label%3Abug
    https://github.com/alibaba/OpenSandbox/issues/620
    https://github.com/alibaba/OpenSandbox/issues/326
    https://github.com/alibaba/OpenSandbox/issues/252


    足够获得徽章！

    该项目应该对过去2-12个月内（包括）的大部分（> 50％）的增强请求作出回应。 [enhancement_responses]
    答复可能是“不”或有关其价值的讨论。目的只是对某些请求有一些回应，这表明项目还活着。为了该条款的目的，项目不需要计数无效请求（例如，来自垃圾邮件发送者或自动系统）。如果项目不再进行增强，请选择“未满足”，并将介绍此情况的URL包含在内。如果一个项目有超出处理能力的增强需求数量，请选择“未满足”并解释。

    OpenSandbox responds to enhancement and feature requests in its public GitHub issue tracker. In this repository, enhancement requests are commonly tracked with the feature label and are acknowledged through discussion, comments, triage, and issue closure when implemented or resolved.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/issues?q=is%3Aissue+label%3Afeature
    https://github.com/alibaba/OpenSandbox/issues/609
    https://github.com/alibaba/OpenSandbox/issues/442
    https://github.com/alibaba/OpenSandbox/issues/115


    足够获得徽章！

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

    OpenSandbox maintains a publicly available archive of reports and responses through GitHub Issues, GitHub Discussions, and pull requests. These records are public, searchable, and preserved for later reference.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/issues
    https://github.com/alibaba/OpenSandbox/discussions
    https://github.com/alibaba/OpenSandbox/pulls


  • 漏洞报告流程


    足够获得徽章！

    项目必须在项目网站上发布报告漏洞的流程。 (需要网址) [vulnerability_report_process]
    例如，https://PROJECTSITE/security 上的一个明确指定的邮箱地址，通常以 security@example.org 的形式。这可能与其错误报告流程相同。漏洞报告可能一直是公开的，但是许多项目都有一个私密漏洞报告机制。

    OpenSandbox publishes its vulnerability reporting process in the public security policy. The policy explains how to report security issues and directs reporters to GitHub Security Advisories and the project's security reporting process.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/SECURITY.md
    https://github.com/alibaba/OpenSandbox/security


    足够获得徽章！

    如果支持私有漏洞报告，项目必须包括如何以保密的方式发送信息。 (需要网址) [vulnerability_report_private]
    示例包括使用HTTPS（TLS）或使用OpenPGP加密的电子邮件在网络上提交的私密缺陷报告。如果漏洞报告总是公开的（从来没有私密漏洞报告），请选择“不适用”（N/A）。

    OpenSandbox supports private vulnerability reporting. The public security policy instructs reporters to open a private GitHub Security Advisory, which provides a private reporting channel.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/SECURITY.md
    https://github.com/alibaba/OpenSandbox/security


    足够获得徽章！

    该项目在过去6个月收到的任何漏洞报告的初始响应时间必须小于或等于14天。 [vulnerability_report_response]
    如果过去6个月没有报告漏洞，请选择“不适用”（N/A）。

    Based on publicly visible GitHub records from the last 6 months (October 23, 2025 to April 23, 2026), no identified vulnerability report had an initial project response later than 14 days.


 质量 13/13 ●

 安全 16/16 ●

 分析 8/8 ●


该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Sky和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Sky.
最后更新于 2026-04-19 13:16:25 UTC, 最后更新于 2026-05-03 01:01:44 UTC。 最后在 2026-04-26 14:38:05 UTC 获得通过徽章。