FLOSS Best Practices Criteria (All Levels)

This is the set of best practices for Free/Libre and Open Source Software (FLOSS) projects to achieve the Open Source Security Foundation (OpenSSF) Best Practices badges at the passing, silver, and gold badge levels. You can show this list with just the criteria or with additional information. You may also view just the passing, silver, and gold criteria, as well as criteria statistics.

See criteria discussion for more information about these criteria.

Passing

Основы

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

Веб-сайт проекта ОБЯЗАН кратко описывать, что делает программное обеспечение (какую проблему решает?). ^{[description_good]}
Веб-сайт проекта ОБЯЗАН предоставлять информацию о том, как: получать и предоставлять обратную связь (например, отчеты об ошибках или улучшения) и вносить свой вклад в программное обеспечение. ^[interact]
В описании того, как сделать вклад, НЕОБХОДИМО объяснить процесс внесения вклада (например, используются ли pull request'ы). {Met URL} ^{[contribution]}
В информацию о том, как внести вклад, СЛЕДУЕТ включать требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). {Met URL} ^{[contribution_requirements]}

Свободная лицензия

ПО, создаваемое проектом, ОБЯЗАНО быть выпущено под свободной лицензией. ^{[floss_license]}
ЖЕЛАТЕЛЬНО, чтобы все лицензии для ПО, создаваемого проектом, были одобрены Open Source Initiative (OSI). ^{[floss_license_osi]}
Проект ОБЯЗАН публиковать лицензию или лицензии своих результатов в стандартном расположении в своем репозитории исходного кода. {Met URL} ^{[license_location]}

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

Проект ОБЯЗАН предоставлять базовую документацию для программного обеспечения, создаваемого проектом. {N/A justification} ^{[documentation_basics]}
Проект ОБЯЗАН предоставлять справочную документацию, описывающую внешний интерфейс (как входной, так и выходной) программного обеспечения, создаваемого проектом. {N/A justification} ^{[documentation_interface]}

Другое

Сайты проекта (веб-сайт, репозиторий и URL-адреса для загрузки) ОБЯЗАНЫ поддерживать HTTPS с использованием TLS. ^{[sites_https]}
Проект ОБЯЗАН иметь один или несколько механизмов для обсуждения (включая предлагаемые изменения и проблемы), которые доступны для поиска, позволяют ссылаться на сообщения и темы по URL, позволяют новым людям участвовать в некоторых обсуждениях и не требуют установки на стороне клиента проприетарного программного обеспечения. ^[discussion]
Проекту СЛЕДУЕТ предоставлять документацию на английском языке и иметь возможность принимать отчеты об ошибках и комментарии о коде на английском языке. ^[english]
НЕОБХОДИМО, чтобы проект поддерживался. ^[maintained]

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

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

Проект ОБЯЗАН иметь репозиторий (хранилище) исходного кода с управлением версиями, который является общедоступным и имеет URL. ^{[repo_public]}
Проектный репозиторий исходного кода ОБЯЗАН отслеживать, какие изменения были внесены, кто внес изменения и когда изменения были сделаны. ^[repo_track]
Чтобы обеспечить возможность для проверки другими участниками, проектный репозиторий исходного кода ОБЯЗАН включать промежуточные версии для проверки между релизами; НЕДОПУСТИМО хранить в репозитории лишь финальные версии. ^{[repo_interim]}
Для хранилища проектного исходного кода ЖЕЛАТЕЛЬНО использовать типовое ПО для распределенного управления версиями (например, git). ^{[repo_distributed]}

Уникальная нумерация версий

Результаты проекта ОБЯЗАНЫ иметь уникальный идентификатор версии для каждой версии, предназначенной для конечных пользователей. ^{[version_unique]}
Для выпусков ЖЕЛАТЕЛЬНО использовать семантическую либо календарную нумерацию версий. При использовании календарной нумерации к версии ЖЕЛАТЕЛЬНО добавлять микро-компоненту. ^{[version_semver]}
Проектам ЖЕЛАТЕЛЬНО идентифицировать каждый выпуск в своей системе управления версиями. Например, при использовании git ЖЕЛАТЕЛЬНО идентифицировать каждую версию, используя теги git. ^{[version_tags]}

Примечания к выпуску

Проект ОБЯЗАН предоставлять с каждой выпускаемой версией замечания к выпуску - удобочитаемые человеком сведения об основных изменениях в этом выпуске, помогающие пользователям определить, должны ли они обновляться и какими будут последствия обновления. НЕДОПУСТИМО делать замечания к выпуску сырым выводом журнала управления версиями (например, результаты команды «git log» не являются замечаниями к выпуску). Проекты, результаты которых не предназначены для повторного использования в нескольких местах (например, программное обеспечение для одного веб-сайта или службы) И выдаются через непрерывную доставку (continuous delivery) МОГУТ выбрать «неприменимо» (N/A). {N/A justification} {Met URL} ^{[release_notes]}
В замечаниях о выпуске НЕОБХОДИМО упоминать каждую общеизвестную уязвимость, исправленную в каждой новой версии, для которой существует CVE или аналогичная публичная запись. Критерий может быть отмечен как неприменимый (N/A), если у пользователей обычно нет практической возможности обновить данное ПО самостоятельно (это часто относится к, например, обновлениям ядра операционной системы). Если замечаний о выпуске не публиковалось или не было обнародованных уязвимостей, отвечайте "неприменимо". {N/A justification} ^{[release_notes_vulns]}

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

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

Проект ОБЯЗАН предоставить пользователям возможность отправлять сообщения об ошибках (например, используя систему отслеживания ошибок или список рассылки). {Met URL} ^{[report_process]}
СЛЕДУЕТ использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. ^{[report_tracker]}
Проект ОБЯЗАН подтверждать получение большинства сообщений об ошибках, отправленных за последние 2-12 месяцев (включительно); подтверждение не обязательно включает исправление. ^{[report_responses]}
Проекту СЛЕДУЕТ реагировать на большинство (>50%) запросов на улучшения в течение последних 2-12 месяцев (включительно). ^{[enhancement_responses]}
Проект ОБЯЗАН иметь общедоступный архив для отчетов и ответов для последующего поиска. {Met URL} ^{[report_archive]}

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

Проект ОБЯЗАН публиковать процесс уведомления об уязвимостях на сайте проекта. {Met URL} ^{[vulnerability_report_process]}
Если поддерживаются приватные отчеты об уязвимости, проект ОБЯЗАН включить описание того, как отправлять сведения конфиденциальным способом. {N/A allowed} {Met URL} ^{[vulnerability_report_private]}
Проект ОБЯЗАН обеспечивать время первоначального отклика на любой отчет об уязвимости, полученный за последние 6 месяцев, в пределах 14 дней или меньше. {N/A allowed} ^{[vulnerability_report_response]}

Качество

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

Если программное обеспечение, создаваемое проектом, требует сборки для использования, проект ОБЯЗАН предоставить рабочую систему сборки, которая может автоматически пересобирать программное обеспечение из исходного кода. {N/A allowed} ^[build]
ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. {N/A allowed} ^{[build_common_tools]}
Для сборки проекта СЛЕДУЕТ использовать только инструменты со свободными лицензиями. {N/A allowed} ^{[build_floss_tools]}

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

Проект ОБЯЗАН использовать по крайней мере один автоматизированный набор тестов, опубликованный как свободное ПО (этот набор тестов может поддерживаться как отдельный проект свободного ПО). Проект ОБЯЗАН ясно показывать или иметь документацию о том, как запускать наборы тестов (например, через непрерывную интеграцию (CI) или используя файлы документации, такие как BUILD.md, README.md или CONTRIBUTING.md). ^[test]
Запуск набора тестов СЛЕДУЕТ реализовывать стандартным способом для этого языка. ^{[test_invocation]}
ЖЕЛАТЕЛЬНО охватывать набором тестов большинство (а в идеале все) ветви кода, поля ввода и функциональные возможности. ^[test_most]
ЖЕЛАТЕЛЬНО реализовать непрерывную интеграцию (Continuous Integration - частая интеграция нового или измененного кода в центральное хранилище кода, и запуск автоматических тестов на получившейся базе кода). ^{[test_continuous_integration]}

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

Проект ОБЯЗАН иметь общую политику (формальную или нет), обязывающую добавлять тесты в набор автоматических тестов по мере добавления новых функциональных возможностей к программному обеспечению, создаваемому проектом. ^{[test_policy]}
Проект ОБЯЗАН иметь доказательства того, что критерий test_policy о добавлении тестов соблюдался при недавних крупных изменениях ПО, создаваемого проектом. ^{[tests_are_added]}
ЖЕЛАТЕЛЬНО задокументировать эту политику добавления тестов (см. критерий test_policy) в инструкции к предложениям об изменениях. ^{[tests_documented_added]}

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

Проект ОБЯЗАН включать один или несколько предупреждающих флагов компилятора, «безопасный» языковой режим или использовать отдельный инструмент «linter» для поиска ошибок качества кода или типовых простых ошибок, если есть хотя бы один инструмент на свободном ПО, который может реализовать этот критерий на выбранном языке. {N/A allowed} ^[warnings]
Проект ОБЯЗАН обращать внимание на предупреждения. {N/A allowed} ^{[warnings_fixed]}
ЖЕЛАТЕЛЬНО, чтобы проекты использовали самый строгий режим предупреждений в производимом ПО, где это целесообразно. {N/A allowed} ^{[warnings_strict]}

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

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

По крайней мере один основной разработчик на проекте ОБЯЗАН знать, как проектировать безопасное программное обеспечение (точные требования описаны в подробностях к критерию). ^{[know_secure_design]}
По крайней мере, один из основных разработчиков проекта ОБЯЗАН знать об общих видах ошибок, которые приводят к уязвимостям в этом виде программного обеспечения, а также по крайней мере одному методу противодействия или смягчения каждого из них. ^{[know_common_errors]}

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

Программное обеспечение, созданное проектом, ОБЯЗАНО использовать по умолчанию только публикуемые криптографические протоколы и алгоритмы, которые анализируются экспертами (если используются криптографические протоколы и алгоритмы). {N/A allowed} ^{[crypto_published]}
Если программное обеспечение, создаваемое проектом, является приложением или библиотекой, и его основной целью является не внедрение криптографии, тогда для реализации криптографических функций СЛЕДУЕТ обращаться к программному обеспечению, специально предназначенному для этого; НЕ СЛЕДУЕТ повторно реализовывать свои собственные функции. {N/A allowed} ^{[crypto_call]}
Вся функциональность программного обеспечения, создаваемого проектом, которая зависит от криптографии, ОБЯЗАНА быть реализована с использованием свободного ПО. {N/A allowed} ^{[crypto_floss]}
Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ использовать стандартные длины криптографических ключей, которые, по крайней мере, соответствуют минимальным требованиям NIST до 2030 года (как указано в 2012 году). Проект ОБЯЗАН предоставлять возможность настройки ПО таким образом, чтобы уменьшенные длины ключей были полностью отключены. {N/A allowed} ^{[crypto_keylength]}
Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕДОПУСТИМО делать зависимыми от взломанных криптографических алгоритмов (например, MD4, MD5, single DES, RC4, Dual_EC_DRBG) или использовать режимы шифрования, которые не подходят для контекста, если только они не требуются для интероперабельности протокола (поддерживающего самую новую версию стандарта на этот протокол, широко распространенного в сетевой экосистеме, причем эта экосистема требует использования данного алгоритма или режима, не предлагая более безопасных альтернатив). В документации НЕОБХОДИМО описать все связанные с этим риски безопасности и все известные способы смягчения рисков, если данные алгоритмы или режимы действительно нужны для совместимости с другими реализациями этого протокола. {N/A allowed} ^{[crypto_working]}
Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕ СЛЕДУЕТ делать зависимыми от криптографических алгоритмов или режимов с известными серьезными слабостями (например, криптографический алгоритм хеширования SHA-1 или режим CBC в SSH). {N/A allowed} ^{[crypto_weaknesses]}
В механизмах безопасности в программном обеспечении, создаваемом проектом, СЛЕДУЕТ реализовать совершенную прямую секретность для протоколов соглашений о ключах, чтобы ключ сеанса, произведенный из набора долгосрочных ключей, не мог быть скомпрометирован, если один из долгосрочных ключей скомпрометирован в будущем. {N/A allowed} ^[crypto_pfs]
Если ПО, создаваемое проектом, требует хранить пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с солью для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, PBKDF2, Bcrypt или Scrypt). См. также: OWASP Password Storage Cheat Sheet (на англ.). {N/A allowed} ^{[crypto_password_storage]}
Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ генерировать все криптографические ключи и временные значения с использованием криптографически безопасного генератора случайных чисел; НЕДОПУСТИМО делать это с использованием генераторов, которые криптографически небезопасны. {N/A allowed} ^{[crypto_random]}

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

Проект ОБЯЗАН использовать механизм доставки, устойчивый против атак посредника (MITM). Приемлемо использование https или ssh + scp. ^{[delivery_mitm]}
НЕДОПУСТИМО получать криптографические контрольные суммы (например, sha1sum) по HTTP и использовать их без проверки криптографической подписи. ^{[delivery_unsigned]}

Исправление обнародованных уязвимостей

НЕДОПУСТИМО оставлять незакрытыми уязвимости со степенью серьезности средней или выше, опубликованные более 60 дней назад. ^{[vulnerabilities_fixed_60_days]}
Проектам СЛЕДУЕТ оперативно исправлять критические уязвимости после сообщения о них. ^{[vulnerabilities_critical_fixed]}

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

НЕДОПУСТИМА утечка действующих частных учетных данных (например, рабочий пароль или закрытый ключ), предназначенных для ограничения общего доступа, из публичных репозиториев. ^{[no_leaked_credentials]}

Анализ

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

НЕОБХОДИМО применять по крайней мере, один инструмент анализа статического кода (помимо предупреждений компилятора и "безопасных" режимов языка) к любой предлагаемой основной версии создаваемого ПО до ее выпуска, если есть хотя бы один инструмент на свободном ПО, который реализует этот критерий на выбранном языке. {N/A justification} {Met justification} ^{[static_analysis]}
ЖЕЛАТЕЛЬНО включать по крайней мере в один из инструментов статического анализа, используемых для критерия static_analysis, правила или подходы для поиска распространенных уязвимостей в анализируемом языке или среде. {N/A allowed} ^{[static_analysis_common_vulnerabilities]}
Все уязвимости со средней и высокой степенью серьезности, обнаруженные при статическом анализе кода, НЕОБХОДИМО своевременно исправлять после их подтверждения. {N/A allowed} ^{[static_analysis_fixed]}
ЖЕЛАТЕЛЬНО выполнять анализ статического исходного кода при каждом коммите или по крайней мере ежедневно. {N/A allowed} ^{[static_analysis_often]}

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

ЖЕЛАТЕЛЬНО применять по крайней мере один инструмент динамического анализа к любой предлагаемой основной (major) версии программного обеспечения перед ее выпуском . ^{[dynamic_analysis]}
ЖЕЛАТЕЛЬНО регулярно использовать по меньшей мере один динамический инструмент (например, fuzzer или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера, если программное обеспечение, создаваемое проектом, включает части, написанные на небезопасном языке (например, C или C++). Если проект не создает программное обеспечение, написанное на небезопасном языке, выберите «неприменимо» (N/A). {N/A allowed} ^{[dynamic_analysis_unsafe]}
ЖЕЛАТЕЛЬНО включать в ПО, создаваемое проектом, достаточно много утверждений (assertions) времени выполнения, проверяемых при динамическом анализе. Во многих случаях эти утверждения не должны попадать в сборки под эксплуатацию (production). ^{[dynamic_analysis_enable_assertions]}
Проект ОБЯЗАН своевременно исправлять все уязвимости средней и выше степени серьезности, обнаруженные при динамическом анализе кода, после их подтверждения. {N/A allowed} ^{[dynamic_analysis_fixed]}

Silver

Основы

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

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

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

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

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

Проекту СЛЕДУЕТ иметь юридический механизм, через который все авторы содержательных взносов в ПО проекта подтверждают, что они имеют законное право на внесение этих взносов. Самый распространенный и легко реализуемый подход для этого заключается в использовании Developer Certificate of Origin (DCO), при котором пользователи добавляют строку "signed-off-by" в свои коммиты, а проект ссылается на веб-сайт DCO. Но этот механизм МОЖЕТ быть реализован и в качестве Лицензионного соглашения с участниками (Contributor License Agreement, CLA) или другого правового механизма. {Met URL} ^[dco]
Проект ОБЯЗАН четко определить и задокументировать модель управления проектом (способ принятия решений, включая ключевые роли). {Met URL} ^[governance]
Проект ОБЯЗАН определить правила поведения и разместить эти правила в стандартном месте. {Met URL} ^{[code_of_conduct]}
Проект ОБЯЗАН четко определять и публично документировать ключевые роли в проекте и их обязанности, включая любые задачи, которые должны выполнять эти роли. Должно быть ясно, кто имеет какую роль(и), хотя это может быть и не задокументировано соответствующим образом. {Met URL} ^{[roles_responsibilities]}
Проект ОБЯЗАН быть в состоянии продолжать работу с минимальным прерыванием, если какой-либо человек окажется недееспособен или убит. В частности, проект ОБЯЗАН быть в состоянии создавать и закрывать вопросы в трекере, принимать предложенные изменения и выпускать версии программного обеспечения через неделю после подтверждения того, что данный человек недееспособен или убит. Это МОЖЕТ быть реализовано через обеспечение кого-то ещё необходимыми ключами, паролами и законными правами для продолжения проекта. Лица, которые запускают проект СПО, МОГУТ сделать это, оставив ключи в сейфе и завещание, передающее все необходимые юридические права (например, для имен DNS). {Met URL} ^{[access_continuity]}
Проекту СЛЕДУЕТ поддерживать «коэффициент автобуса» 2 или более. {Met URL} ^[bus_factor]

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

Проект ОБЯЗАН иметь задокументированный долгосрочный план (roadmap), описывающий, что проект намеревается, а что не намеревается делать, по крайней мере на ближайший год. {Met URL} ^{[documentation_roadmap]}
Проект ОБЯЗАН включать документацию по архитектуре (также называемой высокоуровневым дизайном) ПО, создаваемого проектом. Выберите «неприменимо» (N/A), если проект не создает программное обеспечение. {N/A justification} {Met URL} ^{[documentation_architecture]}
Проект ОБЯЗАН документировать то, что пользователь может и чего он не должен ожидать с точки зрения безопасности от ПО, создаваемого проектом (его «требования безопасности»). {N/A allowed} {Met URL} ^{[documentation_security]}
Проект ОБЯЗАН предоставить руководство для быстрого начала работы для новых пользователей, чтобы помочь им быстро что-то сделать, используя ПО, создаваемое проект. {N/A justification} {Met URL} ^{[documentation_quick_start]}
Проект ОБЯЗАН прилагать усилия к тому, чтобы документация соответствовала текущей версии результатов проекта (включая ПО, создаваемое проектом). НЕОБХОДИМО исправлять любые известные дефекты документации, приводящие к ее непоследовательности. Если документация в целом актуальна, но ошибочно включает в себя некоторые более старые данные, которые больше не верны, просто рассматривайте это как дефект, отслеживайте и исправляйте, как обычно. {N/A justification} {Met justification} ^{[documentation_current]}
НЕОБХОДИМО размещать ссылку на любые свои достижения, включая этот значок передовой практики, на главной странице проекта и/или веб-сайте в течение 48 часов после открытого признания достижения. {Met URL} ^{[documentation_achievements]}

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

Проекту (как на сайтах проекта, так и в результатах работы проекта) СЛЕДУЕТ придерживаться передовой практики общедоступности, чтобы люди с ограниченными возможностями могли участвовать в проекте и использовать результаты проекта, где это имеет смысл. {N/A justification} {Met justification} ^{[accessibility_best_practices]}
Проекту СЛЕДУЕТ интернационализировать создаваемое ПО, чтобы обеспечить легкую локализацию под культуру, регион или язык целевой аудитории. Выберите «неприменимо» (N/A), если интернационализация (i18n) не применяется (например, ПО не генерирует текст, предназначенный для конечных пользователей, и не сортирует текст, читаемый человеком), {N/A justification} {Met justification} ^{[internationalization]}

Другое

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

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

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

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

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

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

Проект ОБЯЗАН использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. {N/A justification} {Met justification} ^{[report_tracker]}

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

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

Качество

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

Проект ОБЯЗАН задать определенные правила стиля кодирования для основных языков, которые он использует, и требовать его соблюдения от предлагаемого кода. {N/A justification} {Met URL} ^{[coding_standards]}
Проект ОБЯЗАН автоматически применять свой выбранный стиль(и) кодирования, если есть хотя бы один инструмент на СПО, который может сделать это на выбранном языке (языках). {N/A justification} {Met justification} ^{[coding_standards_enforced]}

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

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

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

Проект ОБЯЗАН предоставлять возможность легко установить и удалить ПО, создаваемое проектом, с использованием общепринятых способов. {N/A justification} {Met justification} ^{[installation_common]}
В системе установки для конечных пользователей НЕОБХОДИМО учитывать стандартные соглашения при выборе места, в которое собранные артефакты записываются при установке. Например, если она устанавливает файлы в системе POSIX, НЕОБХОДИМО учитывать переменную окружения DESTDIR. Если установочной системы или стандартного соглашения нет, выберите «неприменимо» (N/A). {N/A justification} {Met justification} ^{[installation_standard_variables]}
Проект ОБЯЗАН предоставить возможность потенциальным разработчикам быстро установить все результаты проекта и поддерживать среду, необходимую для внесения изменений, включая тесты и тестовое окружение. Проект ОБЯЗАН использовать для этого общепринятые соглашения. {N/A justification} {Met justification} ^{[installation_development_quick]}

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

Проект ОБЯЗАН перечислять внешние зависимости в машинночитаемом виде. {N/A justification} {Met URL} ^{[external_dependencies]}
Проекты ОБЯЗАНЫ следить за своими внешними зависимостями или периодически проверять их (включая копии, сделанные для удобства) на предмет известных уязвимостей, а также исправлять уязвимости, которые могут быть использованы, или проверять невозможность их использования. {N/A justification} {Met justification} ^{[dependency_monitoring]}
Проект ОБЯЗАН:
1. позволять легко идентифицировать и обновлять повторно используемые компоненты, поддерживаемые извне; или
2. использовать стандартные компоненты, предоставляемые системой или языком программирования.
В этом случае, если уязвимость обнаружена в повторно используемом компоненте, будет легко обновить этот компонент. {N/A justification} {Met justification} ^{[updateable_reused_components]}
Проекту СЛЕДУЕТ избегать использования нерекомендуемых (deprecated) или устаревших (obsolete) функций и API в тех случаях, когда альтернативы на СПО доступны в используемом наборе технологий («стек технологий» проекта) и для подавляющего большинства пользователей, поддерживаемых проектом (т.е. так чтобы пользователи могли быстро воспользоваться этой альтернативой). {N/A justification} {Met justification} ^{[interfaces_current]}

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

НЕОБХОДИМО применять автоматический набор тестов к каждому коммиту в общий репозиторий по крайней мере для одной ветки. Этот набор тестов ОБЯЗАН создавать отчет об успешном или неудачном тестировании. {Met justification} ^{[automated_integration_testing]}
Проект ОБЯЗАН добавить регрессионные тесты к автоматизированному набору тестов по крайней мере на 50% ошибок, исправленных в течение последних шести месяцев. {N/A justification} {Met justification} ^{[regression_tests_added50]}
Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 80% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. {N/A justification} {Met justification} ^{[test_statement_coverage80]}

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

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

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

Проекты ОБЯЗАНЫ быть максимально строгими с предупреждениями в ПО, создаваемом проектом, где это целесообразно. {N/A justification} {Met justification} ^{[warnings_strict]}

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

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

Проект ОБЯЗАН реализовывать принципы безопасного дизайна (из критерия «know_secure_design»), где это применимо. Выберите «неприменимо» (N/A), если проект не создает программное обеспечение. {N/A justification} {Met justification} ^{[implement_secure_design]}

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

В ПО, создаваемом проектом, НЕДОПУСТИМО делать механизмы безопасности по умолчанию зависимыми от криптографических алгоритмов или режимов с известными серьезными слабостями (например, криптографический алгоритм хеширования SHA-1 или режим CBC в SSH). {N/A allowed} {Met justification} ^{[crypto_weaknesses]}
Проекту СЛЕДУЕТ поддерживать несколько криптографических алгоритмов, чтобы пользователи могли быстро переключиться, если один из них поврежден. Общие симметричные ключевые алгоритмы включают AES, Twofish и Serpent. Общие алгоритмы контрольных сумм (хешей) включают SHA-2 (SHA-224, SHA-256, SHA-384 и SHA-512) и SHA-3. {N/A allowed} {Met justification} ^{[crypto_algorithm_agility]}
Проект ОБЯЗАН поддерживать хранение данных для аутентификации (например, паролей и динамических токенов) и закрытых криптографических ключей в файлах, отдельных от остальной информации (например, файлов конфигурации, баз данных и журналов) и позволять пользователям их обновление и замену без перекомпиляции кода. Выберите «неприменимо» (N/A), если проект никогда не работает с данными аутентификации и закрытыми криптографическими ключами. {N/A allowed} {Met justification} ^{[crypto_credential_agility]}
В ПО, создаваемом проектом, СЛЕДУЕТ поддерживать безопасные протоколы для всех сетевых коммуникаций, такие как SSHv2 или новее, TLS1.2 или новее (HTTPS), IPsec, SFTP и SNMPv3. По умолчанию СЛЕДУЕТ отключать небезопасные протоколы, такие как FTP, HTTP, telnet, SSLv3 или более ранние версии, и SSHv1, и разрешать их только в том случае, если пользователь явным образом это задаёт. Если программное обеспечение, созданное проектом, не поддерживает сетевые коммуникации, выберите «неприменимо» (N/A). {N/A allowed} {Met justification} ^{[crypto_used_network]}
Если ПО, создаваемое проектом, поддерживает или использует TLS, ему СЛЕДУЕТ поддерживать как минимум версию TLS 1.2. Примечание: предшественник TLS называется SSL. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). {N/A allowed} {Met justification} ^{[crypto_tls12]}
В ПО, создаваемом проектом, НЕОБХОДИМО выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). {N/A allowed} {Met justification} ^{[crypto_certificate_verification]}
В ПО, создаваемом проектом, НЕОБХОДИМО, если поддерживается TLS, выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). {N/A allowed} {Met justification} ^{[crypto_verification_private]}

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

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

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

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

Анализ

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

Проект ОБЯЗАН использовать хотя бы один инструмент статического анализа с правилами или подходами для поиска распространенных уязвимостей в анализируемом языке или окружении, если есть хотя бы один инструмент на СПО, который может реализовать этот критерий на выбранном языке. {N/A justification} {Met justification} ^{[static_analysis_common_vulnerabilities]}

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

Если ПО, создаваемое проектом, включает ПО, написанное с использованием небезопасного языка (например, C или C++), тогда проект ОБЯЗАН регулярно использовать хотя бы один динамический инструмент (например, фаззер или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера. Выберите «неприменимо» (N/A), если проект не создает ПО, написанное на небезопасном языке. {N/A justification} {Met justification} ^{[dynamic_analysis_unsafe]}

Gold

Основы

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

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

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

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

Другое

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

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

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

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

Качество

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализ

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

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