Руководство для практиков: Начало работы с безопасностью

Основные показатели:

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

Безопасность настолько сильна, насколько сильна ее самая слабая связь. Пакеты программного обеспечения с открытым исходным кодом можно найти почти во всем программном обеспечении, которое мы используем (Synopsis 2024), поэтому безопасность наших проектов с открытым исходным кодом может иметь далеко идущие последствия для других проектов, наших пользователей и более широкой экосистемы.

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

В отчете Synopsys Open Source Security and Risk Analysis за 2024 год было обнаружено, что 96% отсканированных ими кодовых баз содержали программное обеспечение с открытым исходным кодом, и, к сожалению, 84% из них имели уязвимости (74% с высоким рейтингом серьезности). Поскольку открытый исходный код присутствует везде, безопасность проектов с открытым исходным кодом влияет на работоспособность и устойчивость наших проектов, что распространяется на всю экосистему программного обеспечения. Однако имейте в виду, что риск безопасности часто можно рассматривать как функцию вероятности вместе с воздействием. Вероятность — это потенциальная возможность эксплуатации, а воздействие — это ущерб, который может быть нанесен в результате эксплуатации в контексте развертывания программного обеспечения, поэтому риск — это то, что каждый, кто принимает открытый исходный код, должен определить для своего конкретного контекста, ситуации и среды.

Поскольку безопасность — сложная и важная тема, это руководство предназначено только для того, чтобы чтобы вы начали на вашем пути к улучшению безопасности вашего проекта. Это не является исчерпывающим руководством ко всему, что вам нужно знать о безопасности проектов с открытым исходным кодом. Цель серии руководств для практиков — провести людей через подавляющую фазу, которую многие чувствуют, сталкиваясь с большим количеством новых метрик, которые помогают им найти способы начать понимать и улучшать здоровье своих проектов. После начала работы с этим руководством для практиков вы можете узнать больше по ссылкам на комплексные руководства в разделе «Дополнительное чтение» ниже и по ссылкам в этом руководстве.

Шаг 1: Определите тенденции

Безопасность — сложная тема, но вы можете начать с рассмотрения нескольких ключевых показателей. Во-первых, Знаки отличия OpenSSF Best Practices criteria создает хорошую инженерную основу, которая включает в себя основные методы безопасности. Во-вторых, когда вы используете устаревшие зависимости, у вас в четыре раза больше шансов иметь проблемы безопасности (Cox et al. 2015), поэтому использование Либерс метрика может помочь вам понять, поддерживаете ли вы свои зависимости в актуальном состоянии. В-третьих, Частота выпуска помогает оценить, своевременно ли выпускаются исправления безопасности и другие обновления, чтобы ваши пользователи могли воспользоваться преимуществами обновлений безопасности.

Лучшие практики OpenSSF

Команда Фонд безопасности с открытым исходным кодом (OpenSSF) предоставляет способы оценки вашего проекта с открытым исходным кодом по ряду различных измерений, чтобы получить сводку того, где практики вашего проекта могут быть улучшены. Хотя практики безопасности являются важным компонентом, Значок «Лучшая практика OpenSSF» выходит за рамки просто безопасности, предлагая ряд лучших практик для вашего проекта. Это хороший способ не только оценить ваши методы безопасности и улучшить их, чтобы соответствовать критериям значка, но и сигнализировать вашим пользователям, что вы следуете лучшим практикам OpenSSF. Критерии, найденные в разделах отчетов, безопасности и анализа, являются наиболее применимыми для понимания и улучшения безопасности вашего проекта.

Пример значка Open SSF Gold из проекта curl

Image Source: https://www.bestpractices.dev/en/projects/63

Либерс

Команда Либерс метрика объясняет возраст зависимостей, на которые вы полагаетесь, по сравнению с текущими стабильными релизами этих зависимостей. Впервые она была предложена в «Измерении свежести зависимостей в программных системах» (Кокс и др., 2015). В целом, меньшее число Libyear лучше, поскольку оно указывает на то, что вы поддерживаете свои зависимости в актуальном состоянии.

Пример проекта Libyear, отстающего на 103.78 года

Image Source: https://github.com/nasirhjafri/libyear

Сравнивая текущую версию зависимости, используемой в вашем проекте, с последней доступной версией для каждой зависимости, вы можете лучше понять, где вам может потребоваться более тщательное обновление ваших зависимостей. Однако техническая задержка в обновлении зависимостей обычно создается напряжением между использованием самой последней версии и сохранением решения, которое уже хорошо работает, поэтому в некоторых случаях разработчики могут намеренно выбирать более старую версию вместо последней из-за несовместимости или других технических проблем (Zerouali et al. 2019).

Частота выпуска

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

![Частота выпуска проекта с частыми выпусками][https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/images/releases.png?raw=true]

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

Шаг 2: Диагностика

Хорошим местом для начала диагностики потенциальных проблем с методами обеспечения безопасности вашего проекта является работа с критериями OpenSSF Project Badging Criteria. Пока он находится в процессе, он, скорее всего, будет выглядеть примерно так:

Список категорий значков OSSF для проекта, который работает над получением значка, но еще многое предстоит сделать

Image Source: https://www.bestpractices.dev/en/projects/40

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

Например, вот несколько вопросов из раздела безопасности:

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

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

Следующим шагом в диагностике может стать просмотр отчета Libyears с акцентом на зависимости, которые устарели больше всего. При использовании устаревших зависимостей вероятность возникновения проблем безопасности в четыре раза выше (Cox et al. 2015), поэтому поддержание зависимостей в актуальном состоянии является важным фактором повышения безопасности вашего проекта. Как упоминалось ранее, иногда существуют веские причины для того, чтобы зависимость отставала от текущей версии: критические изменения, несовместимость с вашим программным обеспечением / другими зависимостями или другие технические проблемы. Диагностика в этом случае требует вдумчивого и тщательного изучения того, есть ли веская причина не обновлять зависимость.

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

Шаг 3. При необходимости соберите дополнительные данные.

Примеры, использованные в Шагах 1 и 2, дают отправную точку, которую можно расширить, используя дополнительные инструменты и метрики. Хорошим следующим шагом в процессе диагностики будет также запуск Система показателей OpenSSF, который содержит подробные проверки, помогающие вам найти области, в которых ваш проект может быть уязвим в категориях исходного кода, сборки, зависимостей, тестирования и обслуживания проекта.

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

Дополнительные метрики:

Шаг 4. Внесите улучшения

Одно из лучших мест для начала улучшения ваших методов безопасности — это защита вашего репозитория кода. Это включает управление доступом, защиту ветвей, управление вкладами и многое другое. Лучшие практики настройки платформы управления исходным кодом OpenSSF В руководстве приведен список предложений со ссылками на их реализацию как для GitHub, так и для GitLab.

Еще одной хорошей отправной точкой является создание подробного документа политики безопасности для вашего проекта. Обычно он находится в SECURITY.md файл в корне вашего репозитория. Цель этого документа — предоставить инструкции по сообщению об уязвимостях безопасности, а также документировать, как вы реагируете на эти сообщения, включая управление эмбарго. Этот документ поможет вам выполнить требования к критериям отчетности в OpenSSF Best Practices Badge. Подробные инструкции по созданию политик безопасности можно найти во многих местах, поэтому мы не будем дублировать эти сведения здесь. Например, Руководство по уязвимостям OSS от OpenSSF содержит более подробную информацию о том, что должен включать этот файл, а также шаблоны и инструкции по реализации политики безопасности, которая выходит за рамки простого создания документа и включает сведения об инфраструктуре и других требованиях к управлению процессом обеспечения безопасности.

Как уже упоминалось, при использовании устаревших зависимостей у вас в четыре раза больше шансов столкнуться с проблемами безопасности (Кокс и др., 2015 г.), поэтому поддержание зависимостей в актуальном состоянии является важным фактором повышения безопасности вашего проекта. Зависимости требуют вдумчивого и тщательного изучения того, есть ли веская причина не обновлять зависимость, а также тестирования более новых версий, чтобы убедиться, что вы не нарушаете что-то еще при обновлении зависимости. Хотя есть веские причины избегать обновления определенных зависимостей, в большинстве случаев зависимости не обновляются, потому что может быть сложно отслеживать, когда их следует обновлять. Такой инструмент, как Зависимый бот or Renovatebot может помочь определить и автоматически обновить определенные зависимости.

Хорошая документация по исправлениям безопасности может помочь повысить осведомленность о доступных исправлениях безопасности (Imtiaz et al. 2022), и важно убедиться, что эти исправления попадают в релиз своевременно. Если вы часто выпускаете исправления безопасности, но не быстро добавляете их в релиз, то вам, вероятно, следует разобраться, почему это происходит, и посмотреть, можно ли улучшить процесс выпуска, чтобы выпускать более частые релизы при исправлении уязвимостей. Также важно, чтобы ваши заметки о выпуске или другая документация содержали подробности об исправлениях безопасности, чтобы подчеркнуть важность обновления для людей, использующих ваше программное обеспечение.

Как упоминалось ранее, прохождение критериев значков OpenSSF Best Practices — это хороший способ улучшить безопасность. подробный просмотр страницы критериев для всех уровней содержит пояснения и ссылки с более подробной информацией, которые помогут вам улучшить свои результаты в каждой из этих областей.

Шаг 5: Мониторинг результатов

Поскольку безопасность — это такая сложная тема, ее может быть трудно контролировать. Однако есть несколько вещей, которые вы можете отслеживать с течением времени, чтобы увидеть, оказывают ли действия, которые вы предприняли для улучшения вашей безопасности, влияние. Вот несколько предложений по мониторингу вашего прогресса:

  • Система показателей OpenSSF: Улучшился ли ваш общий балл? Улучшились ли ваши баллы в некоторых отдельных областях, которые вы определили для улучшения?
  • Libyears: Улучшилось ли ваше число libyear?
  • Релизы: Вы выпускаете релиз каждый раз, когда создаете исправление безопасности?

Предостережения и соображения

  • Поскольку безопасность является важной темой, это руководство предназначено только для того, чтобы чтобы вы начали на вашем пути к улучшению безопасности вашего проекта. Это не является исчерпывающим руководством ко всему, что вам нужно знать о безопасности проектов с открытым исходным кодом. Вы можете узнать больше по ссылкам в разделе «Дополнительное чтение» ниже.
  • Вы можете заметить, что в этом руководстве нет метрики, ориентированной на время устранения уязвимостей безопасности. Это очень важно, но сложно измерить, поэтому мы рекомендуем включить эту метрику в качестве одного из ваших первых следующих шагов. Подробнее см. в Шаге 3.

Дополнительное чтение

  • У нас есть Короткое видео (<4 минут) посвящено этому руководству на канале CHAOSS YouTube.
  • Эпизод CHAOSScast об этом руководстве.
  • Сайт OpenSSF содержит широкий спектр очень подробных руководств, обучающих материалов и других ресурсов.
  • Команда Правила безопасности CNCF Документ гораздо менее подробный, чем руководства OpenSSF, но он может оказаться более полезным, если вы только начинаете повышать уровень своей безопасности.
  • Руководство по уязвимостям OSS от OpenSSF содержит руководство, а также шаблоны и руководство по разработке и внедрению политики безопасности.

Обратная связь

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

Соавторы

Следующие люди внесли свой вклад в создание этого руководства:

  • Рассвет Фостер
  • Мэтт Жермонпрез
  • Эмили Фокс

Рекомендации

Руководства для практиков CHAOSS — это живые документы, лицензированные MIT, и мы будем рады вашим отзывам и вкладу. Вы можете предложить изменения к этому документу на странице https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/security.md