Критерии лучших практик 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]}

  Подробности:

  Мы предполагаем, что проекты на GitHub используют issues и pull requests, если не указано иное. Описание может быть кратким, например, указывать, что проект использует pull requests, issue tracker или сообщения в список рассылки (какой?).

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

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

• ПО, создаваемое проектом, ОБЯЗАНО быть выпущено под свободной лицензией. ^{[floss_license]}

  Подробности:

  Свободное ПО (далее СПО) - это программное обеспечение, которое соответствует Определению Открытого ПО (официальный текст на англ.) или Определению Свободного Программного Обеспечения. Примеры таких лицензий включают CC0, MIT, BSD 2-Clause, BSD 3-Clause, Apache 2.0, Меньшая стандартная общественная лицензия GNU (LGPL) и Стандартная общественная лицензия GNU (GPL). Для наших целей это означает, что лицензия ОБЯЗАНА быть:

  • одобренной Open Source Initiative (OSI), или
  • свободной лицензией, одобренной Фондом Свободного Программного Обеспечения (FSF), или
  • свободной лицензией, приемлемой для ветки main проекта Debian, или
  • «хорошей» лицензией в понимании Fedora.

  ПО МОЖЕТ одновременно лицензироваться на других условиях (например, приемлема комбинация «GPLv2 или закрытая лицензия»).

• ЖЕЛАТЕЛЬНО, чтобы все лицензии для ПО, создаваемого проектом, были одобрены Open Source Initiative (OSI). ^{[floss_license_osi]}

  Подробности:

  Для одобрения OSI используется строгий процесс, чтобы определить, какие лицензии соответствуют Открытому ПО.

• Проект ОБЯЗАН публиковать лицензию или лицензии своих результатов в стандартном расположении в своем репозитории исходного кода. {Требуется URL выполнения} ^{[license_location]}

  Подробности:

  Например, в качестве файла верхнего уровня с именем LICENSE или COPYING. Имена файлов лицензии МОГУТ сопровождаться расширением, таким как «.txt» или «.md». Другим соглашением может быть наличие каталога с именем LICENSES, содержащего файлы лицензий; имена этих файлов обычно соответствуют SPDX-идентификатору лицензии, за которым следует соответствующее расширение файла, как описано в спецификации REUSE . Обратите внимание, что этот критерий является обязательным только для репозитория с исходным кодом. Вам НЕ нужно включать файл лицензии при генерации чего-либо из исходного кода (например, исполняемого файла, пакета или контейнера). Например, при создании пакета R для Comprehensive R Archive Network (CRAN) рекомендуется следовать стандартной практике CRAN: если лицензия является стандартной, используйте стандартную короткую спецификацию лицензии (чтобы избежать установки еще одной копии текста) и добавьте файл LICENSE в списке исключений, например .Rbuildignore. Аналогично, при создании пакета Debian вы можете поместить в файл copyright ссылку на текст лицензии в /usr/share/common-licenses и исключить файл лицензии из созданного пакета (например, удаляя файл после вызова dh_auto_install). Мы рекомендуем включать машиночитаемую информацию о лицензии в сгенерированных форматах, где это возможно.

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

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

  Подробности:

  Эта документация должна быть в некоторых формах (таких как текст или видео), которые включают в себя: как установить программное обеспечение, как его запустить, как его использовать (возможно, с помощью учебника с примерами) и как использовать его безопасно (например, что делать и чего не делать), если эти темы применимы для данного программного обеспечения. Документация по безопасности не обязательно должна быть длинной. Проект МОЖЕТ использовать гипертекстовые ссылки для не-проектных материалов в качестве документации. Если проект не создает программное обеспечение, выберите «неприменимо» (N/A).

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

  Подробности:

  Документация внешнего интерфейса объясняет конечному пользователю или разработчику, как его использовать. Это может включать в себя интерфейс прикладного программирования (API), если программное обеспечение его имеет. Если это библиотека, документируйте основные классы/типы и методы/функции, которые можно вызвать. Если это веб-приложение, определите его URL-интерфейс (часто его интерфейс REST). Если это интерфейс командной строки, документируйте параметры и настройки, которые он поддерживает. Во многих случаях лучше всего, если большая часть этой документации будет автоматически сгенерирована, чтобы эта документация была синхронизирована с программным обеспечением по мере его изменения, но это не требуется. Проект МОЖЕТ использовать гипертекстовые ссылки для не-проектных материалов в качестве документации. Документация МОЖЕТ быть автоматически сгенерирована (там, где это применимо, это часто наилучший способ создания документации). Документация интерфейса REST может быть сгенерирована с использованием Swagger/OpenAPI. Документация по интерфейсу кода МОЖЕТ быть сгенерирована с использованием таких инструментов, как JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) и Doxygen (многие языки). Просто иметь комментарии в коде реализации недостаточно для выполнения этого критерия; должен быть простой способ увидеть информацию без чтения всего исходного кода. Если проект не создает программное обеспечение, выберите «неприменимо» (N/A).

Другое

• Сайты проекта (веб-сайт, репозиторий и URL-адреса для загрузки) ОБЯЗАНЫ поддерживать HTTPS с использованием TLS. ^{[sites_https]}

  Подробности:

  Для выполнения этого критерия требуется, чтобы URL домашней страницы проекта начинался с "https:", а не "http:". Вы можете получить бесплатные сертификаты от проекта Let's Encrypt. Проекты МОГУТ выполнить этот критерий, используя (например) GitHub Pages, GitLab Pages или проектные страницы SourceForge. Если вы поддерживаете HTTP, мы настоятельно рекомендуем перенаправить HTTP-трафик на HTTPS.

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

  Подробности:

  Примерами приемлемых механизмов являются архивируемые списки рассылки, обсуждения в GitHub issues и pull requests, Bugzilla, Mantis и Trac. Асинхронные механизмы обсуждения (например, IRC) приемлемы, если они отвечают этим критериям; убедитесь, что есть механизм архивирования URL-адресов. Разрешено, хотя и не рекомендуется, использовать проприетарный JavaScript.

• Проекту СЛЕДУЕТ предоставлять документацию на английском языке и иметь возможность принимать отчеты об ошибках и комментарии о коде на английском языке. ^[english]

  Подробности:

  Английский в настоящее время является лингва франка компьютерной техники; Поддержка английского языка увеличивает число потенциальных разработчиков и рецензентов во всем мире. Проект может соответствовать этому критерию, даже если английский не является основным языком его ключевых разработчиков.

• НЕОБХОДИМО, чтобы проект поддерживался. ^[maintained]

  Подробности:

  Как минимум, проект должен пытаться реагировать на сообщения о серьезных проблемах и уязвимостях. Проект, который активно добивается получения значка, вероятно, и поддерживается тоже. Ресурсы любого проекта и человека ограничены, и обычно проекты будут отклонять некоторые предлагаемые изменения; поэтому ограниченность ресурсов и отклонение предложений сами по себе не указывают на то, что проект не поддерживается.
  
  Если известно, что проект больше не будет поддерживаться, следует установить для этого критерия значение «Не соответствует» и использовать подходящие механизмы, чтобы указать другим, что он не поддерживается. Например, используйте “DEPRECATED” («УСТАРЕЛ») в качестве первого заголовка в файле README, добавьте “DEPRECATED” в начале его домашней страницы, добавьте “DEPRECATED” в начало описания проекта репозитория кода, добавьте значок об отсутствии поддержки в README проекта и/или домашнюю страницу, пометьте его как устаревший в любых репозиториях пакетов (напр., npm deprecate ) и/или используйте механизм, предоставленный репозиторием кода для его архивирования (например, параметр "archive" у GitHub или пометка "archive" у GitLab, статус «только для чтения» у Gerrit или статус «брошенного» проекта у SourceForge). Дополнительное обсуждение можно найти здесь .

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

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

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

  Подробности:

  URL МОЖЕТ быть таким же, как URL проекта. Проект МОЖЕТ использовать частные (непубличные) ветви в конкретных случаях, когда изменение не выпускается публично (например, для устранения уязвимости до того, как она будет открыта для публики).

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

  Подробности:

  Проекты МОГУТ опускать отдельные промежуточные версии из своих публичных репозиториев (например, те, которые фиксируют отдельные не обнародованные уязвимости, никогда не будут публично выпущены или включают материалы, которые не могут быть опубликованы на законных основаниях и не находятся в финальной версии).

• Для хранилища проектного исходного кода ЖЕЛАТЕЛЬНО использовать типовое ПО для распределенного управления версиями (например, git). ^{[repo_distributed]}

  Подробности:

  Не требуется именно git, и проекты могут использовать централизованное программное обеспечение для управления версиями (например, Subversion) с обоснованием.

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

• Результаты проекта ОБЯЗАНЫ иметь уникальный идентификатор версии для каждой версии, предназначенной для конечных пользователей. ^{[version_unique]}

  Подробности:

  Это МОЖНО выполнить различными способами, включая идентификаторы коммита (например, идентификатор коммита git или идентификатор набора изменений mercurial) или номер версии (включая номера версий, которые используют семантическое версионирование или схемы на основе даты, такие как YYYYMMDD).

• Для выпусков ЖЕЛАТЕЛЬНО использовать семантическую либо календарную нумерацию версий. При использовании календарной нумерации к версии ЖЕЛАТЕЛЬНО добавлять микро-компоненту. ^{[version_semver]}

  Подробности:

  МОЖНО использовать в качестве номеров версий другие схемы нумерации версий, такие как идентификаторы коммитов (например, идентификатор коммита в git или идентификатор набора изменений в mercurial) или схемы на основе даты, такие как YYYYMMDD, поскольку они уникальны. Некоторые альтернативы могут вызвать трудности, поскольку пользователи могут быть не в состоянии легко определить, используют ли они последнюю версию. SemVer может оказаться менее полезным для идентификации версий программного обеспечения, если все получатели используют только последнюю версию (например, это код для одного веб-сайта или интернет-сервиса, который постоянно обновляется с помощью непрерывной доставки).

• Проектам ЖЕЛАТЕЛЬНО идентифицировать каждый выпуск в своей системе управления версиями. Например, при использовании git ЖЕЛАТЕЛЬНО идентифицировать каждую версию, используя теги git. ^{[version_tags]}

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

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

  Подробности:

  Замечания к выпуску МОГУТ быть реализованы различными способами. Многие проекты предоставляют их в файле с именем «NEWS», «CHANGELOG» или «ChangeLog», возможно с расширениями, такими как «.txt», «.md» или «.html». Исторически термин «журнал изменений» означал журнал для каждого изменения, но для соответствия этим критериям требуется человекочитаемая сводка. Замечания к выпуску МОГУТ вместо этого быть предоставлены механизмами системы контроля версий, такими как процесс GitHub Releases.

• В замечаниях о выпуске НЕОБХОДИМО упоминать каждую общеизвестную уязвимость, исправленную ​​в каждой новой версии, для которой существует CVE или аналогичная публичная запись. Критерий может быть отмечен как неприменимый (N/A), если у пользователей обычно нет практической возможности обновить данное ПО самостоятельно (это часто относится к, например, обновлениям ядра операционной системы). Если замечаний о выпуске не публиковалось или не было обнародованных уязвимостей, отвечайте "неприменимо". {Требуется обоснование N/A} ^{[release_notes_vulns]}

  Подробности:

  Этот критерий помогает пользователям определить, исправит ли данное обновление общеизвестную уязвимость, чтобы помочь пользователям принять обоснованное решение об обновлении. Если пользователи обычно не могут практически самостоятельно обновлять программное обеспечение на своих компьютерах, а вместо этого должны полагаться на одного или нескольких посредников для выполнения обновления (как это часто бывает с ядром и низкоуровневым программным обеспечением, которое взаимосвязано с ядром), проект вместо этого можно выбрать «Неприменимо», поскольку эта дополнительная информация будет бесполезна для таких пользователей. Аналогично, проект может выбрать «неприменимо» (N/A), если все получатели используют только последнюю версию (например, это код для одного веб-сайта или интернет-службы, который постоянно обновлен при помощи непрерывной доставки). Этот критерий применим только к результатам проекта, а не к его зависимостям. Перечисление уязвимостей всех транзитивных зависимостей проекта становится громоздким, поскольку зависимости увеличиваются и изменяются; и в этом нет необходимости, поскольку инструменты, которые исследуют и отслеживают зависимости, могут делать это более масштабируемым способом.

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

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

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

  Подробности:

  В качестве ответа МОЖЕТ быть «нет» или обсуждение выгод от данного улучшения. Цель состоит в том, чтобы по крайней мере на некоторые запросы был какой-то ответ, что указывает на то, что проект все еще жив. Для целей этого критерия не нужно учитывать поддельные запросы (например, от спамеров или автоматизированных систем). Если проект больше не принимает улучшения, выберите «не соответствует» и укажите URL, проясняющий ситуацию для пользователей. Если проект большую часть времени перегружен количеством запросов на улучшения, выберите «не cоответствует» и объясните.

• Проект ОБЯЗАН иметь общедоступный архив для отчетов и ответов для последующего поиска. {Требуется URL выполнения} ^{[report_archive]}

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

• Проект ОБЯЗАН публиковать процесс уведомления об уязвимостях на сайте проекта. {Требуется URL выполнения} ^{[vulnerability_report_process]}

  Подробности:

  Например, четко обозначенный почтовый адрес на https://PROJECTSITE/security, часто в форме security@example.org. Процесс МОЖЕТ быть таким же, как и процесс для отчетов об ошибках. Отчеты об уязвимостях МОГУТ быть всегда общедоступными, но многие проекты имеют приватный механизм для отправки отчетов об уязвимостях.

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

  Подробности:

  Примеры включают приватный отчет о дефектах, отправленный в Интернете с использованием HTTPS (TLS) или электронной почты, зашифрованной с использованием OpenPGP. Если отчеты об уязвимостях всегда являются общедоступными (поэтому нет приватных отчетов об уязвимостях), выберите «неприменимо» (N/A).

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

  Подробности:

  Если за последние 6 месяцев не было обнаружено никаких уязвимостей, выберите «неприменимо» (N/A).

Качество

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

• Если программное обеспечение, создаваемое проектом, требует сборки для использования, проект ОБЯЗАН предоставить рабочую систему сборки, которая может автоматически пересобирать программное обеспечение из исходного кода. {Разрешено N/A} ^[build]

  Подробности:

  Система сборки определяет, какие действия необходимо предпринять для пересборки программного обеспечения (и в каком порядке), а затем выполняет эти действия. Например, она может вызывать компилятор для компиляции исходного кода. Если исполняемый файл создается из исходного кода, должна иметься возможность изменить исходный код проекта, а затем сгенерировать обновленный исполняемый файл с этими изменениями. Если программное обеспечение, создаваемое проектом, зависит от внешних библиотек, система сборки не обязана пересобирать эти внешние библиотеки. Если для использования программного обеспечения после изменения его исходного кода пересборка не требуется, выберите «неприменимо» (N/A).

• ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. {Разрешено N/A} ^{[build_common_tools]}

  Подробности:

  Например, Maven, Ant, cmake, autotools, make, rake или devtools (R).

• Для сборки проекта СЛЕДУЕТ использовать только инструменты со свободными лицензиями. {Разрешено N/A} ^{[build_floss_tools]}

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

• Проект ОБЯЗАН использовать по крайней мере один автоматизированный набор тестов, опубликованный как свободное ПО (этот набор тестов может поддерживаться как отдельный проект свободного ПО). Проект ОБЯЗАН ясно показывать или иметь документацию о том, как запускать наборы тестов (например, через непрерывную интеграцию (CI) или используя файлы документации, такие как BUILD.md, README.md или CONTRIBUTING.md). ^[test]

  Подробности:

  Проект МОЖЕТ использовать несколько автоматизированных наборов тестов (например, один, который работает быстро, а другой - более тщательный, но требует специального оборудования). Существует множество каркасов (frameworks) и систем поддержки тестирования, включая Selenium (автоматизация веб-браузера), Junit (JVM, Java), RUnit (R), testthat (R).

• Запуск набора тестов СЛЕДУЕТ реализовывать стандартным способом для этого языка. ^{[test_invocation]}

  Подробности:

  Например, «make check», «mvn test» или «rake test» (Ruby).

• ЖЕЛАТЕЛЬНО охватывать набором тестов большинство (а в идеале все) ветви кода, поля ввода и функциональные возможности. ^[test_most]
• ЖЕЛАТЕЛЬНО реализовать непрерывную интеграцию (Continuous Integration - частая интеграция нового или измененного кода в центральное хранилище кода, и запуск автоматических тестов на получившейся базе кода). ^{[test_continuous_integration]}

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

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

  Подробности:

  Если есть действующая политика, хотя бы «из уст в уста», которая говорит, что разработчики должны добавлять тесты в набор автотестов для новой функциональности, указывайте «соответствует».

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

  Подробности:

  Крупная функциональность обычно упоминается в замечаниях к выпуску. Совершенство не требуется, просто доказательство того, что на практике тесты обычно добавляются в набор автотестов, когда к ПО, создаваемому проектом, добавляются новые крупные функции.

• ЖЕЛАТЕЛЬНО задокументировать эту политику добавления тестов (см. критерий test_policy) в инструкции к предложениям об изменениях. ^{[tests_documented_added]}

  Подробности:

  Однако даже неформальное правило приемлемо, если тесты добавляются на практике.

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

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

  Подробности:

  Примером предупреждающего флага компилятора может служить "-Wall" для gcc/clang. Примеры «безопасного» языкового режима включают «use strict» в JavaScript и «use warnings» в perl5. Отдельный инструмент «linter» - это просто инструмент, который исследует исходный код для поиска ошибок качества кода или типовых простых ошибок. Всё это обычно включается в исходный код или инструкции сборки.

• Проект ОБЯЗАН обращать внимание на предупреждения. {Разрешено N/A} ^{[warnings_fixed]}

  Подробности:

  Речь о предупреждениях, найденных при выполнении критерия warnings. Проект должен исправлять предупреждения или отмечать их в исходном коде как ложные срабатывания. В идеале не должно быть никаких предупреждений, но проект МОЖЕТ принимать существование каких-то предупреждений (обычно менее 1 предупреждения на 100 строк или менее 10 предупреждений).

• ЖЕЛАТЕЛЬНО, чтобы проекты использовали самый строгий режим предупреждений в производимом ПО, где это целесообразно. {Разрешено N/A} ^{[warnings_strict]}

  Подробности:

  Некоторые предупреждения не могут быть эффективно задействованы в некоторых проектах. Что необходимо в этом критерии - это доказательства того, что проект стремится включать флаги предупреждений там, где это возможно, чтобы ошибки обнаруживались на ранней стадии.

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

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

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

  Подробности:

  Это требует понимания следующих принципов проектирования, в том числе 8 принципов из Saltzer and Schroeder:

  • экономичность механизма (поддерживать дизайн ПО настолько простым и компактным, насколько практически возможно, например, с помощью массовых упрощений)
  • отказобезопасные значения по умолчанию (доступ по умолчанию должен быть запрещен, а установка проектов по умолчанию должна быть в защищенной конфигурации)
  • полное разграничение (любой доступ, который может быть ограничен, должен проверяться на достаточность прав доступа и не иметь обходных путей)
  • открытый дизайн (механизмы безопасности должны полагаться не на незнание их злоумышленником, а на данные типа ключей и паролей, которые проще защищать и менять)
  • разделение привилегий (в идеале доступ к важным объектам должен зависеть от более чем одного условия, так чтобы взлом одной системы защиты не приводил к полному доступу; напр., многофакторная аутентификация с требованием и пароля, и аппаратного токена сильнее однофакторной)
  • минимальные привилегии (процессы должны работать с минимальными привилегиями, необходимыми для выполнения ими своих функций)
  • наименьший общий механизм (дизайн должен минимизировать механизмы, общие для нескольких пользователей и следовательно зависящие от всех этих пользователей, например, каталоги для временных файлов)
  • психологическая приемлемость (интерфейс для человека должен быть спроектирован с учетом удобства использования - может быть полезным проектирование для «наименьшего удивления»)
  • ограничение периметра атаки (периметр атаки - множество разных точек, в которых злоумышленник может попытаться ввести или извлечь данные - должен быть ограничен)
  • проверка входных данных с помощью списков на допуск (входы обычно должны проверяться на корректность до их принятия; эта проверка должна использовать списки на допуск, содержащие только заведомо хорошие значения, а не списки на запрет, пытающиеся перечислить заведомо плохие значения).

  «Основной разработчик» в проекте - это любой, кто знаком с базой кода проекта, без затруднений может вносить в него изменения и признан таковым большинством других участников проекта. Основной разработчик, как правило, неоднократно вносит вклад в течение последнего года (через код, документацию или ответы на вопросы). Разработчики обычно считаются основными разработчиками, если это они начали проект (и не покинули проект более трех лет назад), имеют возможность получать информацию по закрытому каналу для отчетов об уязвимостях (если он есть), могут принимать коммиты от имени проекта или делать финальные выпуски программного обеспечения проекта. Если есть только один разработчик, этот человек является основным разработчиком. Есть много книг и курсов, помогающих понять, как разрабатывать более безопасное ПО, с обсуждением вопросов проектирования. Например, Secure Software Development Fundamentals - это бесплатный набор из трех курсов, объясняющих, как разрабатывать более безопасное ПО (бесплатный для обучения; за отдельную плату вы можете получить сертификат для подтверждения, что вы освоили материал).

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

  Подробности:

  Примеры (в зависимости от типа ПО) включают внедрение SQL-кода (injection), внедрение на уровне ОС, классическое переполнение буфера, межсайтовый скриптинг, отсутствие проверки подлинности и отсутствие авторизации. Обычно используемые списки уязвимостей можно найти в CWE/SANS top 25 или OWASP Top 10. Есть много книг и обучающих курсов, помогающих понять, как разрабатывается безопасное программное обеспечение, и обсуждающих типичные ошибки в реализации, ведущие к уязвимостям. К примеру, Secure Software Development Fundamentals - это набор из трех курсов, объясняющих, как сделать разрабатываемое ПО более безопасным (бесплатный для прослушивания; за дополнительную плату вы можете получить справку о том, что прошли его).

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

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

  Подробности:

  Эти криптографические критерии не всегда применяются, поскольку некоторые программы не нуждаются в прямом использовании криптографических возможностей.

• Если программное обеспечение, создаваемое проектом, является приложением или библиотекой, и его основной целью является не внедрение криптографии, тогда для реализации криптографических функций СЛЕДУЕТ обращаться к программному обеспечению, специально предназначенному для этого; НЕ СЛЕДУЕТ повторно реализовывать свои собственные функции. {Разрешено N/A} ^{[crypto_call]}
• Вся функциональность программного обеспечения, создаваемого проектом, которая зависит от криптографии, ОБЯЗАНА быть реализована с использованием свободного ПО. {Разрешено N/A} ^{[crypto_floss]}

  Подробности:

  См. Требования к открытым стандартам для программного обеспечения в рамках Open Source Initiative (на англ.).

• Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ использовать стандартные длины криптографических ключей, которые, по крайней мере, соответствуют минимальным требованиям NIST до 2030 года (как указано в 2012 году). Проект ОБЯЗАН предоставлять возможность настройки ПО таким образом, чтобы уменьшенные длины ключей были полностью отключены. {Разрешено N/A} ^{[crypto_keylength]}

  Подробности:

  Эти минимальные длины в битах перечислены далее: симметричный ключ - 112, модуль факторизации - 2048, дискретный логарифмический ключ - 224, дискретная логарифмическая группа - 2048, эллиптическая кривая - 224 и хеш - 224 (хеширование пароля не покрывается этой длиной, больше информации о хешировании пароля можно найти в описании критерия crypto_password_storage). См. http://www.keylength.com для сравнения рекомендаций по длинам криптографических ключей от различных организаций. Программное обеспечение МОЖЕТ допускать меньшие длины ключей в некоторых конфигурациях (в идеале не должно, поскольку это позволяет атаки через понижение длины ключа, но иногда требуется более короткая длина ключа для обеспечения взаимодействия с другими системами).

• Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕДОПУСТИМО делать зависимыми от взломанных криптографических алгоритмов (например, MD4, MD5, single DES, RC4, Dual_EC_DRBG) или использовать режимы шифрования, которые не подходят для контекста, если только они не требуются для интероперабельности протокола (поддерживающего самую новую версию стандарта на этот протокол, широко распространенного в сетевой экосистеме, причем эта экосистема требует использования данного алгоритма или режима, не предлагая более безопасных альтернатив). В документации НЕОБХОДИМО описать все связанные с этим риски безопасности и все известные способы смягчения рисков, если данные алгоритмы или режимы действительно нужны для совместимости с другими реализациями этого протокола. {Разрешено N/A} ^{[crypto_working]}

  Подробности:

  Режим ECB почти никогда не подходит, потому что внутри зашифрованного ECB текста обнаруживаются идентичные блоки, как можно видеть на примере «пингвина ECB», а режим CTR часто неприемлем, поскольку не выполняет аутентификацию и приводит к дубликатам, контекста, если состояние ввода повторяется. Во многих случаях лучше всего выбирать режим алгоритма с блочным шифром, предназначенный для сочетания секретности и аутентификации, например, Galois / Counter Mode (GCM) и EAX. Проекты МОГУТ разрешать пользователям включать сломанные механизмы, где это необходимо для совместимости, но в таких случаях пользователи знают, что они это делают.

• Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕ СЛЕДУЕТ делать зависимыми от криптографических алгоритмов или режимов с известными серьезными слабостями (например, криптографический алгоритм хеширования SHA-1 или режим CBC в SSH). {Разрешено N/A} ^{[crypto_weaknesses]}

  Подробности:

  Проблемы, связанные с режимом CBC в SSH, обсуждаются в описании уязвимости CERT: SSH CBC.

• В механизмах безопасности в программном обеспечении, создаваемом проектом, СЛЕДУЕТ реализовать совершенную прямую секретность для протоколов соглашений о ключах, чтобы ключ сеанса, произведенный из набора долгосрочных ключей, не мог быть скомпрометирован, если один из долгосрочных ключей скомпрометирован в будущем. {Разрешено N/A} ^[crypto_pfs]
• Если ПО, создаваемое проектом, требует хранить пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с солью для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, PBKDF2, Bcrypt или Scrypt). См. также: OWASP Password Storage Cheat Sheet (на англ.). {Разрешено N/A} ^{[crypto_password_storage]}

  Подробности:

  Этот критерий применяется только тогда, когда программное обеспечение требует проверки внешних пользователей с использованием паролей (так называемая входящая аутентификация), таких как серверные веб-приложения. Он не применяется в тех случаях, когда программное обеспечение хранит пароли для аутентификации в других системах (исходящая аутентификация; например, программное обеспечение реализует клиент для какой-либо другой системы), поскольку по крайней мере части этого программного обеспечения должны часто обращаться к нехешированному паролю.

• Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ генерировать все криптографические ключи и временные значения с использованием криптографически безопасного генератора случайных чисел; НЕДОПУСТИМО делать это с использованием генераторов, которые криптографически небезопасны. {Разрешено N/A} ^{[crypto_random]}

  Подробности:

  Криптографически безопасный генератор случайных чисел может быть аппаратным генератором случайных чисел или криптографически безопасным генератором псевдослучайных чисел (CSPRNG), использующим такие алгоритмы как Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow или Fortuna. Примеры вызовов защищенных генераторов случайных чисел включают java.security.SecureRandom в Java и window.crypto.getRandomValues в JavaScript. Примеры вызовов небезопасных генераторов случайных чисел включают java.util.Random в Java и Math.random в JavaScript.

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

• Проект ОБЯЗАН использовать механизм доставки, устойчивый против атак посредника (MITM). Приемлемо использование https или ssh + scp. ^{[delivery_mitm]}

  Подробности:

  Еще более сильным механизмом является выпуск программного обеспечения в виде пакетов, подписанных цифровой подписью, поскольку это смягчает атаки на систему распространения, но это работает только в том случае, если пользователи могут быть уверены, что открытые ключи для подписей верны и если пользователи действительно проверяют подпись.

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

  Подробности:

  Эти хеши могут быть изменены при передаче.

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

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

  Подробности:

  Уязвимость должна быть исправлена ​​и выпущена самим проектом (патчи могут быть разработаны в другом месте). Уязвимость считается опубликованной (для цели данного критерия) после того, как она имеет CVE с описанием, бесплатно доступным для общественности, (например, в National Vulnerability Database) или когда проект был проинформирован, и информация была опубликована для общественности (возможно, самим проектом). Уязвимость имеет среднюю и высокую степень серьезности, если ее базовая оценка по CVSS 2.0 равна 4 или выше. Примечание. Это означает, что пользователи могут оставаться уязвимыми для всех злоумышленников по всему миру на срок до 60 дней. Этот критерий часто намного легче выполнить, чем рекомендует Google в Rebooting responsible disclosure, поскольку Google рекомендует, чтобы 60-дневный период начинался, когда проект был уведомлен, даже если отчет не является общедоступным.

• Проектам СЛЕДУЕТ оперативно исправлять критические уязвимости после сообщения о них. ^{[vulnerabilities_critical_fixed]}

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

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

  Подробности:

  Проект МОЖЕТ пропускать «шаблонные» учетные данные для тестирования и несущественные базы данных, при условии что они не предназначены для ограничения общего доступа.

Анализ

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

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

  Подробности:

  Средство анализа статического кода анализирует программный код (как исходный код, промежуточный код или исполняемый файл), не выполняя его с конкретными входами. Для целей этого критерия предупреждения компилятора и «безопасные» языковые режимы не считаются инструментами анализа статического кода (они обычно избегают глубокого анализа, поскольку скорость имеет жизненно важное значение). Примеры таких статических инструментов анализа кода включают cppcheck (C, C++), статический анализатор Clang (C, C++), SpotBugs (Java), FindBugs (Java; включая FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Анализатор качества Coverity, SonarQube, Codacy и статический анализатор кода HP Enterprise Fortify. Более крупные списки инструментов можно найти в таких местах, как Wikipedia list of tools for static code analysis, OWASP information on static code analysis, NIST list of source code security analyzers и Wheeler's list of static analysis tools. Если для используемого языка(ов) реализации нет доступных инструментов статического анализа на свободном ПО, выберите «неприменимо» (N/A).

• ЖЕЛАТЕЛЬНО включать по крайней мере в один из инструментов статического анализа, используемых для критерия static_analysis, правила или подходы для поиска распространенных уязвимостей в анализируемом языке или среде. {Разрешено N/A} ^{[static_analysis_common_vulnerabilities]}

  Подробности:

  Инструменты статического анализа, специально предназначенные для поиска распространенных уязвимостей, с большей вероятностью найдут их. Тем не менее, использование любых статических инструментов обычно помогает найти какие-то проблемы, поэтому мы предлагаем, но не требуем этого для получения базового значка.

• Все уязвимости со средней и высокой степенью серьезности, обнаруженные при статическом анализе кода, НЕОБХОДИМО своевременно исправлять после их подтверждения. {Разрешено N/A} ^{[static_analysis_fixed]}

  Подробности:

  Уязвимость имеет среднюю и высокую степень серьезности, если ее оценка по CVSS 2.0 - 4 или выше.

• ЖЕЛАТЕЛЬНО выполнять анализ статического исходного кода при каждом коммите или по крайней мере ежедневно. {Разрешено N/A} ^{[static_analysis_often]}

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

• ЖЕЛАТЕЛЬНО применять по крайней мере один инструмент динамического анализа к любой предлагаемой основной (major) версии программного обеспечения перед ее выпуском . ^{[dynamic_analysis]}

  Подробности:

  Инструмент динамического анализа проверяет программное обеспечение, выполняя его с конкретными входными данными. Например, проект МОЖЕТ использовать инструмент фаззинг-тестирования (например, American Fuzzy Lop) или сканер веб-приложений (например, OWASP ZAP или w3af). В некоторых случаях проект OSS-Fuzz может быть готов применить фаззинг-тестирование к вашему проекту. Для целей этого критерия инструмент динамического анализа должен каким-то образом варьировать исходные данные, чтобы искать проблемы разного рода или быть автоматическим набором тестов с покрытием веток исполнения не менее 80%. Страница Википедии о динамическом анализе и cтраница OWASP о фаззинг-тестировании указывают некоторые инструменты динамического анализа. Использование инструмента/ов анализа МОЖЕТ, но не обязано быть сосредоточено на поиске уязвимостей в безопасности.

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

  Подробности:

  Примерами механизмов обнаружения проблем безопасности памяти являются Address Sanitizer (ASAN) (доступен в GCC и LLVM), Memory Sanitizer и valgrind. Другие потенциально используемые инструменты включают Thread Sanitizer и Undefined Behavior Sanitizer. Достаточно широкое использование утверждений (assertions) тоже может быть приемлемо.

• ЖЕЛАТЕЛЬНО включать в ПО, создаваемое проектом, достаточно много утверждений (assertions) времени выполнения, проверяемых при динамическом анализе. Во многих случаях эти утверждения не должны попадать в сборки под эксплуатацию (production). ^{[dynamic_analysis_enable_assertions]}

  Подробности:

  Этот критерий не предполагает включения утверждений на этапе эксплуатации; решение об этом полностью лежит на проекте и его пользователях. Вместо этого критерий направлен на улучшение обнаружения ошибок во время динамического анализа перед развертыванием. Использование утверждений при эксплуатации полностью отличается от такового во время динамического анализа (например, при тестировании). В некоторых случаях включать утверждения при эксплуатации крайне неразумно (особенно в компонентах с высокой степенью целостности). Существует множество аргументов против включения утверждений в выпускаемых сборках: например, библиотеки не должны вызывать сбой при вызове, присутствие утверждений может привести к отклонению магазинами приложений и/или активация их при рабочем использовании может привести к раскрытию частных данных, таких как закрытые ключи. Помните, что во многих дистрибутивах Linux NDEBUG не определен, поэтому C/C++assert() в таких рабочих средах по умолчанию будет включен. Может быть важно использовать другой механизм утверждений или определить NDEBUG для эксплуатации в этих средах.

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

  Подробности:

  Если вы не используете динамический анализ кода и, следовательно, не обнаружили уязвимостей таким способом, выберите «неприменимо» (N/A). Степень серьезности уязвимости считается средней или выше, если уязвимость имеет среднюю или выше базовую оценку по Common Vulnerability Scoring System (CVSS). В версиях CVSS с 2.0 по 3.1 это соответствует оценке 4.0 и выше. Проекты могут использовать оценку CVSS опубликованную в любой широко используемой базе данных по уязвимостям (такой как National Vulnerability Database) используя самую новую версию CVSS доступную в этой базе данных. Вместо этого проекты могут сами вычислять серьезность используя последнюю версию CVSS на момент раскрытия уязвимости, если вводные для вычисления раскрываются вместе с публикацией уязвимости.

Silver

Основы

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

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

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

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

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

• Проекту СЛЕДУЕТ иметь юридический механизм, через который все авторы содержательных взносов в ПО проекта подтверждают, что они имеют законное право на внесение этих взносов. Самый распространенный и легко реализуемый подход для этого заключается в использовании Developer Certificate of Origin (DCO), при котором пользователи добавляют строку "signed-off-by" в свои коммиты, а проект ссылается на веб-сайт DCO. Но этот механизм МОЖЕТ быть реализован и в качестве Лицензионного соглашения с участниками (Contributor License Agreement, CLA) или другого правового механизма. {Требуется URL выполнения} ^[dco]

  Подробности:

  DCO является рекомендуемым механизмом, потому что его легко реализовать и отслеживать в исходном коде, а git напрямую поддерживает функцию "signed-off" при помощи "commit -s". Для большей эффективности лучше всего, если проектная документация объясняет, что означает "signed-off" для этого проекта. CLA - это юридическое соглашение, которое определяет условия, на которых произведения умственного труда были лицензированы для организации или проекта. Соглашение о назначении участника (contributor assignment agreement, CAA) является юридическим соглашением, которое передает права на произведения умственного труда другой стороне; проекты не обязаны иметь CAA, поскольку CAA увеличивает риск того, что потенциальные участники не будут вносить свой вклад, особенно если получатель является коммерческой организацией. Лицензии CLA от Apache Software Foundation (лицензия отдельного участника и корпоративное соглашение CLA) являются примерами CLA для проектов, считающих, что риски от такого рода CLA для проекта меньше, чем их преимущества.

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

  Подробности:

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

• Проект ОБЯЗАН определить правила поведения и разместить эти правила в стандартном месте. {Требуется URL выполнения} ^{[code_of_conduct]}

  Подробности:

  Проекты могут повысить цивилизованность их сообщества и установить ожидания относительно приемлемого поведения, приняв правила поведения. Это может помочь избежать проблем до их возникновения и сделать проект более привлекательным местом, поощряющим участие. Правила должны быть сосредоточены только на поведении в сообществе или на рабочем месте проекта. Примерами правил поведения являются правила конфликтов на проекте ядра Linux, Contributor Covenant Code of Conduct, Кодекс поведения Debian, Ubuntu Code of Conduct, Правила поведения проекта Fedora, GNOME Code Of Conduct, KDE Community Code of Conduct">, Python Community Code of Conduct, The Ruby Community Conduct Guideline и The Rust Code of Conduct.

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

  Подробности:

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

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

  Подробности:

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

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

• Проект ОБЯЗАН иметь задокументированный долгосрочный план (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]}

  Подробности:

  Достижением считается любой набор внешних критериев, над выполнением которых проект специально работал, включая некоторые значки. Эта информация не обязательно должна находиться на главной странице веб-сайта проекта. Проект с использованием GitHub может помещать достижения на главную страницу хранилища кода, добавляя их в файл README.

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

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

  Подробности:

  Для веб-приложений см. Руководство по обеспечению доступности веб-контента (WCAG) 2.0 и его поддерживающий документ Understanding WCAG 2.0; см. также W3C accessibility information. Для приложений с графическим интерфейсом рассмотрите использование соответствующих вашему окружению рекомендаций по обеспечению доступности (таких как GNOME, KDE, XFCE, Android, iOS, Mac и Windows (на русском)). Некоторые приложения с текстовым интерфейсом пользователя (например, программы на ncurses) могут сделать некоторые вещи, чтобы сделать себя более доступными (например, параметр `force-arrow-cursor` в `alpine`). Большинство приложений командной строки довольно общедоступны как они есть. Этот критерий часто неприменим, например, для библиотек программ. Вот несколько примеров действий или проблем, которые следует учитывать:

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

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

  Подробности:

  Локализация "относится к адаптации продукта, приложения или содержимого документа для соответствия языковым, культурным и другим требованиям конкретного целевого рынка (языковому стандарту)". Интернационализация - это «проектирование и разработка продукта, приложения или содержимого документа, которые позволяют легкую локализацию под целевые аудитории, различающиеся по культуре, региону или языку». (См. «Локализация по сравнению с интернационализацией» на веб-сайте W3C.) Чтобы ПО соответствовало этому критерию, достаточно лишь интернационализации. Не требуется локализация для другого конкретного языка, так как после того, как программное обеспечение было интернационализировано, другие могут работать над локализацией.

Другое

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

  Подробности:

  Примечание: использование GitHub автоматически выполняет этот критерий. Этот критерий применяется только к паролям, используемым для аутентификации внешних пользователей на сайтах проекта (т.н. входящей аутентификации). Если сайты проекта должны подключаться к другим сайтам (т.н. исходящая аутентификация), им может потребоваться хранить аутентифицирующие данные (пароли, ключи) для этой цели как-то иначе (поскольку хранение контрольной суммы для этой цели бесполезно). В данном случае критерий crypto_password_storage применяется к сайтам проекта, по аналогии с критерием sites_https.

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

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

• Проект ОБЯЗАН поддерживать наиболее часто используемые старые версии продукта или предоставлять возможность простого перехода на более новые версии (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]}

  Подробности:

  Этот критерий тесно связан с критерием vulnerability_report_process, который требует документированного способа для сообщения об уязвимостях. Он также связан с vulnerability_report_response, который требует ответа на отчеты об уязвимостях в течение определенного периода времени.

Качество

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

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

  Подробности:

  В большинстве случаев это делается путем ссылки на некоторые существующие руководства по стилю, возможно, с перечислением различий. Эти руководства по стилю могут включать в себя способы повышения удобочитаемости и способы снижения вероятности дефектов (включая уязвимости). Многие языки программирования имеют один или несколько широко используемых руководств по стилю. Примеры руководств по стилю включают Руководство по стилю Google и Стандарты кодирования SEI CERT.

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

  Подробности:

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

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

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

  Подробности:

  Должно быть легко включить специальные функции сборки, такие как Address Sanitizer (ASAN), или выполнить рекомендации по упрочнению от дистрибутивов (например, путем простого включения флагов компилятора для этого).

• В системах сборки и установки СЛЕДУЕТ сохранять отладочную информацию, если передаваемые флаги требуют этого (например, не используется «install -s»). Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, для типичных библиотек JavaScript), . {Требуется обоснование N/A} {Требуется обоснование выполнения} ^{[build_preserve_debug]}

  Подробности:

  Например, установка CFLAGS (C) или CXXFLAGS (C++) должна создавать соответствующую информацию для отладки, если эти языки используются, и ее не следует удалять во время установки. Отладочная информация необходима для поддержки и анализа, а также полезна для того, чтобы определить наличие упрочняющих функций в скомпилированных двоичных файлах.

• НЕДОПУСТИМО, чтобы система сборки ПО, создаваемого проектом, рекурсивно собирала подкаталоги, если в подкаталогах есть кросс-зависимости. Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, типичные библиотеки JavaScript). {Требуется обоснование N/A} {Требуется обоснование выполнения} ^{[build_non_recursive]}

  Подробности:

  Информация о внутренних зависимостях системы сборки проекта должна быть точной, в противном случае изменения в проекте могут быть включены в сборку неправильно. Неправильные сборки могут привести к дефектам (включая уязвимости). Общей ошибкой в ​​больших системах сборки является использование «рекурсивной сборки» или «рекурсивного make», то есть иерархии подкаталогов, содержащих исходные файлы, где каждый подкаталог собирается независимо. Если только каждый из подкаталогов не является полностью независимым, это ошибка, потому что информация о зависимостях неверна.

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

  Подробности:

  Пользователи GCC и clang могут найти полезной опцию -frandom-seed; в некоторых случаях это может быть разрешено путем задания определенного порядка сортировки. Дополнительные предложения можно найти на сайте Reproducible builds.

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

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

  Подробности:

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

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

  Подробности:

  Это МОЖЕТ быть реализовано при помощи сгенерированного контейнера или установочных сценариев. Внешние зависимости обычно устанавливаются путем вызова системных и/или языковых пакетов, как описано в критерии external_dependencies.

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

• Проект ОБЯЗАН перечислять внешние зависимости в машинночитаемом виде. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[external_dependencies]}

  Подробности:

  Обычно это делается при помощи инструкций для диспетчера пакетов и/или системы сборки. Обратите внимание, что это помогает реализовать критерий installation_development_quick.

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

  Подробности:

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

• Проект ОБЯЗАН:
  1. позволять легко идентифицировать и обновлять повторно используемые компоненты, поддерживаемые извне; или
  2. использовать стандартные компоненты, предоставляемые системой или языком программирования.
  В этом случае, если уязвимость обнаружена в повторно используемом компоненте, будет легко обновить этот компонент. {Требуется обоснование N/A} {Требуется обоснование выполнения} ^{[updateable_reused_components]}

  Подробности:

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

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

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

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

  Подробности:

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

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

  Подробности:

  Для измерения тестового покрытия существует множество средств на СПО, включая gcov/lcov, Blanket.js, Istanbul и JCov. Обратите внимание, что соответствие этому критерию не является гарантией того, что тестовый пакет является исчерпывающим; вместо этого, несоответствие этому критерию является сильным индикатором плохого набора тестов.

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

• Проект ОБЯЗАН иметь формальную задокументированную политику о том, что при добавлении существенной новой функциональности НЕОБХОДИМО добавлять тесты для новой функциональности в набор автоматических тестов. {Требуется обоснование 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 является распространенной ошибкой. Для дальнейших сведений см. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" Мартина Георгиева и др. и "Do you trust this application?" Майкла Катанзаро.

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

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

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

  Подробности:

  Результаты проекта включают как исходный код, так и любые сгенерированные результаты, если это применимо (например, исполняемые файлы, пакеты и контейнеры). Сгенерированные результаты МОГУТ быть подписаны отдельно от исходного кода. Подписывание МОЖЕТ быть реализовано как подписанные теги git (с использованием криптографических цифровых подписей). Проекты МОГУТ предоставлять генерируемые результаты отдельно от таких инструментов, как git, но в этих случаях отдельные результаты ОБЯЗАНЫ быть отдельно подписаны.

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

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

• В результатах проекта НЕОБХОДИМО проверять любой ввод из потенциально ненадежных источников, чтобы убедиться, что они действительны (*белый список*), и отклонять недействительный ввод, если вообще есть какие-либо ограничения на данные. {Требуется обоснование N/A} {Требуется обоснование выполнения} ^{[input_validation]}

  Подробности:

  Обратите внимание, что сравнения ввода со списком «плохих форматов» (также известным как *черный список*) обычно недостаточно, потому что злоумышленники часто могут обойти черный список. В частности, числа преобразуются во внутренние форматы, а затем проверяются, находятся ли они между их минимальным и максимальным (включительно), а текстовые строки проверяются, чтобы убедиться, что они являются допустимыми текстовыми шаблонами (например, действительный UTF-8, длина, синтаксис и т. д.). От некоторых данных может требоваться, чтобы они были «хоть чем-нибудь» (например, загрузчик файлов), но такое обычно случается редко.

• В ПО, создаваемом проектом, СЛЕДУЕТ использовать механизмы упрочнения безопасности (hardening), чтобы дефекты программного обеспечения с меньшей вероятностью приводили к уязвимостям в безопасности. {Требуется обоснование N/A} {Требуется обоснование выполнения} ^[hardening]

  Подробности:

  Механизмы упрочнения могут включать HTTP-заголовки, такие как Content Security Policy (CSP), флаги компилятора для противостояния атакам (например, -fstack-protector) или флаги компилятора, устраняющие неопределенное поведение. Для наших целей политика наименьших привилегий не считается механизмом упрочнения (использовать наименьшие достаточные привилегии важно, но этому посвящён отдельный критерий).

• Проект ОБЯЗАН предоставить обоснование того, что требования безопасности соблюдаются проектом. В обоснование НЕОБХОДИМО включить: описание модели угроз, четкое указание границ доверия, доказательство того, что использовались принципы безопасного дизайна, и доказательство того, что слабости в безопасности реализации нейтрализованы. {Требуется URL выполнения} ^{[assurance_case]}

  Подробности:

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

Анализ

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

• Проект ОБЯЗАН использовать хотя бы один инструмент статического анализа с правилами или подходами для поиска распространенных уязвимостей в анализируемом языке или окружении, если есть хотя бы один инструмент на СПО, который может реализовать этот критерий на выбранном языке. {Требуется обоснование 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]}

  Подробности:

  Соавторы связаны, если они оплачиваются работой одной и той же организации (как работник или подрядчик), и организация может выиграть от результатов проекта. Финансовые гранты не считаются находящимися в одной организации, если они проходят через другие организации (например, гранты на науку, выплачиваемые различным организациям из общего правительства или источника НПО, не приводят к тому, что вкладчики могут быть связаны). Соавтор считается значительным, если за последний год он(а) внес(ла) заметный вклад в проект. Примерами хороших показателей значительного соавтора являются: написано не менее 1000 строк кода, внесено 50 коммитов или предоставлено не менее 20 страниц документации.

Другое

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

  Подробности:

  Это МОЖНО сделать, включив следующее в комментарий рядом с началом каждого файла: «Copyright [год создания этого проекта или контента] - [последний год изменений], [основатель проекта] and the [название проекта] contributors.»

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

  Подробности:

  Это МОЖЕТ также быть сделано путем указания лицензии на естественном языке. Проект МОЖЕТ также включать стабильный URL-адрес, указывающий на текст лицензии, или полный текст лицензии. Обратите внимание, что критерий license_location требует помещать лицензию проекта в стандартном расположении. См. этот учебник SPDX для получения дополнительных сведений об SPDX-выражениях лицензии. Обратите внимание на связь с критерием copyright_per_file, содержимое для которого обычно предшествует информации о лицензии.

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

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

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

  Подробности:

  Это обозначение обычно делается путем маркировки выбранных проблем в трекере одним или несколькими тегами, которые использует проект для этой цели, например up-for-grabs, «только для новичков», «Небольшое исправление», «микрозадача» или IdealFirstBug. Эти новые задачи не обязательно требуют добавления функциональности; это может быть улучшение документации, добавление тестовых кейсов или что-то еще, что помогает проекту и помогает участнику лучше понять проект.

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

  Подробности:

  Механизм ДФА, который соответствует этому критерию, может быть приложением для генерации временных одноразовых паролей (Time-based One-Time Password, TOTP), которое автоматически генерирует код аутентификации, меняющийся через определенный промежуток времени. Обратите внимание, что GitHub поддерживает TOTP.

Качество

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

• Проект ОБЯЗАН документировать свои требования по ревью кода, в том числе, как проводится ревью кода, что необходимо проверять и что необходимо для приемлемости кода. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[code_review_standards]}

  Подробности:

  См. также критерии two_person_review и contrib_requirements.

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

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

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

  Подробности:

  Воспроизводимая сборка означает, что несколько сторон могут независимо повторить процесс генерации информации из исходных файлов и получить аналогичный результат с точностью до бита. В некоторых случаях воспроизводимости можно достичь путем принудительного выставления окружения. Разработчики JavaScript могут рассмотреть возможность использования npm shrinkwrap и webpack OccurenceOrderPlugin. Пользователи GCC и clang могут найти полезной опцию -frandom-seed. Среда сборки (включая набор инструментов) часто может быть определена для внешних сторон путём указания криптографической суммы (hash) для конкретного контейнера или виртуальной машины, которые они могут использовать для пересборки. В проекте Reproducible Builds есть документация о том, как это сделать.

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

• Набор тестов ОБЯЗАН запускаться стандартным способом для этого языка. {Требуется 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]}

  Подробности:

  Обратите внимание, что GitHub отвечает этому критерию. Такие сайты как https://securityheaders.io/ могут быстро проверить использование. Ключевыми заголовками для упрочнения являются: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (выставленный в «nosniff»), X-Frame-Options и X-XSS-Protection. Статические веб-сайты без возможности входа в систему через веб-страницы могут опускать упрочняющие HTTP-заголовки CSP и X-XSS-Protection, поскольку в этом случае эти заголовки менее эффективны.

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

• Проект ОБЯЗАН иметь проверку безопасности за последние 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]}

  Подробности:

  Обеспечьте многофакторную аутентификацию для системы контроля версий проекта, требуя от соавторов предоставления второй формы аутентификации при доступе к конфиденциальным данным или изменении настроек репозитория. Для этой меры приемлемы passkeys (ключи доступа).

• При добавлении нового соавтора система контроля версий ДОЛЖНА требовать ручного назначения прав доступа или по умолчанию ограничивать права доступа соавтора до минимально доступных привилегий. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_ac_02_01]}

  Подробности:

  Большинство публичных систем контроля версий настроены таким образом. Убедитесь, что система контроля версий проекта всегда назначает минимально доступные права доступа соавторам по умолчанию при добавлении, предоставляя дополнительные права доступа только при необходимости.

• При попытке прямого коммита в основную ветку проекта механизм принудительного исполнения ДОЛЖЕН предотвращать применение изменения. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_ac_03_01]}

  Подробности:

  Если VCS централизована, установите защиту ветки на основную ветку в VCS проекта. В качестве альтернативы используйте децентрализованный подход, как в ядре Linux, где изменения сначала предлагаются в другом репозитории, а слияние изменений в основной репозиторий требует специального отдельного действия.

• Когда предпринимается попытка удалить основную ветку проекта, система контроля версий ОБЯЗАНА рассматривать это как деликатное действие и требовать явного подтверждения намерения. {Требуется обоснование 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]}

  Подробности:

  Настройте веб-сайты и системы контроля версий проекта на использование зашифрованных каналов, таких как SSH или HTTPS для передачи данных. Убедитесь, что все инструменты и домены, на которые ссылается документация проекта, доступны только через зашифрованные каналы.

• Когда проект указывает URI как официальный канал распространения, этот URI ОБЯЗАН передаваться исключительно с использованием зашифрованных каналов. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_03_02]}

  Подробности:

  Настройте конвейер выпуска проекта так, чтобы он получал данные только с веб-сайтов, API-ответов и других служб, которые используют зашифрованные каналы, такие как SSH или HTTPS для передачи данных.

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

  Подробности:

  Настройте .gitignore или эквивалент для исключения файлов, которые могут содержать конфиденциальную информацию. Используйте pre-commit хуки и автоматизированные инструменты сканирования для обнаружения и предотвращения включения конфиденциальных данных в коммиты.

• Когда проект сделал релиз, документация проекта ОБЯЗАНА включать руководства пользователя для всего базового функционала. {Требуется обоснование 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]}

  Подробности:

  Создайте файл CONTRIBUTING.md или директорию CONTRIBUTING/ для описания процесса внесения вклада, включая шаги для отправки изменений и взаимодействия с сопровождающими проекта.

• Пока проект активен, лицензия на исходный код ОБЯЗАНА соответствовать определению Open Source от OSI или определению свободного программного обеспечения от FSF. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_le_02_01]}

  Подробности:

  Добавьте файл LICENSE в репозиторий проекта с лицензией, которая является одобренной лицензией Open Source Initiative (OSI), или свободной лицензией, одобренной Фондом свободного программного обеспечения (FSF). Примеры таких лицензий включают MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL) и GNU General Public License (GPL). Выпуск в публичное достояние соответствует этому контролю, если нет других ограничений, таких как патенты.

• Пока активен, лицензия для выпущенных программных активов ОБЯЗАНА соответствовать определению открытого ПО по OSI или определению свободного ПО по FSF. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_le_02_02]}

  Подробности:

  Если с выпущенными программными активами включена другая лицензия, убедитесь, что это одобренная лицензия Open Source Initiative (OSI) или свободная лицензия, одобренная Free Software Foundation (FSF). Примеры таких лицензий включают MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL) и GNU General Public License (GPL). Обратите внимание, что лицензия для выпущенных программных активов может отличаться от лицензии для исходного кода.

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

  Подробности:

  Включите лицензию исходного кода проекта в файл LICENSE проекта, файл COPYING или директорию LICENSE/, чтобы обеспечить видимость и ясность условий лицензирования. Имя файла МОЖЕТ иметь расширение. Если у проекта несколько репозиториев, убедитесь, что каждый репозиторий включает файл лицензии.

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

  Подробности:

  Включите лицензию выпущенных программных активов проекта в выпущенный исходный код или в файл LICENSE, файл COPYING или директорию LICENSE/ рядом с соответствующими выпущенными активами, чтобы обеспечить видимость и ясность условий лицензирования. Имя файла МОЖЕТ иметь расширение. Если у проекта несколько репозиториев, убедитесь, что каждый репозиторий включает файл лицензии.

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

  Подробности:

  Используйте общую систему контроля версий (VCS), такую как GitHub, GitLab или Bitbucket. Убедитесь, что репозиторий доступен для публичного чтения. Избегайте дублирования или зеркалирования репозиториев, если только хорошо видимая документация не разъясняет первичный источник. Избегайте частых изменений репозитория, которые могут повлиять на URL репозитория. Убедитесь, что репозиторий публичный.

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

  Подробности:

  Используйте общую VCS, такую как GitHub, GitLab или Bitbucket, для поддержания публично доступной истории коммитов. Избегайте сжатия или перезаписи коммитов таким образом, чтобы это скрывало автора любых коммитов.

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

  Подробности:

  Это может быть в виде файла менеджера пакетов или файла языковых зависимостей, перечисляющего все прямые зависимости, такие как package.json, Gemfile или go.mod.

• Пока активна, документация проекта ОБЯЗАНА содержать список всех кодовых баз, которые считаются подпроектами. {Требуется обоснование 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]}

  Подробности:

  Создайте файл security.md (или с аналогичным именем), который содержит контакты по вопросам безопасности для проекта.

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

Общее

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

• Когда задача CI/CD выполняется без указания прав доступа, система CI/CD ОБЯЗАНА по умолчанию назначать задаче минимальные права, предоставленные в конвейере. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_ac_04_01]}

  Подробности:

  Настройте параметры проекта для назначения минимальных доступных прав новым конвейерам по умолчанию, предоставляя дополнительные права только при необходимости для конкретных задач.

• Когда создается официальный выпуск, этому выпуску ОБЯЗАН быть назначен уникальный идентификатор версии. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_02_01]}

  Подробности:

  Присваивайте уникальный идентификатор версии каждому выпуску, создаваемому проектом, следуя согласованному соглашению о наименовании или схеме нумерации. Примеры включают SemVer, CalVer или идентификатор коммита git.

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

  Подробности:

  Убедитесь, что все выпуски содержат описательный журнал изменений. Рекомендуется обеспечить, чтобы журнал изменений был читаемым человеком и содержал более подробные сведения, чем сообщения коммитов, такие как описания влияния на безопасность или релевантность для различных сценариев использования. Для обеспечения машиночитаемости размещайте содержимое под заголовком markdown, таким как "## Changelog".

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

  Подробности:

  Используйте общие инструменты для вашей экосистемы, такие как менеджеры пакетов или инструменты управления зависимостями для загрузки зависимостей во время сборки. Это может включать использование файла зависимостей, lock-файла или манифеста для указания требуемых зависимостей, которые затем подключаются системой сборки.

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

  Подробности:

  Подписывайте все выпущенные программные активы во время сборки с использованием криптографической подписи или аттестаций, таких как подпись GPG или PGP, подписи Sigstore, происхождение SLSA или SLSA VSA. Включите криптографические хеши каждого актива в подписанный манифест или файл метаданных.

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

  Подробности:

  Рекомендуется публиковать эту информацию вместе с технической документацией и документацией по дизайну проекта в общедоступном ресурсе, таком как репозиторий исходного кода, веб-сайт проекта или другой канал.

• Пока проект активен, документация проекта ОБЯЗАНА включать список членов проекта с доступом к критическим ресурсам. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_gv_01_01]}

  Подробности:

  Документируйте участников проекта и их роли с помощью таких артефактов, как members.md, governance.md, maintainers.md или аналогичного файла в репозитории исходного кода проекта. Это может быть просто включение имен или учетных записей в список сопровождающих или более сложное в зависимости от управления проектом.

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

  Подробности:

  Документируйте участников проекта и их роли с помощью таких артефактов, как members.md, governance.md, maintainers.md или аналогичного файла в репозитории исходного кода проекта.

• Пока проект активен, документация проекта ОБЯЗАНА включать руководство для участников кода, которое включает требования к приемлемым вкладам. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_gv_03_02]}

  Подробности:

  Расширьте содержимое CONTRIBUTING.md или CONTRIBUTING/ в документации проекта, чтобы изложить требования к приемлемым вкладам, включая стандарты кодирования, требования к тестированию и руководства по отправке для участников кода. Рекомендуется, чтобы это руководство было источником истины как для участников, так и для утверждающих.

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

  Подробности:

  Включите DCO в репозиторий проекта, требуя от участников кода утверждать, что они имеют законное право вносить соответствующий вклад в каждом коммите. Используйте проверку статуса, чтобы убедиться, что утверждение сделано. CLA также удовлетворяет этому требованию. Некоторые системы контроля версий, такие как GitHub, могут включать это в условия обслуживания платформы.

• При внесении коммита в основную ветку все автоматические проверки статуса для коммитов ДОЛЖНЫ пройти успешно или быть явно обойдены вручную. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_03_01]}

  Подробности:

  Настройте систему контроля версий проекта таким образом, чтобы все автоматические проверки статуса должны были пройти успешно или требовать ручного подтверждения перед тем, как коммит может быть объединен с основной веткой. Рекомендуется НЕ настраивать необязательные проверки статуса как требование успешного прохождения или провала, которые утверждающие могут быть склонны обойти.

• Перед принятием коммита в проекте ДОЛЖЕН выполняться хотя бы один автоматизированный набор тестов в конвейере CI/CD для обеспечения соответствия изменений ожиданиям. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_06_01]}

  Подробности:

  Автоматизированные тесты должны выполняться перед каждым объединением с основной веткой. Набор тестов должен выполняться в конвейере CI/CD, и результаты должны быть видны всем участникам. Набор тестов должен выполняться в согласованной среде и таким образом, чтобы участники могли выполнять тесты локально. Примеры наборов тестов включают модульные тесты, интеграционные тесты и сквозные тесты.

• Когда проект выпустил релиз, документация проекта ДОЛЖНА включать проектную документацию, демонстрирующую все действия и участников в системе. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_sa_01_01]}

  Подробности:

  Включите в документацию проекта проектные описания, объясняющие действия и участников. Участники включают любую подсистему или сущность, которая может повлиять на другой сегмент в системе. Убедитесь, что эта информация обновляется для новых функций или критических изменений.

• Когда проект выпустил релиз, документация проекта ДОЛЖНА включать описания всех внешних программных интерфейсов выпущенных программных активов. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_sa_02_01]}

  Подробности:

  Документируйте все программные интерфейсы (API) выпущенных программных активов, объясняя, как пользователи могут взаимодействовать с программным обеспечением и какие данные ожидаются или производятся. Убедитесь, что эта информация обновляется для новых функций или критических изменений.

• Когда проект выпустил релиз, проект ДОЛЖЕН провести оценку безопасности для понимания наиболее вероятных и значимых потенциальных проблем безопасности, которые могут возникнуть в программном обеспечении. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_sa_03_01]}

  Подробности:

  Проведение оценки безопасности информирует как членов проекта, так и конечных потребителей о том, что проект понимает, какие проблемы могут возникнуть в программном обеспечении. Понимание того, какие угрозы могут быть реализованы, помогает проекту управлять рисками и справляться с ними. Эта информация полезна для конечных потребителей для демонстрации компетентности в области безопасности и практик проекта. Убедитесь, что эта информация обновляется для новых функций или критических изменений.

• Пока проект активен, документация проекта ДОЛЖНА включать политику координированного раскрытия уязвимостей (CVD) с четко определенными сроками ответа. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_01_01]}

  Подробности:

  Создайте файл SECURITY.md в корневом каталоге, описывающий политику проекта для координированного раскрытия уязвимостей. Включите метод сообщения об уязвимостях. Установите ожидания относительно того, как проект будет реагировать и решать сообщенные проблемы.

• Пока проект активен, документация проекта ДОЛЖНА предоставлять средства для приватного сообщения об уязвимостях непосредственно контактам по безопасности в проекте. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_03_01]}

  Подробности:

  Предоставьте средства для того, чтобы исследователи безопасности могли приватно сообщать об уязвимостях в проект. Это может быть специальный адрес электронной почты, веб-форма, специализированные инструменты системы контроля версий, адреса электронной почты контактов по безопасности или другие методы.

• Пока проект активен, документация проекта ДОЛЖНА публично публиковать данные об обнаруженных уязвимостях. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_04_01]}

  Подробности:

  Предоставляйте информацию об известных уязвимостях в предсказуемом публичном канале, таком как запись CVE, запись в блоге или другом носителе. По мере возможности эта информация должна включать затронутые версии, как потребитель может определить, уязвим ли он, и инструкции по смягчению последствий или исправлению.

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

Общее

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

• Когда задаче назначаются разрешения в конвейере CI/CD, исходный код или конфигурация ДОЛЖНЫ назначать только минимальные привилегии, необходимые для соответствующей деятельности. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_ac_04_02]}

  Подробности:

  Настройте конвейеры CI/CD проекта так, чтобы по умолчанию назначать пользователям и службам наименьшие доступные разрешения, повышая разрешения только когда это необходимо для конкретных задач. В некоторых системах контроля версий это может быть возможно на уровне организации или репозитория. Если нет, установите разрешения на верхнем уровне конвейера.

• Когда создается официальный релиз, все активы в этом релизе ДОЛЖНЫ быть четко связаны с идентификатором релиза или другим уникальным идентификатором для актива. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_br_02_02]}

  Подробности:

  Назначьте уникальный идентификатор версии каждому программному активу, произведенному проектом, следуя единообразному соглашению об именовании или схеме нумерации. Примеры включают SemVer, CalVer или идентификатор git-коммита.

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

  Подробности:

  Задокументируйте, как секреты и учетные данные управляются и используются в рамках проекта. Это должно включать подробную информацию о том, как хранятся секреты (например, с использованием инструмента управления секретами), как контролируется доступ, и как секреты ротируются или обновляются. Убедитесь, что конфиденциальная информация не встроена в исходный код и не хранится в системах контроля версий.

• Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке целостности и подлинности активов релиза. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_do_03_01]}

  Подробности:

  Инструкции в проекте должны содержать информацию об используемой технологии, командах для выполнения и ожидаемом выводе. По возможности избегайте хранения этой документации в том же месте, что и конвейер сборки и выпуска, чтобы избежать компрометации как программного обеспечения, так и документации для проверки целостности программного обеспечения в случае единичного нарушения безопасности.

• Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке ожидаемой личности человека или процесса, создающего программный релиз. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_do_03_02]}

  Подробности:

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

• Когда проект выпустил релиз, документация проекта ДОЛЖНА включать описательное заявление о масштабе и сроках поддержки для каждого релиза. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_do_04_01]}

  Подробности:

  Для информирования о масштабе и сроках поддержки выпущенных программных активов проекта, проект должен иметь файл SUPPORT.md, раздел "Поддержка" в SECURITY.md или другую документацию, объясняющую жизненный цикл поддержки, включая ожидаемую продолжительность поддержки для каждого релиза, типы предоставляемой поддержки (например, исправления ошибок, обновления безопасности) и любые соответствующие политики или процедуры получения поддержки.

• Когда проект выпустил релиз, документация проекта ДОЛЖНА предоставлять описательное заявление о том, когда релизы или версии больше не будут получать обновления безопасности. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_do_05_01]}

  Подробности:

  Для информирования о масштабе и сроках поддержки исправлений безопасности, проект должен иметь SUPPORT.md или другую документацию, объясняющую политику проекта в отношении обновлений безопасности.

• Пока проект активен, документация проекта ДОЛЖНА содержать политику, согласно которой участники кода проверяются перед предоставлением повышенных разрешений на доступ к критическим ресурсам. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_gv_04_01]}

  Подробности:

  Опубликуйте исполняемую политику в документации проекта, которая требует, чтобы участники кода были проверены и одобрены до предоставления повышенных разрешений на доступ к критическим ресурсам, таким как одобрение слияния или доступ к секретам. Рекомендуется, чтобы проверка включала установление обоснованной линии идентичности, такой как подтверждение связи участника с известной доверенной организацией.

• Когда проект выпустил релиз, все скомпилированные выпущенные программные активы ДОЛЖНЫ поставляться со списком компонентов программного обеспечения (Software Bill of Materials). {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_02_02]}

  Подробности:

  Рекомендуется автоматически генерировать SBOM во время сборки с использованием инструмента, который был проверен на точность. Это позволяет пользователям получать эти данные стандартизированным способом наряду с другими проектами в их среде.

• Когда проект выпустил релиз, состоящий из нескольких репозиториев исходного кода, все подпроекты ДОЛЖНЫ применять требования безопасности, которые являются столь же строгими или более строгими, чем первичная кодовая база. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_04_02]}

  Подробности:

  Любые дополнительные репозитории кода подпроектов, созданные проектом и скомпилированные в релиз, должны применять требования безопасности в соответствии со статусом и целями соответствующей кодовой базы. В дополнение к следованию соответствующим требованиям OSPS Baseline, это может включать требование проверки безопасности, обеспечение отсутствия уязвимостей и обеспечение отсутствия известных проблем безопасности.

• Пока проект активен, документация проекта ДОЛЖНА четко документировать, когда и как выполняются тесты. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_qa_06_02]}

  Подробности:

  Добавьте раздел в документацию по участию в проекте, объясняющий, как запускать тесты локально и как запускать тесты в конвейере CI/CD. Документация должна объяснять, что тестируют тесты и как интерпретировать результаты.

• Пока проект активен, документация проекта ДОЛЖНА включать политику, согласно которой все значительные изменения программного обеспечения, производимого проектом, должны добавлять или обновлять тесты функциональности в автоматизированном наборе тестов. {Требуется обоснование 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]}

  Подробности:

  Создайте поток VEX, сообщающий о статусе эксплуатируемости известных уязвимостей, включая детали оценки или любые меры по смягчению, препятствующие выполнению уязвимого кода.

• Пока активна, документация проекта ДОЛЖНА включать политику, определяющую порог для устранения результатов SCA, связанных с уязвимостями и лицензиями. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_05_01]}

  Подробности:

  Задокументируйте в проекте политику, определяющую порог для устранения результатов SCA, связанных с уязвимостями и лицензиями. Включите процесс выявления, приоритизации и устранения этих результатов.

• Пока активна, документация проекта ДОЛЖНА включать политику для устранения нарушений SCA до любого релиза. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_05_02]}

  Подробности:

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

• Пока активны, все изменения в кодовой базе проекта ДОЛЖНЫ автоматически оцениваться на соответствие задокументированной политике по вредоносным зависимостям и известным уязвимостям в зависимостях, а затем блокироваться в случае нарушений, за исключением случаев, когда они объявлены и подавлены как неэксплуатируемые. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_05_03]}

  Подробности:

  Создайте проверку статуса в системе контроля версий проекта, которая запускает инструмент анализа состава программного обеспечения для всех изменений в кодовой базе. Требуйте, чтобы проверка статуса проходила успешно, прежде чем изменения могут быть объединены.

• Пока активна, документация проекта ДОЛЖНА включать политику, определяющую порог для устранения результатов SAST. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_06_01]}

  Подробности:

  Задокументируйте в проекте политику, определяющую порог для устранения результатов статического тестирования безопасности приложений (SAST). Включите процесс выявления, приоритизации и устранения этих результатов.

• Пока активны, все изменения в кодовой базе проекта ДОЛЖНЫ автоматически оцениваться на соответствие задокументированной политике по слабым местам безопасности и блокироваться в случае нарушений, за исключением случаев, когда они объявлены и подавлены как неэксплуатируемые. {Требуется обоснование N/A} {Требуется URL выполнения} ^{[osps_vm_06_02]}

  Подробности:

  Создайте проверку статуса в системе контроля версий проекта, которая запускает инструмент статического тестирования безопасности приложений (SAST) для всех изменений в кодовой базе. Требуйте, чтобы проверка статуса проходила успешно, прежде чем изменения могут быть объединены.