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

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

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

Passing

Основы

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

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

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

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

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

Проект ОБЯЗАН предоставлять базовую документацию для программного обеспечения, создаваемого проектом. {Требуется обоснование N/A} ^{[documentation_basics]}
Проект ОБЯЗАН предоставлять справочную документацию, описывающую внешний интерфейс (как входной, так и выходной) программного обеспечения, создаваемого проектом. {Требуется обоснование N/A} ^{[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} {Требуется URL выполнения} ^{[release_notes]}
В замечаниях о выпуске НЕОБХОДИМО упоминать каждую общеизвестную уязвимость, исправленную в каждой новой версии, для которой существует CVE или аналогичная публичная запись. Критерий может быть отмечен как неприменимый (N/A), если у пользователей обычно нет практической возможности обновить данное ПО самостоятельно (это часто относится к, например, обновлениям ядра операционной системы). Если замечаний о выпуске не публиковалось или не было обнародованных уязвимостей, отвечайте "неприменимо". {Требуется обоснование N/A} ^{[release_notes_vulns]}

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

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

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

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

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

Качество

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

Если программное обеспечение, создаваемое проектом, требует сборки для использования, проект ОБЯЗАН предоставить рабочую систему сборки, которая может автоматически пересобирать программное обеспечение из исходного кода. {Разрешено N/A} ^[build]
ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. {Разрешено N/A} ^{[build_common_tools]}
Для сборки проекта СЛЕДУЕТ использовать только инструменты со свободными лицензиями. {Разрешено N/A} ^{[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} ^[warnings]
Проект ОБЯЗАН обращать внимание на предупреждения. {Разрешено N/A} ^{[warnings_fixed]}
ЖЕЛАТЕЛЬНО, чтобы проекты использовали самый строгий режим предупреждений в производимом ПО, где это целесообразно. {Разрешено N/A} ^{[warnings_strict]}

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

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

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

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

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

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

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

Silver

Основы

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

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

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

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

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

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

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

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

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

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

Другое

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

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

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

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

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

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

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

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

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

Качество

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В ПО, создаваемом проектом, НЕДОПУСТИМО делать механизмы безопасности по умолчанию зависимыми от криптографических алгоритмов или режимов с известными серьезными слабостями (например, криптографический алгоритм хеширования SHA-1 или режим CBC в SSH). {Разрешено N/A} {Требуется обоснование выполнения} ^{[crypto_weaknesses]}
Проекту СЛЕДУЕТ поддерживать несколько криптографических алгоритмов, чтобы пользователи могли быстро переключиться, если один из них поврежден. Общие симметричные ключевые алгоритмы включают AES, Twofish и Serpent. Общие алгоритмы контрольных сумм (хешей) включают SHA-2 (SHA-224, SHA-256, SHA-384 и SHA-512) и SHA-3. {Разрешено N/A} {Требуется обоснование выполнения} ^{[crypto_algorithm_agility]}
Проект ОБЯЗАН поддерживать хранение данных для аутентификации (например, паролей и динамических токенов) и закрытых криптографических ключей в файлах, отдельных от остальной информации (например, файлов конфигурации, баз данных и журналов) и позволять пользователям их обновление и замену без перекомпиляции кода. Выберите «неприменимо» (N/A), если проект никогда не работает с данными аутентификации и закрытыми криптографическими ключами. {Разрешено N/A} {Требуется обоснование выполнения} ^{[crypto_credential_agility]}
В ПО, создаваемом проектом, СЛЕДУЕТ поддерживать безопасные протоколы для всех сетевых коммуникаций, такие как 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]}
В ПО, создаваемом проектом, НЕОБХОДИМО выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). {Разрешено N/A} {Требуется обоснование выполнения} ^{[crypto_certificate_verification]}
В ПО, создаваемом проектом, НЕОБХОДИМО, если поддерживается TLS, выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). {Разрешено N/A} {Требуется обоснование выполнения} ^{[crypto_verification_private]}

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

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

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

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

Анализ

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

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

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

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

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]}

Базовый уровень 1

Общее

Элементы управления

Когда пользователь пытается прочитать или изменить чувствительный ресурс в авторитетном репозитории проекта, система ДОЛЖНА требовать от пользователя прохождения процесса многофакторной аутентификации. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_ac_01_01]}
При добавлении нового соавтора система контроля версий ДОЛЖНА требовать ручного назначения прав доступа или по умолчанию ограничивать права доступа соавтора до минимально доступных привилегий. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_ac_02_01]}
При попытке прямого коммита в основную ветку проекта механизм принудительного исполнения ДОЛЖЕН предотвращать применение изменения. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_ac_03_01]}
Когда предпринимается попытка удалить основную ветку проекта, система контроля версий ОБЯЗАНА рассматривать это как деликатное действие и требовать явного подтверждения намерения. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_ac_03_02]}
Когда конвейер CI/CD принимает входной параметр, этот параметр ОБЯЗАН быть очищен и проверен перед использованием в конвейере. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_01_01]}
Когда конвейер CI/CD использует имя ветки в своей функциональности, это значение имени ОБЯЗАНО быть очищено и проверено перед использованием в конвейере. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_01_02]}
Когда проект указывает URI как официальный канал проекта, этот URI ОБЯЗАН передаваться исключительно с использованием зашифрованных каналов. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_03_01]}
Когда проект указывает URI как официальный канал распространения, этот URI ОБЯЗАН передаваться исключительно с использованием зашифрованных каналов. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_03_02]}
Проект ОБЯЗАН предотвращать непреднамеренное сохранение незашифрованных конфиденциальных данных, таких как секреты и учетные данные, в системе контроля версий. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_07_01]}
Когда проект сделал релиз, документация проекта ОБЯЗАНА включать руководства пользователя для всего базового функционала. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_do_01_01]}
Когда проект сделал релиз, документация проекта ОБЯЗАНА включать руководство по сообщению о дефектах. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_do_02_01]}
Пока проект активен, он ОБЯЗАН иметь один или несколько механизмов для публичных обсуждений предлагаемых изменений и препятствий в использовании. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_gv_02_01]}
Пока проект активен, документация проекта ОБЯЗАНА включать объяснение процесса внесения вклада. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_gv_03_01]}
Пока проект активен, лицензия на исходный код ОБЯЗАНА соответствовать определению Open Source от OSI или определению свободного программного обеспечения от FSF. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_le_02_01]}
Пока активен, лицензия для выпущенных программных активов ОБЯЗАНА соответствовать определению открытого ПО по OSI или определению свободного ПО по FSF. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_le_02_02]}
Пока активен, лицензия для исходного кода ОБЯЗАНА поддерживаться в файле LICENSE, файле COPYING или директории LICENSE/ соответствующего репозитория. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_le_03_01]}
Пока активен, лицензия для выпущенных программных активов ОБЯЗАНА быть включена в выпущенный исходный код или в файл LICENSE, файл COPYING или директорию LICENSE/ рядом с соответствующими выпущенными активами. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_le_03_02]}
Пока активен, репозиторий исходного кода проекта ОБЯЗАН быть общедоступным для чтения по статическому URL. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_01_01]}
Система контроля версий ОБЯЗАНА содержать общедоступную запись всех внесенных изменений, кто внес изменения и когда были внесены изменения. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_01_02]}
Когда система управления пакетами это поддерживает, репозиторий исходного кода ОБЯЗАН содержать список зависимостей, учитывающий прямые языковые зависимости. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_02_01]}
Пока активна, документация проекта ОБЯЗАНА содержать список всех кодовых баз, которые считаются подпроектами. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_04_01]}
Пока активна, система контроля версий НЕ ДОЛЖНА содержать сгенерированные исполняемые артефакты. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_05_01]}
Пока активна, система контроля версий НЕ ДОЛЖНА содержать непроверяемые бинарные артефакты. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_05_02]}
Пока активна, документация проекта ОБЯЗАНА содержать контакты по вопросам безопасности. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_02_01]}

Базовый Уровень 2

Общее

Элементы управления

Когда задача CI/CD выполняется без указания прав доступа, система CI/CD ОБЯЗАНА по умолчанию назначать задаче минимальные права, предоставленные в конвейере. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_ac_04_01]}
Когда создается официальный выпуск, этому выпуску ОБЯЗАН быть назначен уникальный идентификатор версии. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_02_01]}
Когда создается официальный выпуск, этот выпуск ОБЯЗАН содержать описательный журнал функциональных изменений и изменений безопасности. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_04_01]}
Когда конвейер сборки и выпуска загружает зависимости, он ОБЯЗАН использовать стандартизированные инструменты, где они доступны. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_05_01]}
Когда создается официальный выпуск, этот выпуск ОБЯЗАН быть подписан или учтен в подписанном манифесте, включающем криптографические хеши каждого актива. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_06_01]}
Когда проект создал выпуск, документация проекта ОБЯЗАНА включать описание того, как проект выбирает, получает и отслеживает свои зависимости. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_do_06_01]}
Пока проект активен, документация проекта ОБЯЗАНА включать список членов проекта с доступом к критическим ресурсам. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_gv_01_01]}
Пока проект активен, документация проекта ОБЯЗАНА включать описания ролей и обязанностей для членов проекта. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_gv_01_02]}
Пока проект активен, документация проекта ОБЯЗАНА включать руководство для участников кода, которое включает требования к приемлемым вкладам. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_gv_03_02]}
Пока проект активен, система контроля версий ОБЯЗАНА требовать от всех участников кода утверждать, что они имеют законное право вносить соответствующий вклад в каждом коммите. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_le_01_01]}
При внесении коммита в основную ветку все автоматические проверки статуса для коммитов ДОЛЖНЫ пройти успешно или быть явно обойдены вручную. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_03_01]}
Перед принятием коммита в проекте ДОЛЖЕН выполняться хотя бы один автоматизированный набор тестов в конвейере CI/CD для обеспечения соответствия изменений ожиданиям. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_06_01]}
Когда проект выпустил релиз, документация проекта ДОЛЖНА включать проектную документацию, демонстрирующую все действия и участников в системе. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_sa_01_01]}
Когда проект выпустил релиз, документация проекта ДОЛЖНА включать описания всех внешних программных интерфейсов выпущенных программных активов. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_sa_02_01]}
Когда проект выпустил релиз, проект ДОЛЖЕН провести оценку безопасности для понимания наиболее вероятных и значимых потенциальных проблем безопасности, которые могут возникнуть в программном обеспечении. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_sa_03_01]}
Пока проект активен, документация проекта ДОЛЖНА включать политику координированного раскрытия уязвимостей (CVD) с четко определенными сроками ответа. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_01_01]}
Пока проект активен, документация проекта ДОЛЖНА предоставлять средства для приватного сообщения об уязвимостях непосредственно контактам по безопасности в проекте. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_03_01]}
Пока проект активен, документация проекта ДОЛЖНА публично публиковать данные об обнаруженных уязвимостях. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_04_01]}

Базовый Уровень 3

Общее

Элементы управления

Когда задаче назначаются разрешения в конвейере CI/CD, исходный код или конфигурация ДОЛЖНЫ назначать только минимальные привилегии, необходимые для соответствующей деятельности. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_ac_04_02]}
Когда создается официальный релиз, все активы в этом релизе ДОЛЖНЫ быть четко связаны с идентификатором релиза или другим уникальным идентификатором для актива. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_02_02]}
НЕОБХОДИМО, чтобы проект определил политику управления секретами и учетными данными, используемыми проектом. Политика должна включать руководства по хранению, доступу и ротации секретов и учетных данных. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_07_02]}
Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке целостности и подлинности активов релиза. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_do_03_01]}
Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке ожидаемой личности человека или процесса, создающего программный релиз. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_do_03_02]}
Когда проект выпустил релиз, документация проекта ДОЛЖНА включать описательное заявление о масштабе и сроках поддержки для каждого релиза. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_do_04_01]}
Когда проект выпустил релиз, документация проекта ДОЛЖНА предоставлять описательное заявление о том, когда релизы или версии больше не будут получать обновления безопасности. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_do_05_01]}
Пока проект активен, документация проекта ДОЛЖНА содержать политику, согласно которой участники кода проверяются перед предоставлением повышенных разрешений на доступ к критическим ресурсам. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_gv_04_01]}
Когда проект выпустил релиз, все скомпилированные выпущенные программные активы ДОЛЖНЫ поставляться со списком компонентов программного обеспечения (Software Bill of Materials). {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_02_02]}
Когда проект выпустил релиз, состоящий из нескольких репозиториев исходного кода, все подпроекты ДОЛЖНЫ применять требования безопасности, которые являются столь же строгими или более строгими, чем первичная кодовая база. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_04_02]}
Пока проект активен, документация проекта ДОЛЖНА четко документировать, когда и как выполняются тесты. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_06_02]}
Пока проект активен, документация проекта ДОЛЖНА включать политику, согласно которой все значительные изменения программного обеспечения, производимого проектом, должны добавлять или обновлять тесты функциональности в автоматизированном наборе тестов. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_06_03]}
Когда совершается коммит в основную ветку, система контроля версий проекта ДОЛЖНА требовать как минимум одного одобрения изменений человеком, не являющимся автором, перед слиянием. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_07_01]}
Когда проект выпустил релиз, проект ДОЛЖЕН выполнить моделирование угроз и анализ поверхности атаки для понимания и защиты от атак на критические пути кода, функции и взаимодействия внутри системы. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_sa_03_02]}
Пока активен, любые уязвимости в программных компонентах, не затрагивающие проект, ДОЛЖНЫ быть учтены в документе VEX, дополняющем отчет об уязвимостях деталями о неэксплуатируемости. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_04_02]}
Пока активна, документация проекта ДОЛЖНА включать политику, определяющую порог для устранения результатов SCA, связанных с уязвимостями и лицензиями. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_05_01]}
Пока активна, документация проекта ДОЛЖНА включать политику для устранения нарушений SCA до любого релиза. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_05_02]}
Пока активны, все изменения в кодовой базе проекта ДОЛЖНЫ автоматически оцениваться на соответствие задокументированной политике по вредоносным зависимостям и известным уязвимостям в зависимостях, а затем блокироваться в случае нарушений, за исключением случаев, когда они объявлены и подавлены как неэксплуатируемые. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_05_03]}
Пока активна, документация проекта ДОЛЖНА включать политику, определяющую порог для устранения результатов SAST. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_06_01]}
Пока активны, все изменения в кодовой базе проекта ДОЛЖНЫ автоматически оцениваться на соответствие задокументированной политике по слабым местам безопасности и блокироваться в случае нарушений, за исключением случаев, когда они объявлены и подавлены как неэксплуатируемые. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_06_02]}