Критерии лучших практик FLOSS (золотой значок)

Это набор лучших практик для проектов свободного и открытого ПО (Free/Libre and Open Source Software - FLOSS) для получения значка "Передовая практика Open Source Security Foundation (OpenSSF)" уровня gold. Вы можете показать этот список с только критериями или с дополнительной информацией. Также доступен полный набор критериев.

См. обсуждение критериев для получения более подробной информации об этих критериях.

Gold

Основы

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

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

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

Проект ОБЯЗАН иметь «коэффициент автобуса» 2 или более. {Требуется URL выполнения} ^[bus_factor]
Проект ОБЯЗАН иметь как минимум двух несвязанных значительных соавторов. {Требуется URL выполнения} ^{[contributors_unassociated]}

Другое

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

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

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

Хранилище проектного исходного кода ОБЯЗАНО использовать типовое ПО для распределенного управления версиями (например, git или mercurial). {Требуется обоснование выполнения} ^{[repo_distributed]}
Проект ОБЯЗАН четко обозначать небольшие задачи, которые могут быть выполнены новыми или случайными участниками. {Требуется URL выполнения} ^{[small_tasks]}
Проект ОБЯЗАН требовать двухфакторной аутентификации (ДФА) от разработчиков для изменения центрального хранилища или доступа к конфиденциальным данным (например, приватным отчетам об уязвимостях). Этот механизм ДФА МОЖЕТ использовать механизмы без криптографической защиты, такие как SMS, хотя это не рекомендуется. {Требуется обоснование выполнения} ^{[require_2FA]}
При двухфакторной аутентификации (ДФА) проекту СЛЕДУЕТ использовать криптографические механизмы для предотвращения имперсонации. ДФА на основе службы коротких сообщений (SMS) сама по себе НЕ соответствует этому критерию, поскольку короткие сообщения не шифруются. {Требуется обоснование выполнения} ^[secure_2FA]

Качество

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

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

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

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

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

Набор тестов ОБЯЗАН запускаться стандартным способом для этого языка. {Требуется URL выполнения} ^{[test_invocation]}
Проект ОБЯЗАН реализовать непрерывную интеграцию, при которой новый или измененный код интегрируется в центральное хранилище кода, и на получившейся базе кода запускаются автоматические тесты. {Требуется URL выполнения} ^{[test_continuous_integration]}
Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 90% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. {Требуется обоснование N/A} {Требуется обоснование выполнения} ^{[test_statement_coverage90]}
Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 80% веток кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. {Требуется обоснование N/A} {Требуется обоснование выполнения} ^{[test_branch_coverage80]}

Безопасность

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

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

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

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

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

Проект ОБЯЗАН иметь проверку безопасности за последние 5 лет. При проверке НЕОБХОДИМО учитывать требования и границы безопасности. {Требуется обоснование выполнения} ^{[security_review]}
В ПО, создаваемом проектом, НЕОБХОДИМО использовать механизмы упрочнения безопасности (hardening), чтобы дефекты программного обеспечения с меньшей вероятностью приводили к уязвимостям в безопасности. {Требуется обоснование N/A} {Требуется URL выполнения} ^[hardening]

Анализ

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

Проект ОБЯЗАН применять хотя бы один инструмент динамического анализа к любой предлагаемой основной версии ПО, создаваемого проектом до её выпуска. {Требуется обоснование N/A} {Требуется обоснование выполнения} ^{[dynamic_analysis]}
Проекту СЛЕДУЕТ включать достаточно много утверждений (assertions) времени выполнения в создаваемом им ПО и проверять эти утверждения во время динамического анализа. {Требуется обоснование N/A} {Требуется обоснование выполнения} ^{[dynamic_analysis_enable_assertions]}