in-toto

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

Если это ваш проект, пожалуйста, покажите свой значок на странице проекта! Статус значка выглядит следующим образом: Уровень значка для проекта 1523 - gold Вот как вставить его:

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

        

 Основы 5/5

  • Идентификация

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

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


    Проект ОБЯЗАН получить серебряный значок. [achieve_silver]

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


    Проект ОБЯЗАН иметь «коэффициент автобуса» 2 или более. (Требуется URL) [bus_factor]

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



    Проект ОБЯЗАН иметь как минимум двух несвязанных значительных соавторов. (Требуется URL) [contributors_unassociated]

    The in-toto project is primarily a specification but also maintains several implementations. As the Python reference implementation is spec-complete and has reached the 1.0 stability milestone, activity is primarily visible on the specification, its enhancement proposals, and other implementations. in-toto has a robust community within the CNCF and receives contributions from a variety of industry adopters and academics, most of whom are not directly affiliated with the project.

    in-toto PRs authors (Repository group: All, Range: Last year): https://intoto.devstats.cncf.io/d/22/prs-authors-table?orgId=1&var-period_name=Last%20year&var-repogroup_name=All

    in-toto PRs authors companies** (Repository group: All, Range: Last year): https://intoto.devstats.cncf.io/d/21/prs-authors-companies-table?orgId=1&var-period_name=Last%20year&var-repogroup_name=All

    **might include some false mappings


  • Другое


    Проект ОБЯЗАН указывать лицензию в каждом исходном файле. Это МОЖЕТ быть сделано путем включения в комментарий рядом с началом каждого файла следующей строки: SPDX-License-Identifier: [SPDX-выражение лицензии для проекта]. [license_per_file]

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

    # SPDX-License-Identifier: Apache-2.0


  • Публичное хранилище исходного кода с поддержкой версий


    Хранилище проектного исходного кода ОБЯЗАНО использовать типовое ПО для распределенного управления версиями (например, git или mercurial). [repo_distributed]

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



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

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



    Проект ОБЯЗАН требовать двухфакторной аутентификации (ДФА) от разработчиков для изменения центрального хранилища или доступа к конфиденциальным данным (например, приватным отчетам об уязвимостях). Этот механизм ДФА МОЖЕТ использовать механизмы без криптографической защиты, такие как SMS, хотя это не рекомендуется. [require_2FA]

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



    При двухфакторной аутентификации (ДФА) проекту СЛЕДУЕТ использовать криптографические механизмы для предотвращения имперсонации. ДФА на основе службы коротких сообщений (SMS) сама по себе НЕ соответствует этому критерию, поскольку короткие сообщения не шифруются. [secure_2FA]

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


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


    Проект ОБЯЗАН документировать свои требования по ревью кода, в том числе, как проводится ревью кода, что необходимо проверять и что необходимо для приемлемости кода. (Требуется URL) [code_review_standards]

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

    All pull requests must be reviewed by one or more maintainers before they are merged.

    https://github.com/in-toto/in-toto/blob/develop/GOVERNANCE.md#contributions


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


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

    The project is implemented in a scripting language where the source code is used directly.


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


    Набор тестов ОБЯЗАН запускаться стандартным способом для этого языка. (Требуется URL) [test_invocation]

    The project's tests are written using Python's standard unittest module. The test suite also uses tox, a popular way of invoking a project's test suite.

    https://github.com/in-toto/in-toto/blob/v1.0.0/tests/runtests.py https://github.com/in-toto/in-toto/blob/v1.0.0/tox.ini



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

    The project implements continuous integration using GitHub Actions, running tests on Linux, macOS and MS Windows.

    https://github.com/in-toto/in-toto/actions https://github.com/in-toto/in-toto/tree/develop/.github/workflows



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

    The project uses FLOSS tools coverage, unittest from the Python standard library, and tox to run automated tests on GitHub Pull Requests and to measure test coverage. It currently reaches 100% combined statement and branch coverage.

    Project-specific configuration: https://github.com/in-toto/in-toto/blob/develop/.github/workflows/ci.yml#L52 https://github.com/in-toto/in-toto/blob/develop/tox.ini#L19 https://github.com/in-toto/in-toto/blob/develop/.coveragerc#L2

    FLOSS tools https://tox.wiki/en/latest/index.html https://docs.python.org/3/library/unittest.html https://coverage.readthedocs.io/



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

    The project uses FLOSS tools coverage, unittest from the Python standard library, and tox to run automated tests on GitHub Pull Requests and to measure test coverage. It currently reaches 100% combined statement and branch coverage.

    Project-specific configuration: https://github.com/in-toto/in-toto/blob/develop/.github/workflows/ci.yml#L52 https://github.com/in-toto/in-toto/blob/develop/tox.ini#L19 https://github.com/in-toto/in-toto/blob/develop/.coveragerc#L2

    FLOSS tools https://tox.wiki/en/latest/index.html https://docs.python.org/3/library/unittest.html https://coverage.readthedocs.io/


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

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

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

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



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

    The software produced by the project does not use TLS.


  • Доставка, защищенная от атак посредника (MITM)


    Веб-сайт проекта, репозиторий (если он доступен через Интернет) и сайт загрузки (если он существует отдельно) ОБЯЗАНЫ использовать упрочняющие безопасность (hardening) заголовки с неразрешающими значениями. (Требуется URL) [hardened_site]

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


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


    Проект ОБЯЗАН иметь проверку безопасности за последние 5 лет. При проверке НЕОБХОДИМО учитывать требования и границы безопасности. [security_review]

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



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

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

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


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


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

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

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



    Проекту СЛЕДУЕТ включать достаточно много утверждений (assertions) времени выполнения в создаваемом им ПО и проверять эти утверждения во время динамического анализа. [dynamic_analysis_enable_assertions]

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

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



Эти данные доступны под лицензией Creative Commons Attribution версии 3.0 или более поздней (CC-BY-3.0+). Все могут свободно делиться и адаптировать эти данные, но должны указывать соответствующие ссылки. При распространении, пожалуйста, указывайте "Lukas Puehringer and the OpenSSF Best Practices badge contributors".

Владелец анкеты на значок проекта: Lukas Puehringer.
2018-01-03 16:15:50 UTC, последнее изменение сделано 2022-11-02 15:08:49 UTC. Последний раз условия для получения значка были выполнены 2018-01-05 21:31:54 UTC.

Назад