OpenSandbox

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, покажите свой значок на странице проекта! Статус значка выглядит следующим образом: Уровень значка для проекта 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>


Это критерии уровня Silver. Вы также можете просмотреть критерии уровня Passing или Gold.

Baseline Series: Базовый уровень 1 Базовый Уровень 2 Базовый Уровень 3

        

 Основы 17/17 ●

  • Общая

    Обратите внимание, что другие проекты могут использовать то же имя.

    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».
    Common Platform Enumeration (CPE) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.

  • Предварительные требования


    Достаточно для значка!

    Проект ОБЯЗАН получить значок уровня Passing. [achieve_passing]

  • Основная информация на веб-сайте проекта


    Достаточно для значка!

    В информацию о том, как внести вклад, НЕОБХОДИМО включить требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). (Требуется URL) [contribution_requirements]

    Contribution requirements are documented in CONTRIBUTING.md, including:


  • Надзор за проектом


    Достаточно для значка!

    Проекту СЛЕДУЕТ иметь юридический механизм, через который все авторы содержательных взносов в ПО проекта подтверждают, что они имеют законное право на внесение этих взносов. Самый распространенный и легко реализуемый подход для этого заключается в использовании Developer Certificate of Origin (DCO), при котором пользователи добавляют строку "signed-off-by" в свои коммиты, а проект ссылается на веб-сайт DCO. Но этот механизм МОЖЕТ быть реализован и в качестве Лицензионного соглашения с участниками (Contributor License Agreement, CLA) или другого правового механизма. (Требуется URL) [dco]
    DCO является рекомендуемым механизмом, потому что его легко реализовать и отслеживать в исходном коде, а git напрямую поддерживает функцию "signed-off" при помощи "commit -s". Для большей эффективности лучше всего, если проектная документация объясняет, что означает "signed-off" для этого проекта. CLA - это юридическое соглашение, которое определяет условия, на которых произведения умственного труда были лицензированы для организации или проекта. Соглашение о назначении участника (contributor assignment agreement, CAA) является юридическим соглашением, которое передает права на произведения умственного труда другой стороне; проекты не обязаны иметь CAA, поскольку CAA увеличивает риск того, что потенциальные участники не будут вносить свой вклад, особенно если получатель является коммерческой организацией. Лицензии CLA от Apache Software Foundation (лицензия отдельного участника и корпоративное соглашение CLA) являются примерами CLA для проектов, считающих, что риски от такого рода CLA для проекта меньше, чем их преимущества.

    OpenSandbox uses a Contributor License Agreement (CLA) mechanism. Pull requests are checked by CLA Assistant, and contributors must have the CLA signed for the license/cla check to pass. For example, PR #827 shows the license/cla check passing with "Contributor License Agreement is signed." The contributing guide also states that contributions are licensed under the Apache 2.0 License.

    Key URLs:
    https://cla-assistant.io/alibaba/OpenSandbox?pullRequest=827
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md#license


    Достаточно для значка!

    Проект ОБЯЗАН четко определить и задокументировать модель управления проектом (способ принятия решений, включая ключевые роли). (Требуется URL) [governance]
    Требуется устоявшийся задокументированный способ принятия решений и разрешения споров. В небольших проектах это может быть просто вплоть до «владелец и лидер проекта принимает все окончательные решения». Существуют различные модели управления, включая благосклонное диктаторство и формальную меритократию; более подробно см. Governance models. В проектах успешно используются как централизованные подходы (например, с одним ведущим), так и децентрализованные (например, с групповыми ведущими). Не нужно указывать в сведениях об управлении возможность форка проекта, поскольку это всегда возможно для проектов СПО.

    https://github.com/alibaba/OpenSandbox/blob/main/GOVERNANCE.md


    Достаточно для значка!

    Проект ОБЯЗАН определить правила поведения и разместить эти правила в стандартном месте. (Требуется URL) [code_of_conduct]
    Проекты могут повысить цивилизованность их сообщества и установить ожидания относительно приемлемого поведения, приняв правила поведения. Это может помочь избежать проблем до их возникновения и сделать проект более привлекательным местом, поощряющим участие. Правила должны быть сосредоточены только на поведении в сообществе или на рабочем месте проекта. Примерами правил поведения являются правила конфликтов на проекте ядра Linux, Contributor Covenant Code of Conduct, Кодекс поведения Debian, Ubuntu Code of Conduct, Правила поведения проекта Fedora, GNOME Code Of Conduct, KDE Community Code of Conduct">, Python Community Code of Conduct, The Ruby Community Conduct Guideline и The Rust Code of Conduct.

    https://github.com/alibaba/OpenSandbox/blob/main/CODE_OF_CONDUCT.md


    Достаточно для значка!

    Проект ОБЯЗАН четко определять и публично документировать ключевые роли в проекте и их обязанности, включая любые задачи, которые должны выполнять эти роли. Должно быть ясно, кто имеет какую роль(и), хотя это может быть и не задокументировано соответствующим образом. (Требуется URL) [roles_responsibilities]
    Документация для управления , а также роли и обязанности могут быть в одном месте.

    key URLs:


    Достаточно для значка!

    Проект ОБЯЗАН быть в состоянии продолжать работу с минимальным прерыванием, если какой-либо человек окажется недееспособен или убит. В частности, проект ОБЯЗАН быть в состоянии создавать и закрывать вопросы в трекере, принимать предложенные изменения и выпускать версии программного обеспечения через неделю после подтверждения того, что данный человек недееспособен или убит. Это МОЖЕТ быть реализовано через обеспечение кого-то ещё необходимыми ключами, паролами и законными правами для продолжения проекта. Лица, которые запускают проект СПО, МОГУТ сделать это, оставив ключи в сейфе и завещание, передающее все необходимые юридические права (например, для имен DNS). (Требуется URL) [access_continuity]

    key URLs:


    Достаточно для значка!

    Проекту СЛЕДУЕТ поддерживать «коэффициент автобуса» 2 или более. (Требуется URL) [bus_factor]
    «Коэффициент автобуса» (или «коэффициент грузовика») - это минимальное количество участников проекта, которые должны внезапно исчезнуть из проекта («попасть под автобус»), чтобы проект заглох из-за отсутствия квалифицированного или компетентного персонала. Инструмент truck-factor может оценить это для проектов на GitHub. Для получения дополнительной информации см. статью Cosentino et al. Assessing the Bus Factor of Git Repositories.

    The repository has multiple default and component code owners, so project maintenance is not dependent on one person.
    key URLs:


  • Документация


    Достаточно для значка!

    Проект ОБЯЗАН иметь задокументированный долгосрочный план (roadmap), описывающий, что проект намеревается, а что не намеревается делать, по крайней мере на ближайший год. (Требуется URL) [documentation_roadmap]
    Проект может не достичь того, что описано в долгосрочном плане, и это нормально. Цель дорожной карты - помочь потенциальным пользователям и участникам понять намеченное направление проекта. Подробности не требуются.

    https://github.com/alibaba/OpenSandbox/blob/main/README.md


    Достаточно для значка!

    Проект ОБЯЗАН включать документацию по архитектуре (также называемой высокоуровневым дизайном) ПО, создаваемого проектом. Выберите «неприменимо» (N/A), если проект не создает программное обеспечение. (Требуется URL) [documentation_architecture]
    Архитектура ПО объясняет фундаментальную структуру программы, то есть основные компоненты программы, отношения между ними и ключевые свойства этих компонентов и отношений.

    https://github.com/alibaba/OpenSandbox/blob/main/docs/architecture.md


    Достаточно для значка!

    Проект ОБЯЗАН документировать то, что пользователь может и чего он не должен ожидать с точки зрения безопасности от ПО, создаваемого проектом (его «требования безопасности»). (Требуется URL) [documentation_security]
    Это требования безопасности, выполнение которых ожидается от ПО.

    https://github.com/alibaba/OpenSandbox/blob/main/docs/secure-container.md


    Достаточно для значка!

    Проект ОБЯЗАН предоставить руководство для быстрого начала работы для новых пользователей, чтобы помочь им быстро что-то сделать, используя ПО, создаваемое проект. (Требуется URL) [documentation_quick_start]
    Идея состоит в том, чтобы показать пользователям, как начать работу и и добиться, чтобы ПО что-то вообще сделало. Потенциальным пользователям это критически важно для начала работы.

    key URLs:


    Достаточно для значка!

    Проект ОБЯЗАН прилагать усилия к тому, чтобы документация соответствовала текущей версии результатов проекта (включая ПО, создаваемое проектом). НЕОБХОДИМО исправлять любые известные дефекты документации, приводящие к ее непоследовательности. Если документация в целом актуальна, но ошибочно включает в себя некоторые более старые данные, которые больше не верны, просто рассматривайте это как дефект, отслеживайте и исправляйте, как обычно. [documentation_current]
    Документация МОЖЕТ включать информацию о различиях или изменениях между версиями программного обеспечения и/или ссылку на более старые версии документации. Смысл этого критерия заключается в том, что прилагаются усилия для обеспечения согласованности документации, а не в том, чтобы документация была идеальной.

    https://github.com/alibaba/OpenSandbox/commits/main/docs


    Достаточно для значка!

    НЕОБХОДИМО размещать ссылку на любые свои достижения, включая этот значок передовой практики, на главной странице проекта и/или веб-сайте в течение 48 часов после открытого признания достижения. (Требуется URL) [documentation_achievements]
    Достижением считается любой набор внешних критериев, над выполнением которых проект специально работал, включая некоторые значки. Эта информация не обязательно должна находиться на главной странице веб-сайта проекта. Проект с использованием GitHub может помещать достижения на главную страницу хранилища кода, добавляя их в файл README.

    The repository front page identifies and links to public project achievements. The README includes linked badges and statements for achievements such as Trendshift and CNCF Landscape, including a CNCF Landscape badge and a sentence linking to the OpenSandbox CNCF Landscape entry. Once an OpenSSF Best Practices badge is awarded, the project will add the badge link to the README within 48 hours of public recognition.

    Key URLs:
    https://github.com/alibaba/OpenSandbox#readme
    https://landscape.cncf.io/?item=orchestration-management--scheduling-orchestration--opensandbox


  • Общедоступность и интернационализация


    Достаточно для значка!

    Проекту (как на сайтах проекта, так и в результатах работы проекта) СЛЕДУЕТ придерживаться передовой практики общедоступности, чтобы люди с ограниченными возможностями могли участвовать в проекте и использовать результаты проекта, где это имеет смысл. [accessibility_best_practices]
    Для веб-приложений см. Руководство по обеспечению доступности веб-контента (WCAG) 2.0 и его поддерживающий документ Understanding WCAG 2.0; см. также W3C accessibility information. Для приложений с графическим интерфейсом рассмотрите использование соответствующих вашему окружению рекомендаций по обеспечению доступности (таких как GNOME, KDE, XFCE, Android, iOS, Mac и Windows (на русском)). Некоторые приложения с текстовым интерфейсом пользователя (например, программы на ncurses) могут сделать некоторые вещи, чтобы сделать себя более доступными (например, параметр `force-arrow-cursor` в `alpine`). Большинство приложений командной строки довольно общедоступны как они есть. Этот критерий часто неприменим, например, для библиотек программ. Вот несколько примеров действий или проблем, которые следует учитывать:
    • Должны предоставляться текстовые альтернативы для любого нетекстового контента, так чтобы его можно изменить на другие необходимые формы, например крупная печать, шрифт Брайля, озвучка текста, символы или упрощенный язык (Understanding WCAG 2.0 guideline 1.1)
    • Цвет не должен использоваться в качестве единственного визуального средства передачи информации, указания на действие, запрос реакции пользователя или выделения визуальных элементов. (WCAG 2.0 guideline 1.4.1)
    • Визуальное представление текста и изображений текста должно иметь контрастность не менее 4,5:1, за исключением большого текста, случайного текста и логотипов (WCAG 2.0 guideline 1.4.3)
    • Все функциональные возможности должны быть доступны с клавиатуры (WCAG guideline 2.1)
    • GUI или веб-проект ДОЛЖНЫ тестировать, по крайней мере, одно средство чтения экрана на целевой платформе(ах) (например, NVDA, Jaws или WindowEyes в Windows; VoiceOver на Mac и iOS; Orca на Linux/BSD; TalkBack на Android). Программы с текстовым интерфейсом пользователя МОГУТ по возможности сокращать переписывание текста на экране, чтобы предотвратить лишнее чтение средствами чтения экрана.

    https://github.com/alibaba/OpenSandbox/blob/main/README.md


    Достаточно для значка!

    Проекту СЛЕДУЕТ интернационализировать создаваемое ПО, чтобы обеспечить легкую локализацию под культуру, регион или язык целевой аудитории. Выберите «неприменимо» (N/A), если интернационализация (i18n) не применяется (например, ПО не генерирует текст, предназначенный для конечных пользователей, и не сортирует текст, читаемый человеком), [internationalization]
    Локализация "относится к адаптации продукта, приложения или содержимого документа для соответствия языковым, культурным и другим требованиям конкретного целевого рынка (языковому стандарту)". Интернационализация - это «проектирование и разработка продукта, приложения или содержимого документа, которые позволяют легкую локализацию под целевые аудитории, различающиеся по культуре, региону или языку». (См. «Локализация по сравнению с интернационализацией» на веб-сайте W3C.) Чтобы ПО соответствовало этому критерию, достаточно лишь интернационализации. Не требуется локализация для другого конкретного языка, так как после того, как программное обеспечение было интернационализировано, другие могут работать над локализацией.

    project results are primarily SDKs, APIs, CLI tools, and services, with limited end-user UI text requiring localization.


  • Другое


    Достаточно для значка!

    Если на сайтах проекта (веб-сайт, хранилище и URL-адреса загрузки) хранятся пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с отдельной "солью" для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, Argon2id, Bcrypt, Scrypt или PBKDF2). Выберите «неприменимо» (N/A), если сайты проекта не хранят пароли для этой цели. [sites_password_security]
    Примечание: использование GitHub автоматически выполняет этот критерий. Этот критерий применяется только к паролям, используемым для аутентификации внешних пользователей на сайтах проекта (т.н. входящей аутентификации). Если сайты проекта должны подключаться к другим сайтам (т.н. исходящая аутентификация), им может потребоваться хранить аутентифицирующие данные (пароли, ключи) для этой цели как-то иначе (поскольку хранение контрольной суммы для этой цели бесполезно). В данном случае критерий crypto_password_storage применяется к сайтам проекта, по аналогии с критерием sites_https.

    project sites use GitHub/GitHub Pages and do not store passwords for external user authentication.


 Управление изменениями 1/1 ●

  • Предыдущие версии


    Достаточно для значка!

    Проект ОБЯЗАН поддерживать наиболее часто используемые старые версии продукта или предоставлять возможность простого перехода на более новые версии (upgrade path). Если переход затруднен, проект ОБЯЗАН задокументировать порядок обновления (например, изменившиеся интерфейсы и подробные предлагаемые шаги для обновления). [maintenance_or_update]

    key URLs:


 Отчеты о проблемах 3/3 ●

  • Процесс сообщения об ошибках


    Достаточно для значка!

    Проект ОБЯЗАН использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [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


  • Процесс отчета об уязвимостях


    Достаточно для значка!

    Проект ОБЯЗАН отмечать автора(-ов) всех отчетов об уязвимостях, разрешенных за последние 12 месяцев, за исключением авторов, которые просят об анонимности. Выберите «неприменимо» (N/A), если в течение последних 12 месяцев не было обнаружено никаких уязвимостей. (Требуется URL) [vulnerability_report_credit]

    N/A: no resolved vulnerability reports in the last 12 months requiring reporter credit.


    Достаточно для значка!

    Проект ОБЯЗАН иметь документированный процесс реагирования на отчеты об уязвимостях. (Требуется URL) [vulnerability_response_process]
    Этот критерий тесно связан с критерием vulnerability_report_process, который требует документированного способа для сообщения об уязвимостях. Он также связан с vulnerability_report_response, который требует ответа на отчеты об уязвимостях в течение определенного периода времени.

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


 Качество 19/19 ●

  • Стандарты кодирования


    Достаточно для значка!

    Проект ОБЯЗАН задать определенные правила стиля кодирования для основных языков, которые он использует, и требовать его соблюдения от предлагаемого кода. (Требуется URL) [coding_standards]
    В большинстве случаев это делается путем ссылки на некоторые существующие руководства по стилю, возможно, с перечислением различий. Эти руководства по стилю могут включать в себя способы повышения удобочитаемости и способы снижения вероятности дефектов (включая уязвимости). Многие языки программирования имеют один или несколько широко используемых руководств по стилю. Примеры руководств по стилю включают Руководство по стилю Google и Стандарты кодирования SEI CERT.

    OpenSandbox meets this because CONTRIBUTING.md requires contributions to follow the coding standards for the language/component they touch, and explicitly lists the required style guides: Python follows PEP 8 plus Google-style public API docstrings; Go follows Effective Go and Go Code Review Comments; JavaScript/TypeScript follows TypeScript ESLint recommended and stylistic rule sets; Kotlin follows Kotlin Coding Conventions; C# follows Microsoft C# coding conventions. It also documents that generated files should be regenerated from source specs instead of hand-edited.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md#coding-standards


    Достаточно для значка!

    Проект ОБЯЗАН автоматически применять свой выбранный стиль(и) кодирования, если есть хотя бы один инструмент на СПО, который может сделать это на выбранном языке (языках). [coding_standards_enforced]
    Это МОЖЕТ быть реализовано при помощи инструмента(ов) статического анализа и/или путем пропускания кода через средства переформатирования. Во многих случаях конфигурация инструмента включена в репозиторий проекта (так как разные проекты могут выбирать разные конфигурации). Проекты МОГУТ (и, как правило, будут) допускать исключения стиля; там, где происходят исключения, они ОБЯЗАНЫ быть редки и документированы в соответствующих местах кода, чтобы эти исключения можно было пересматривать и инструменты могли автоматически обрабатывать их в будущем. Примеры таких инструментов включают ESLint (JavaScript) и Rubocop (Ruby).

    OpenSandbox meets this because the selected styles are automatically checked in repository tooling and CI. Python packages configure Ruff/Pyright in pyproject.toml, and CI runs uv run ruff check plus Pyright where applicable. Go components and the Go SDK run gofmt, go vet, and golangci-lint where configured. JavaScript/TypeScript SDKs use shared ESLint configuration with TypeScript ESLint recommended/stylistic rules, and CI runs lint and typecheck. Kotlin SDKs use Gradle Spotless with ktlint and CI runs spotlessCheck. C# SDKs enable .NET analyzers/code style in build and CI builds with /warnaserror.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md#automated-enforcement
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/server-test.yml
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/sdk-tests.yml
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/eslint.base.mjs


  • Рабочая система сборки


    Достаточно для значка!

    Системы сборки для нативных двоичных файлов ОБЯЗАНЫ учитывать соответствующие переменные (среды) для компилятора и компоновщика, переданные им (например, CC, CFLAGS, CXX, CXXFLAGS и LDFLAGS) и передавать их на вызовы компилятора и компоновщика. Система сборки МОЖЕТ расширять их дополнительными флагами; НЕДОПУСТИМО просто заменять предоставленные значения своими. Выберите «неприменимо» (N/A), если нативные двоичные файлы не создаются. [build_standard_variables]
    Должно быть легко включить специальные функции сборки, такие как Address Sanitizer (ASAN), или выполнить рекомендации по упрочнению от дистрибутивов (например, путем простого включения флагов компилятора для этого).

    OpenSandbox meets this because its native Go build paths preserve caller-provided build variables instead of replacing them. The Makefiles for execd, ingress, Kubernetes, and the Go SDK pass user-provided GOFLAGS into go build and user-provided LDFLAGS into go build -ldflags, then append project-required flags such as -trimpath, -buildvcs=false, and reproducible build-id flags. Docker image build scripts also forward GOFLAGS, LDFLAGS, CGO_ENABLED, CC, CXX, CFLAGS, CXXFLAGS, CGO_CFLAGS, CGO_CXXFLAGS, and CGO_LDFLAGS as build args, and the Dockerfiles export them before invoking go build.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md#build-system-standards
    https://github.com/alibaba/OpenSandbox/blob/main/components/execd/Makefile
    https://github.com/alibaba/OpenSandbox/blob/main/components/execd/Dockerfile
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/Makefile


    Достаточно для значка!

    В системах сборки и установки СЛЕДУЕТ сохранять отладочную информацию, если передаваемые флаги требуют этого (например, не используется «install -s»). Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, для типичных библиотек JavaScript), . [build_preserve_debug]
    Например, установка CFLAGS (C) или CXXFLAGS (C++) должна создавать соответствующую информацию для отладки, если эти языки используются, и ее не следует удалять во время установки. Отладочная информация необходима для поддержки и анализа, а также полезна для того, чтобы определить наличие упрочняющих функций в скомпилированных двоичных файлах.

    OpenSandbox meets this because the documented build standard requires default native builds not to strip debug information: it explicitly forbids strip, install -s, and Go linker flags such as -s -w in the default developer and CI build path. Current native Go Makefiles and Dockerfiles do not use those stripping flags; they preserve caller-supplied LDFLAGS and only append reproducibility/version metadata flags such as -buildid= -B none. This allows debug-related flags requested by contributors or downstream packagers to pass through the build system.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md#debug-information
    https://github.com/alibaba/OpenSandbox/blob/main/components/execd/Makefile
    https://github.com/alibaba/OpenSandbox/blob/main/components/execd/Dockerfile
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/Dockerfile


    Достаточно для значка!

    НЕДОПУСТИМО, чтобы система сборки ПО, создаваемого проектом, рекурсивно собирала подкаталоги, если в подкаталогах есть кросс-зависимости. Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, типичные библиотеки JavaScript). [build_non_recursive]
    Информация о внутренних зависимостях системы сборки проекта должна быть точной, в противном случае изменения в проекте могут быть включены в сборку неправильно. Неправильные сборки могут привести к дефектам (включая уязвимости). Общей ошибкой в ​​больших системах сборки является использование «рекурсивной сборки» или «рекурсивного make», то есть иерархии подкаталогов, содержащих исходные файлы, где каждый подкаталог собирается независимо. Если только каждый из подкаталогов не является полностью независимым, это ошибка, потому что информация о зависимостях неверна.

    OpenSandbox meets this because its build standards require package-aware build tools instead of recursive independent subdirectory builds. Go code is built with go build ./... or explicit Go package entry points, so the Go toolchain owns dependency resolution. JavaScript/TypeScript SDKs use pnpm workspace dependencies, Kotlin SDKs use Gradle task dependencies, and C# SDKs use solution/project references through dotnet build. The project documentation also explicitly says subdirectory Make targets may delegate to these tools, but must not replace the build tool’s dependency graph with independent recursive directory builds.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md#build-dependency-graph
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/Makefile
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/package.json
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/go/Makefile


    Достаточно для значка!

    Проект ОБЯЗАН быть в состоянии повторить процесс генерации информации из исходных файлов и получить такой же результат с точностью до бита. Выберите «неприменимо» (N/A), если в проекте не используется сборка (например, языки сценариев, в которых исходный код используется непосредственно вместо компиляции), . [build_repeatable]
    Пользователи GCC и clang могут найти полезной опцию -frandom-seed; в некоторых случаях это может быть разрешено путем задания определенного порядка сортировки. Дополнительные предложения можно найти на сайте Reproducible builds.

    OpenSandbox meets this because native Go binary builds include repeatability controls: -trimpath, -buildvcs=false, and linker flags -buildid= -B none, which remove source paths, VCS metadata, build IDs, and Mach-O UUIDs from the output. The build system also supports repeatable release metadata by allowing SOURCE_DATE_EPOCH, or explicit BUILD_TIME, VERSION, and GIT_COMMIT; when SOURCE_DATE_EPOCH is set, the build scripts derive a stable BUILD_TIME from it.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md#repeatable-builds
    https://github.com/alibaba/OpenSandbox/blob/main/components/execd/Makefile
    https://github.com/alibaba/OpenSandbox/blob/main/components/execd/build.sh
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/Dockerfile


  • Система установки


    Достаточно для значка!

    Проект ОБЯЗАН предоставлять возможность легко установить и удалить ПО, создаваемое проектом, с использованием общепринятых способов. [installation_common]
    Примеры включают использование менеджера пакетов (на уровне системы или языка), «make install/uninstall» (с поддержкой DESTDIR), контейнер в стандартном формате или образ виртуальной машины в стандартном формате. Процесс установки и удаления (например, его упаковка) МОЖЕТ быть реализован третьей стороной, при условии что он построен на СПО.

    OpenSandbox meets this because it provides standard installation paths for its main deliverables instead of a custom installer. SDKs are installed through common language package managers: Python via pip/uv, JavaScript/TypeScript via npm/pnpm/yarn, Java/Kotlin via Gradle or Maven, C# via NuGet, and Go via go get. The CLI and MCP server are also installed through standard Python packaging tools such as pip, uv tool, or pipx. Kubernetes deployments are installed and uninstalled through standard Helm commands, including helm install, helm upgrade, and helm uninstall.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/README.md#sdks
    https://github.com/alibaba/OpenSandbox/blob/main/cli/README.md#install
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/charts/opensandbox/README.md#quick-start
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/charts/opensandbox/README.md#uninstall


    Достаточно для значка!

    В системе установки для конечных пользователей НЕОБХОДИМО учитывать стандартные соглашения при выборе места, в которое собранные артефакты записываются при установке. Например, если она устанавливает файлы в системе POSIX, НЕОБХОДИМО учитывать переменную окружения DESTDIR. Если установочной системы или стандартного соглашения нет, выберите «неприменимо» (N/A). [installation_standard_variables]

    OpenSandbox meets this because end-user installation locations are delegated to standard installation systems rather than hard-coded by a custom installer. Python packages follow normal pip/uv conventions such as virtual environments, user installs, prefixes, and package scripts; JavaScript packages follow npm/pnpm/yarn project or global prefix conventions; Java/Kotlin, C#, and Go artifacts are resolved through their standard dependency managers; and Kubernetes installation uses Helm release names and namespaces, including --namespace and --create-namespace. Since OpenSandbox does not use a custom POSIX make install path for end-user installation, DESTDIR is not bypassed or replaced.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/server/README.md#installation
    https://github.com/alibaba/OpenSandbox/blob/main/cli/pyproject.toml
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/javascript/package.json
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/charts/opensandbox-server/README.md#install


    Достаточно для значка!

    Проект ОБЯЗАН предоставить возможность потенциальным разработчикам быстро установить все результаты проекта и поддерживать среду, необходимую для внесения изменений, включая тесты и тестовое окружение. Проект ОБЯЗАН использовать для этого общепринятые соглашения. [installation_development_quick]
    Это МОЖЕТ быть реализовано при помощи сгенерированного контейнера или установочных сценариев. Внешние зависимости обычно устанавливаются путем вызова системных и/или языковых пакетов, как описано в критерии external_dependencies.

    OpenSandbox meets this because it documents quick developer setup using common tools for each major component. CONTRIBUTING.md lists prerequisites and setup commands for server development (uv sync, run tests), execd development (go mod download, go build), and SDK development (uv sync, pytest). Component guides also provide focused setup and validation commands, and CI uses the same package-manager conventions (uv sync, pnpm install --frozen-lockfile, Gradle, Go tooling) to install dependencies and run tests.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md#development-environment-setup
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md#quick-setup
    https://github.com/alibaba/OpenSandbox/blob/main/server/AGENTS.md#commands
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/AGENTS.md#commands


  • Компоненты, поддерживаемые извне


    Достаточно для значка!

    Проект ОБЯЗАН перечислять внешние зависимости в машинночитаемом виде. (Требуется URL) [external_dependencies]
    Обычно это делается при помощи инструкций для диспетчера пакетов и/или системы сборки. Обратите внимание, что это помогает реализовать критерий installation_development_quick.

    OpenSandbox meets this because external dependencies are listed in standard, computer-processable package-manager files. Python components use pyproject.toml and uv.lock; JavaScript/TypeScript uses package.json and pnpm-lock.yaml; Go components use go.mod and go.sum; Kotlin/Java uses Gradle version catalogs and build files; C# uses .csproj project files; and Helm deployments use Chart.yaml and values files.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/server/pyproject.toml
    https://github.com/alibaba/OpenSandbox/blob/main/server/uv.lock
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/package.json
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/pnpm-lock.yaml
    https://github.com/alibaba/OpenSandbox/blob/main/components/execd/go.mod
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/charts/opensandbox/Chart.yaml


    Достаточно для значка!

    Проекты ОБЯЗАНЫ следить за своими внешними зависимостями или периодически проверять их (включая копии, сделанные для удобства) на предмет известных уязвимостей, а также исправлять уязвимости, которые могут быть использованы, или проверять невозможность их использования. [dependency_monitoring]
    Это можно сделать с помощью средств анализа происхождения/зависимостей, например Dependency-Check от OWASP, Nexus Auditor от Sonatype, Protex от Black Duck , Protecode от Synopsys и Bundler-аудит (для Ruby). Некоторые менеджеры пакетов включают в себя соответствующие механизмы. Допустимо оставлять уязвимость, если ее невозможно использовать, но такой анализ труден, и временами проще просто обновить или исправить эту часть кода.

    OpenSandbox meets this because GitHub Dependabot vulnerability alerts are enabled for the repository, and the GitHub dependency graph can generate an SBOM from the project’s package-manager manifests. I verified the Dependabot alerts API shows fixed dependency vulnerability alerts, including Go and npm dependencies. The release notes also show dependency-security updates from Dependabot, for example bumps to urllib3, pyasn1, golang.org/x/net, google.golang.org/grpc, and other external packages.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/network/dependencies
    https://github.com/alibaba/OpenSandbox/security/dependabot
    https://github.com/alibaba/OpenSandbox/blob/main/server/RELEASE_NOTES.md
    https://github.com/alibaba/OpenSandbox/blob/main/components/execd/RELEASE_NOTES.md


    Достаточно для значка!

    Проект ОБЯЗАН:
    1. позволять легко идентифицировать и обновлять повторно используемые компоненты, поддерживаемые извне; или
    2. использовать стандартные компоненты, предоставляемые системой или языком программирования.
    В этом случае, если уязвимость обнаружена в повторно используемом компоненте, будет легко обновить этот компонент. [updateable_reused_components]
    Типичным способом выполнить этот критерий является использование предоставляемых операционной системой и языком программирования систем управления пакетами. Многие свободные программы распространяются с «подсобными библиотеками», которые являются локальными копиями стандартных библиотек (возможно, форков библиотек). Само по себе это нормально. Однако, если программа *должна* использовать эти локальные копии/форки, то обновление «стандартных» библиотек через системное обновление безопасности оставит эти дополнительные копии по-прежнему уязвимыми. Это особенно актуально для облачных систем; если провайдер облака обновляет свои «стандартные» библиотеки, но программа их не собирается использовать, обновления фактически не помогут. См., например, "Chromium: Why it isn't in Fedora yet as a proper package" от Тома Каллавея.

    OpenSandbox meets this because reused external components are managed through standard package-management systems rather than committed convenience copies. Python dependencies are in pyproject.toml/uv.lock, JavaScript dependencies are in package.json/pnpm-lock.yaml, Go dependencies are in go.mod/go.sum, Kotlin dependencies are in Gradle version catalogs, C# dependencies are in .csproj files, and Kubernetes packaging uses Helm charts. Updating a vulnerable reused component is therefore a normal dependency-manager update, and the release notes show this process already being used for dependency bump fixes.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/server/pyproject.toml
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/pnpm-lock.yaml
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/go.mod
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/kotlin/gradle/libs.versions.toml
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/csharp/src/OpenSandbox/OpenSandbox.csproj


    Достаточно для значка!

    Проекту СЛЕДУЕТ избегать использования нерекомендуемых (deprecated) или устаревших (obsolete) функций и API в тех случаях, когда альтернативы на СПО доступны в используемом наборе технологий («стек технологий» проекта) и для подавляющего большинства пользователей, поддерживаемых проектом (т.е. так чтобы пользователи могли быстро воспользоваться этой альтернативой). [interfaces_current]

    OpenSandbox meets this because the project uses currently supported language/toolchain versions and enforces modern API usage through static analysis. Python packages require Python 3.10+ and use Ruff rules including UP/pyupgrade plus Pyright; JavaScript/TypeScript SDKs require Node 20+ and use TypeScript ESLint recommended/stylistic rules plus TypeScript typechecking; Go components run gofmt, go vet, and golangci-lint; Kubernetes lint config also blocks obsolete dependency patterns such as github.com/pkg/errors in favor of standard library errors or fmt.Errorf.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/CONTRIBUTING.md#automated-enforcement
    https://github.com/alibaba/OpenSandbox/blob/main/cli/pyproject.toml
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/eslint.base.mjs
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/.golangci.yml


  • Набор автотестов


    Достаточно для значка!

    НЕОБХОДИМО применять автоматический набор тестов к каждому коммиту в общий репозиторий по крайней мере для одной ветки. Этот набор тестов ОБЯЗАН создавать отчет об успешном или неудачном тестировании. [automated_integration_testing]
    Это требование можно рассматривать как подмножество test_continuous_integration, но сосредоточенное только на тестировании, без требования непрерывной интеграции.

    OpenSandbox meets this because GitHub Actions automatically run tests and quality checks on pull requests to main, and the SDK workflow also runs on pushes to main. The workflows run server tests, Docker smoke tests, CLI tests, Python SDK tests with JUnit and coverage reports, JavaScript SDK tests with uploaded reports, Go component tests with coverage summaries, and Kubernetes unit/E2E tests across multiple Kubernetes versions. These workflows report pass/fail status in GitHub Actions and upload test artifacts where configured.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/server-test.yml
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/sdk-tests.yml
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/execd-test.yml
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/kubernetes-test.yml


    Достаточно для значка!

    Проект ОБЯЗАН добавить регрессионные тесты к автоматизированному набору тестов по крайней мере на 50% ошибок, исправленных в течение последних шести месяцев. [regression_tests_added50]

    The project meets this criterion. The repository guidelines require focused regression tests for bug fixes and behavior changes, including server, SDK, and Kubernetes changes. Recent bug-fix commits in the last six months include corresponding automated regression tests, for example Docker host-path validation, execd SIGTERM forwarding, GPU resource limit propagation, Go SDK SSE error handling, Python SDK timeout preservation, and sandbox host-path escape hardening.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/server/AGENTS.md#guardrails
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/AGENTS.md#guardrails
    https://github.com/alibaba/OpenSandbox/commit/8aded26fa29391a258285861eaa564ef9334d3df
    https://github.com/alibaba/OpenSandbox/commit/b481aa89b9418147700e31a864585b3ca031b2f4
    https://github.com/alibaba/OpenSandbox/commit/c315d6a10d10ad174a1ae8062ae2e3126039e866
    https://github.com/alibaba/OpenSandbox/commit/0f9a162e2a8b95865bf63d84dd6067a0a2eaf23c
    https://github.com/alibaba/OpenSandbox/commit/ceb89a3d600ff8a5956b1aff71409aeae08141df
    https://github.com/alibaba/OpenSandbox/commit/4876b6eb43beda6e8fd61c22561411f354b98aa2


    Достаточно для значка!

    Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 80% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. [test_statement_coverage80]
    Для измерения тестового покрытия существует множество средств на СПО, включая gcov/lcov, Blanket.js, Istanbul и JCov. Обратите внимание, что соответствие этому критерию не является гарантией того, что тестовый пакет является исчерпывающим; вместо этого, несоответствие этому критерию является сильным индикатором плохого набора тестов.

    OpenSandbox uses FLOSS automated test suites and FLOSS coverage tools. The server test workflow runs pytest with pytest-cov/coverage.py and enforces the threshold with --cov-fail-under=80; it also publishes an XML coverage report. On the latest main commit I verified the same command locally: 975 tests passed and total statement coverage for opensandbox_server was 80.30%, satisfying the 80% requirement. Additional SDK/component workflows also collect coverage using pytest-cov and Go’s built-in go test -coverprofile.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/server-test.yml#L45-L49
    https://github.com/alibaba/OpenSandbox/blob/main/server/README.md#L258-L260
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/sdk-tests.yml#L191-L199
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/execd-test.yml#L48-L59


  • Тестирование новых функций


    Достаточно для значка!

    Проект ОБЯЗАН иметь формальную задокументированную политику о том, что при добавлении существенной новой функциональности НЕОБХОДИМО добавлять тесты для новой функциональности в набор автоматических тестов. [test_policy_mandated]

    The project meets this criterion. The repository has a written policy that behavior changes and new functionality must include tests, and the contribution flow explicitly instructs contributors to write tests for new functionality before opening a pull request. The pull request template also requires contributors to document testing and confirm that tests were added or updated when needed. These tests are run through the project's automated GitHub Actions test suites for the server, SDKs, execd, Kubernetes components, and related packages.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/AGENTS.md#guardrails
    https://github.com/alibaba/OpenSandbox/blob/main/server/README.md#contributing
    https://github.com/alibaba/OpenSandbox/blob/main/server/DEVELOPMENT.md#pull-request-process
    https://github.com/alibaba/OpenSandbox/blob/main/.github/pull_request_template.md
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/server-test.yml
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/sdk-tests.yml
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/execd-test.yml
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/kubernetes-test.yml


    Достаточно для значка!

    Проект ОБЯЗАН включать в свои документированные инструкции для предложений об изменениях политику, по которой для существенной новой функциональности должны добавляться тесты. [tests_documented_added]
    Однако даже неформальное правило приемлемо, если тесты добавляются на практике.

    The expectation to add or update tests is documented in the project's contribution and change-submission instructions. The contribution guide requires contributors to add test coverage, and the pull request template explicitly asks whether tests were added or updated.

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


  • Флаги предупреждений


    Достаточно для значка!

    Проекты ОБЯЗАНЫ быть максимально строгими с предупреждениями в ПО, создаваемом проектом, где это целесообразно. [warnings_strict]
    Некоторые предупреждения не могут быть эффективно задействованы в некоторых проектах. Что необходимо в этом критерии - это доказательства того, что проект стремится включать флаги предупреждений там, где это возможно, чтобы ошибки обнаруживались на ранней стадии.

    The project aims to be strict about warnings where practical. ESLint is configured with "--max-warnings 0", Python linting and type checking are enforced in CI with Ruff and Pyright, and Go-related checks are also automated in CI. These settings show that the project strives to keep warning-related issues from accumulating.

    Key URLs:


 Безопасность 13/13 ●

  • Знание безопасной разработки


    Достаточно для значка!

    Проект ОБЯЗАН реализовывать принципы безопасного дизайна (из критерия «know_secure_design»), где это применимо. Выберите «неприменимо» (N/A), если проект не создает программное обеспечение. [implement_secure_design]
    Например, результаты проекта должны иметь отказоустойчивые значения по умолчанию (доступ по умолчанию должен быть запрещен, а установка проектов по умолчанию должна быть в защищенной конфигурации). Также должно использоваться полное отграничение (любой доступ, который может быть ограничен, должен проверяться на достаточность прав доступа и не иметь обходных путей). Обратите внимание, что в некоторых случаях принципы будут противоречить друг другу, и в этом случае необходимо делать выбор (например, многочисленность механизмов может усложнять дизайн, противореча принципу экономичности/простоты механизма).

    The project meets this criterion. OpenSandbox implements secure design principles in multiple security-sensitive areas. The Lifecycle and Diagnostics APIs require API key authentication, sandbox gateway access can be protected with secure access tokens and signed expiring endpoints, and egress control is deny-by-default with explicit allow rules. The server validates untrusted inputs such as metadata labels, ports, mount paths, subpaths, host paths, timeouts, and allowed host path prefixes before creating runtime resources. The project also supports stronger sandbox isolation through gVisor, Kata Containers, and Firecracker-backed runtimes, and validates configured secure runtimes at startup so invalid isolation configuration fails early. The security policy documents deployment best practices, including least privilege, restricted egress, audit monitoring, and cryptographic key length requirements.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/SECURITY.md#security-best-practices
    https://github.com/alibaba/OpenSandbox/blob/main/SECURITY.md#cryptographic-key-length-policy
    https://github.com/alibaba/OpenSandbox/blob/main/specs/sandbox-lifecycle.yml
    https://github.com/alibaba/OpenSandbox/blob/main/server/opensandbox_server/middleware/auth.py
    https://github.com/alibaba/OpenSandbox/blob/main/server/opensandbox_server/services/validators.py
    https://github.com/alibaba/OpenSandbox/blob/main/components/egress/README.md
    https://github.com/alibaba/OpenSandbox/blob/main/components/egress/pkg/policy/policy.go
    https://github.com/alibaba/OpenSandbox/blob/main/docs/secure-container.md
    https://github.com/alibaba/OpenSandbox/blob/main/oseps/0011-secure-access-endpoint.md


  • Основы правильного использования криптографии

    Обратите внимание, что некоторое ПО не нуждается в использовании криптографических механизмов.

    Достаточно для значка!

    В ПО, создаваемом проектом, НЕДОПУСТИМО делать механизмы безопасности по умолчанию зависимыми от криптографических алгоритмов или режимов с известными серьезными слабостями (например, криптографический алгоритм хеширования SHA-1 или режим CBC в SSH). [crypto_weaknesses]
    Проблемы, связанные с режимом CBC в SSH, обсуждаются в описании уязвимости CERT: SSH CBC.

    OpenSandbox does not explicitly enable cryptographic algorithms or modes with known serious weaknesses such as SHA-1, RC4, DES/3DES, ECB, or CBC in its default security mechanisms. TLS-related behavior is delegated to modern standard libraries such as Go crypto/tls and controller-runtime TLS support, and the project targets Go 1.24.

    Key URLs:


    Едва достаточно для значка.

    Проекту СЛЕДУЕТ поддерживать несколько криптографических алгоритмов, чтобы пользователи могли быстро переключиться, если один из них поврежден. Общие симметричные ключевые алгоритмы включают AES, Twofish и Serpent. Общие алгоритмы контрольных сумм (хешей) включают SHA-2 (SHA-224, SHA-256, SHA-384 и SHA-512) и SHA-3. [crypto_algorithm_agility]

    OpenSandbox currently does not fully meet this SHOULD criterion. The project relies on standard cryptographic libraries and protocols where possible, including Go crypto/tls for TLS negotiation and Sigstore/OpenPGP tooling for release verification. The TLS certificate policy accepts multiple NIST-strength algorithms such as RSA, ECDSA, Ed25519, and SHA-256/SHA-384/SHA-512 based signatures. However, some project-owned mechanisms, such as OSEP-0011 route token signing and source archive checksums, currently use SHA-256 without a documented runtime switch to an alternate hash algorithm. We track this as a future hardening improvement.


    Достаточно для значка!

    Проект ОБЯЗАН поддерживать хранение данных для аутентификации (например, паролей и динамических токенов) и закрытых криптографических ключей в файлах, отдельных от остальной информации (например, файлов конфигурации, баз данных и журналов) и позволять пользователям их обновление и замену без перекомпиляции кода. Выберите «неприменимо» (N/A), если проект никогда не работает с данными аутентификации и закрытыми криптографическими ключами. [crypto_credential_agility]

    The project meets this criterion. OpenSandbox stores all authentication credentials and cryptographic keys separately from application code, in external configuration files that operators can update without code recompilation. API keys and server settings are defined in a TOML configuration file mounted via Kubernetes ConfigMap through Helm values. Route signing keys (HMAC secrets shared between the server and ingress gateway) are configured through Helm values and injected as command-line flags, not embedded in source code. Image registry credentials for snapshot push and pull operations are referenced by Kubernetes Secret name in Helm values, supporting rotation without rebuilds. Egress tokens and all other runtime credentials are supplied through environment variables defined in the egress configuration constants. All credential storage follows Kubernetes-native patterns — ConfigMaps, Secrets, environment variables, and Helm value overrides — ensuring operators can update and replace any credential at deployment time.

    Key URLs:


    Едва достаточно для значка.

    В ПО, создаваемом проектом, СЛЕДУЕТ поддерживать безопасные протоколы для всех сетевых коммуникаций, такие как SSHv2 или новее, TLS1.2 или новее (HTTPS), IPsec, SFTP и SNMPv3. По умолчанию СЛЕДУЕТ отключать небезопасные протоколы, такие как FTP, HTTP, telnet, SSLv3 или более ранние версии, и SSHv1, и разрешать их только в том случае, если пользователь явным образом это задаёт. Если программное обеспечение, созданное проектом, не поддерживает сетевые коммуникации, выберите «неприменимо» (N/A). [crypto_used_network]

    OpenSandbox does not fully meet this SHOULD criterion yet. The project supports secure deployments and HTTPS-capable clients, and some Kubernetes controller endpoints use TLS, but HTTP is still the default for local server/CLI usage and some internal component communication. We track this as future hardening to make secure protocols the default for externally exposed communication.


    Достаточно для значка!

    Если ПО, создаваемое проектом, поддерживает или использует TLS, ему СЛЕДУЕТ поддерживать как минимум версию TLS 1.2. Примечание: предшественник TLS называется SSL. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_tls12]

    OpenSandbox supports TLS 1.2 or later where project-owned TLS configuration is used. The Go SDK default HTTP transport sets tls.Config MinVersion to tls.VersionTLS12, and the Kubernetes controller applies TLS options with MinVersion set to tls.VersionTLS12 for webhook/metrics serving paths.


    Достаточно для значка!

    В ПО, создаваемом проектом, НЕОБХОДИМО выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_certificate_verification]
    Обратите внимание, что неправильная проверка сертификата TLS является распространенной ошибкой. Для дальнейших сведений см. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" Мартина Георгиева и др. и "Do you trust this application?" Майкла Катанзаро.

    The project meets this criterion. When OpenSandbox clients use HTTPS/TLS endpoints, TLS certificate verification is enabled by default. The Go SDK creates a default HTTP transport with TLS 1.2 minimum and certificate-chain verification, and additionally enforces NIST minimum certificate key/hash strength unless explicitly overridden for legacy interoperability. The Python SDK generated clients use httpx with verify_ssl=True by default. The JavaScript SDK uses the platform fetch/undici transport without disabling TLS verification. The C# SDK uses the standard HttpClientHandler without a custom certificate validation bypass. No default client configuration disables certificate validation.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/SECURITY.md#cryptographic-key-length-policy
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/go/transport.go
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/go/crypto_policy.go
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/python/src/opensandbox/api/lifecycle/client.py
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/javascript/src/config/connection.ts
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/csharp/src/OpenSandbox/Config/ConnectionConfig.cs


    Достаточно для значка!

    В ПО, создаваемом проектом, НЕОБХОДИМО, если поддерживается TLS, выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_verification_private]

    The project meets this criterion. Private HTTP headers such as OPEN-SANDBOX-API-KEY, OpenSandbox secure access headers, and OPENSANDBOX-EGRESS-AUTH are sent through the project SDKs using standard HTTPS/TLS client stacks that verify server certificates before transmitting HTTP request headers. The Go SDK uses its default verified TLS transport before sending API key headers, Python uses httpx with certificate verification enabled by default, JavaScript uses fetch/undici defaults, and C# uses the default HttpClientHandler certificate validation. Thus, when TLS is used, certificate verification occurs before private authentication headers are sent.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/specs/sandbox-lifecycle.yml
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/go/http.go
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/go/egress.go
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/python/src/opensandbox/adapters/sandboxes_adapter.py
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/javascript/src/config/connection.ts
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/csharp/src/OpenSandbox/Config/ConnectionConfig.cs


  • Безопасный выпуск


    Достаточно для значка!

    Проект ОБЯЗАН криптографически подписывать выпуски результатов проекта, предназначенные для широкого использования, и ОБЯЗАН иметь задокументированный процесс, объясняющий пользователям, как они могут получить общедоступные ключи подписи и проверить подпись(и) выпусков. НЕДОПУСТИМО размещать закрытый ключ для этих подписей на сайте(сайтах), используемом для прямого распространения ПО для общественности. Выберите «неприменимо» (N/A), если выпуски не предназначены для широкого использования. [signed_releases]
    Результаты проекта включают как исходный код, так и любые сгенерированные результаты, если это применимо (например, исполняемые файлы, пакеты и контейнеры). Сгенерированные результаты МОГУТ быть подписаны отдельно от исходного кода. Подписывание МОЖЕТ быть реализовано как подписанные теги git (с использованием криптографических цифровых подписей). Проекты МОГУТ предоставлять генерируемые результаты отдельно от таких инструментов, как git, но в этих случаях отдельные результаты ОБЯЗАНЫ быть отдельно подписаны.

    OpenSandbox signs public release outputs using the current release workflows. Source archives and checksum files are attested with GitHub/Sigstore attestations; container images are signed by cosign keyless signing and attested in registries; Python, CLI, JavaScript, C#, and Helm release artifacts are attested before publication; Java/Kotlin Maven artifacts are signed through Gradle/Maven Central signing. The project documents the trust roots, signer workflow identities, and user verification commands in the Release Verification guide. Most signatures are keyless Sigstore signatures backed by GitHub Actions OIDC, so there is no long-lived private key or downloadable project public key for those signatures; Maven signing keys are held only in GitHub Actions secrets.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/docs/release-verification.md
    https://github.com/alibaba/OpenSandbox/blob/main/SECURITY.md#release-signatures
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/release-generic.yml
    https://github.com/alibaba/OpenSandbox/blob/main/.github/workflows/publish-components.yml


    Едва достаточно для значка.

    ЖЕЛАТЕЛЬНО, чтобы в системе контроля версий каждый важный тег версии (тег, который является частью основного выпуска, минорной версии или исправляет общедоступные уязвимости) подписывался криптографической подписью и поддавался проверке, как описано в критерииsigned_releases. [version_tags_signed]

    OpenSandbox does not currently meet this suggested criterion. The release script supports optional signed tags via scripts/release/create-release.sh --sign-tag for release operators with local git signing configured, but signed tags are not required by the hosted release workflow and existing release tags are not consistently cryptographically signed or verifiable. Official release artifacts are instead signed and attested through the documented Sigstore/GitHub attestation and package signing workflows.


  • Другие вопросы безопасности


    Достаточно для значка!

    В результатах проекта НЕОБХОДИМО проверять любой ввод из потенциально ненадежных источников, чтобы убедиться, что они действительны (*белый список*), и отклонять недействительный ввод, если вообще есть какие-либо ограничения на данные. [input_validation]
    Обратите внимание, что сравнения ввода со списком «плохих форматов» (также известным как *черный список*) обычно недостаточно, потому что злоумышленники часто могут обойти черный список. В частности, числа преобразуются во внутренние форматы, а затем проверяются, находятся ли они между их минимальным и максимальным (включительно), а текстовые строки проверяются, чтобы убедиться, что они являются допустимыми текстовыми шаблонами (например, действительный UTF-8, длина, синтаксис и т. д.). От некоторых данных может требоваться, чтобы они были «хоть чем-нибудь» (например, загрузчик файлов), но такое обычно случается редко.

    OpenSandbox validates untrusted input at multiple boundaries: public OpenAPI contracts define required fields, enums, numeric ranges, string patterns, and additionalProperties: false for many schemas. The lifecycle server maps these contracts to FastAPI/Pydantic request models, so request bodies and query parameters are type-checked before service logic runs. Additional service validators reject unsupported platforms, invalid metadata labels/reserved prefixes, invalid ports/timeouts, path traversal, non-normalized or non-allowlisted host paths, invalid volume/PVC names, invalid OSSFS options, and out-of-range extension values. The egress sidecar also parses network policies into typed rules and rejects unsupported actions or empty targets. These validations are covered by focused positive and negative tests.

    Key URLs:
    https://github.com/alibaba/OpenSandbox/blob/main/specs/sandbox-lifecycle.yml
    https://github.com/alibaba/OpenSandbox/blob/main/server/opensandbox_server/api/schema.py
    https://github.com/alibaba/OpenSandbox/blob/main/server/opensandbox_server/services/validators.py
    https://github.com/alibaba/OpenSandbox/blob/main/server/tests/test_validators.py
    https://github.com/alibaba/OpenSandbox/blob/main/components/egress/pkg/policy/policy.go


    Достаточно для значка!

    В ПО, создаваемом проектом, СЛЕДУЕТ использовать механизмы упрочнения безопасности (hardening), чтобы дефекты программного обеспечения с меньшей вероятностью приводили к уязвимостям в безопасности. [hardening]
    Механизмы упрочнения могут включать HTTP-заголовки, такие как Content Security Policy (CSP), флаги компилятора для противостояния атакам (например, -fstack-protector) или флаги компилятора, устраняющие неопределенное поведение. Для наших целей политика наименьших привилегий не считается механизмом упрочнения (использовать наименьшие достаточные привилегии важно, но этому посвящён отдельный критерий).

    OpenSandbox uses hardening mechanisms beyond ordinary functional checks. First-party code is primarily Go, Python, TypeScript, Kotlin, and C#, with no checked-in first-party C/C++/Rust source found outside dependency/venv directories; the Go binaries are built with CGO disabled by default where practical, reducing native memory-unsafe surface. CI and project configs run static and semantic checks such as go vet, golangci-lint, gosec, staticcheck, Ruff, Pyright, and tests. Runtime hardening is also configured: Docker sandboxes support no-new-privileges, dropped dangerous capabilities, PID limits, optional seccomp/AppArmor, and Kubernetes manifests/charts use restricted Pod Security settings such as runAsNonRoot, RuntimeDefault seccomp, allowPrivilegeEscalation: false, and dropped capabilities. Access paths are additionally hardened with API-key middleware, random endpoint tokens, and signed route tokens with expiry validation.

    Key URLs:

    https://github.com/alibaba/OpenSandbox/blob/main/components/execd/Makefile
    https://github.com/alibaba/OpenSandbox/blob/main/components/execd/.golangci.yml
    https://github.com/alibaba/OpenSandbox/blob/main/server/opensandbox_server/examples/example.config.toml
    https://github.com/alibaba/OpenSandbox/blob/main/server/opensandbox_server/services/docker.py
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/config/manager/manager.yaml
    https://github.com/alibaba/OpenSandbox/blob/main/server/opensandbox_server/middleware/auth.py
    https://github.com/alibaba/OpenSandbox/blob/main/components/ingress/pkg/signature/signature.go


    Достаточно для значка!

    Проект ОБЯЗАН предоставить обоснование того, что требования безопасности соблюдаются проектом. В обоснование НЕОБХОДИМО включить: описание модели угроз, четкое указание границ доверия, доказательство того, что использовались принципы безопасного дизайна, и доказательство того, что слабости в безопасности реализации нейтрализованы. (Требуется URL) [assurance_case]
    Обоснованием является «документальное подтверждение, которое дает убедительное и корректное доказательство того, что указанный набор критических заявлений относительно свойств системы адекватно оправдан для данного приложения в данной среде» (перевод выдержки из "Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Границы доверия - это границы, на которых меняется уровень доверия к данным или выполнению кода, например границы сервера в типичном веб-приложении. В обосновании обычно перечисляются принципы безопасного проектирования (такие как Saltzer and Schroeer) и общие слабости безопасности в реализации (такие как OWASP Top 10 или CWE/SANS Top 25), и показывается, как противодействовать каждой из них. Полезным примером может служить обоснование для BadgeApp. Этот критерий связан с documentation_security, documentation_architecture и implement_secure_design.

    OpenSandbox provides its assurance case through documented security policy, architecture, and design proposals. The threat model is centered on executing untrusted AI-generated or user-provided code in sandbox instances, with risks such as container escape, cross-tenant impact, uncontrolled network egress, unauthorized endpoint access, and resource abuse. The architecture documentation identifies trust boundaries between SDK/client code, the lifecycle server, runtime backends, sandbox containers, the injected execd daemon, ingress, and egress sidecars. Secure design principles are applied through protocol-first APIs, API-key and token-based access control, signed endpoint routes with expiry, sandbox isolation, optional secure runtimes such as gVisor/Kata/Firecracker, resource limits, egress allow/deny policy enforcement, and separation of privileged network-control logic into a sidecar instead of the application container. Common implementation weaknesses are countered through schema/input validation, bounded port/time parsing, path traversal rejection, signed-token validation, capability dropping, no-new-privileges/seccomp/AppArmor support, and CI checks/tests.

    Key URLs:

    https://github.com/alibaba/OpenSandbox/blob/main/SECURITY.md
    https://github.com/alibaba/OpenSandbox/blob/main/docs/architecture.md
    https://github.com/alibaba/OpenSandbox/blob/main/docs/secure-container.md
    https://github.com/alibaba/OpenSandbox/blob/main/oseps/0004-secure-container-runtime.md
    https://github.com/alibaba/OpenSandbox/blob/main/oseps/0001-fqdn-based-egress-control.md
    https://github.com/alibaba/OpenSandbox/blob/main/oseps/0011-secure-access-endpoint.md
    https://github.com/alibaba/OpenSandbox/blob/main/server/opensandbox_server/services/validators.py
    https://github.com/alibaba/OpenSandbox/blob/main/components/ingress/pkg/signature/signature.go


 Анализ 2/2 ●

  • Статический анализ кода


    Достаточно для значка!

    Проект ОБЯЗАН использовать хотя бы один инструмент статического анализа с правилами или подходами для поиска распространенных уязвимостей в анализируемом языке или окружении, если есть хотя бы один инструмент на СПО, который может реализовать этот критерий на выбранном языке. [static_analysis_common_vulnerabilities]
    Инструменты статического анализа, специально предназначенные для поиска распространенных уязвимостей, с большей вероятностью найдут их. Тем не менее, использование любых статических инструментов обычно помогает найти какие-то проблемы, поэтому мы предлагаем, но не требуем этого для получения базового значка.

    The project uses GitHub CodeQL code scanning, which includes rules for common vulnerability classes. Historical CodeQL findings in this repository include security-focused rules such as path injection, command injection, clear-text storage of sensitive data, workflow permission issues, URL sanitization, and socket binding concerns.

    Key URL:


  • Динамический анализ кода


    Достаточно для значка!

    Если ПО, создаваемое проектом, включает ПО, написанное с использованием небезопасного языка (например, C или C++), тогда проект ОБЯЗАН регулярно использовать хотя бы один динамический инструмент (например, фаззер или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера. Выберите «неприменимо» (N/A), если проект не создает ПО, написанное на небезопасном языке. [dynamic_analysis_unsafe]
    Примерами механизмов обнаружения проблем безопасности памяти являются Address Sanitizer (ASAN) (доступен в GCC и LLVM), Memory Sanitizer и valgrind. Другие потенциально используемые инструменты включают Thread Sanitizer и Undefined Behavior Sanitizer. Достаточно широкое использование утверждений (assertions) тоже может быть приемлемо.

    OpenSandbox does not produce first-party software written in memory-unsafe implementation languages such as C or C++. I verified the repository source tree excluding dependency/build directories (.venv, node_modules, vendor, bin) and found no first-party C/C++/Objective-C/Rust source files. The project code is implemented in memory-safe or runtime-managed languages: Go for server-side components/controllers, Python for the lifecycle server/CLI/SDKs, TypeScript/JavaScript for SDKs/docs/tests, Kotlin/Java for JVM SDKs/tests, and C# for .NET SDKs/tests. Therefore the requirement to routinely use dynamic memory-safety tools such as ASAN, MSAN, valgrind, or fuzzers for memory-unsafe project code is not applicable.

    Key URLs:

    https://github.com/alibaba/OpenSandbox/blob/main/components/execd/go.mod
    https://github.com/alibaba/OpenSandbox/blob/main/components/egress/go.mod
    https://github.com/alibaba/OpenSandbox/blob/main/kubernetes/go.mod
    https://github.com/alibaba/OpenSandbox/blob/main/server/pyproject.toml
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/package.json
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/kotlin/build.gradle.kts
    https://github.com/alibaba/OpenSandbox/blob/main/sdks/sandbox/csharp/src/OpenSandbox/OpenSandbox.csproj



Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Sky и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Sky.
2026-04-19 13:16:25 UTC, последнее изменение сделано 2026-05-03 01:01:44 UTC. Последний раз условия для получения значка были выполнены 2026-04-26 14:38:05 UTC.