Безопасность цепочки поставок программного обеспечения

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

Основные практики от разработчиков компании DST Global, обеспечения безопасности SDLC и управления рисками. 

Безопасность цепочек поставок программного обеспечения стала актуальной темой в последние годы из-за катастрофических утечек, о которых сообщалось в новостях, и их масштабных финансовых последствий. Стоит лишь упомянуть такие компании, как Log4Shell , чтобы вспомнить, насколько разрушительной может быть простая уязвимость. Чтобы избежать подобных катастроф, мы должны применять основные методы защиты наших цепочек поставок программного обеспечения и гарантировать, что мы поставляем и внедряем продукты, безопасность которых можно проверить.

В этой реферальной карте мы ответим на следующие пять вопросов:

- Что такое цепочка поставок программного обеспечения?

- Как мы можем гарантировать использование безопасных зависимостей?

- Как можно безопасно создавать артефакты?

- Как можно безопасно доставлять и развертывать артефакты?

- Какие стандарты и уровни соответствия существуют для безопасности цепочки поставок программного обеспечения?

О безопасности цепочки поставок программного обеспечения

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

- Древесина

- Металл

- Графит

- Резина

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

- Соответствуют ли поставляемые нам материалы нашим стандартам качества?

- Что делать, если поставленные нам материалы будут отозваны?

- Что делать, если поставщик , поставляющий нам материалы, не сможет выполнить свою квоту?

- А что делать, если на наш импорт от поставщика наложены эмбарго?

- Как мы реагируем на мировое событие, такое как пандемия или война, которое нарушает нашу цепочку поставок?

- Какие правовые ограничения или обязательства налагают наши поставщики на нашу продукцию?

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

В целом цепочка поставок программного обеспечения состоит из трех компонентов:

- Upstream – зависимости, необходимые для создания нашего продукта

- Система сборки – инфраструктура и процессы, используемые для сборки нашего продукта.

- Downstream – артефакты, которые мы производим, которые составляют и сопровождают наш продукт

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

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

В следующем разделе мы рассмотрим основные практики обеспечения безопасности каждого компонента цепочки поставок программного обеспечения и разберем главные соображения при создании надежного программного продукта.

Основные методы обеспечения безопасности цепочки поставок программного обеспечения

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

В ходе обсуждения мы будем использовать следующие ключевые термины:

- Уязвимость — программный дефект, которым злоумышленник может воспользоваться для получения нежелательного доступа к системам или данным и вредоносного воздействия на приложение.

- Исправление – стратегия (например, обновление зависимости) для устранения уязвимости.

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

Примечание: Эти основные практики предполагают использование автоматизированного конвейера непрерывной интеграции и непрерывной поставки (CI/CD) для разработки и поставки нашего программного обеспечения. Как мы увидим, автоматизация и логическое разделение этапов конвейера имеют решающее значение для установления проверяемого доверия в нашей цепочке поставок.

Безопасность в авангарде

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

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

- Разработчики вручную включают файлы и проекты

- Разработчики копируют и вставляют исходный код в свои проекты

- Помощники кодирования на основе ИИ

- Языки программирования, не использующие менеджеры пакетов (например, C/C++)

- Сторонние библиотеки

- Изображения контейнеров

Примечание: Не все зависимости являются прямыми. Существуют также транзитивные зависимости , или зависимости зависимостей. Например, если наше приложение зависит от A , A зависит от B , а B зависит от C , уязвимость в B или C может создать вектор атаки, даже если мы не включили B напрямую в качестве зависимости. Эту структуру можно составить в граф зависимостей, используя зависимости в качестве узлов (вершин), а зависимости — в качестве ребер.

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

Существует множество типов зависимостей, включая:

- Программные артефакты (например, Jars, пакеты NPM)

- Образы Docker

- Файлы конфигурации

- Конфигурации инфраструктуры и автоматизации ИТ (например, конфигурации Ansible )

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

Существует четыре основных метода защиты наших зависимостей:

- Перечисление наших зависимостей

- Обнаружение их уязвимостей

- Проверка законности наших зависимостей

- Своевременное устранение уязвимостей

Спецификация программного обеспечения

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

- Включает все зависимости в графе зависимостей

- Включает каждую зависимость только один раз

Уникальность записи определяется её именем и версией. Если существуют две зависимости с одинаковым именем и версией, в SBOM создаётся только одна запись для каждой зависимости.

Примечание: для создания SBOM не требуется инструмент сборки, но его использование значительно упрощает задачу. Большинство инструментов сборки требуют указания зависимостей проекта, чтобы они могли их извлечь во время компиляции. Поэтому большинство инструментов сборки, таких как Maven , Gradle , NPM или PyPi , могут легко сгенерировать SBOM на основе этой спецификации зависимостей. Однако если эти инструменты не учитывают какие-либо зависимости, не представленные инструментом, их SBOM могут быть неточными и неполными. Инструменты анализа состава программного обеспечения (SCA) — это коммерческие решения, которые обычно обеспечивают более точную и полную SBOM.

В настоящее время мы можем генерировать три основных формата SBOM:

- Обмен данными о программных пакетах (SPDX) от Linux Foundation

- CycloneDX от OWASP

- Syft от Anchor

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

Для автоматического создания SBOM мы можем добавить в наш проект следующие инструменты:

- SPDX содержит плагины для Maven и других языков и систем сборки.

- CycloneDX содержит множество плагинов для различных систем сборки, включая Maven , Gradle и NPM.

- Syft генерирует SBOM из образа контейнера Docker или файловой системы.

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

Распознавание уязвимостей

Используя перечисленные зависимости, мы теперь можем определить, какие из них содержат известные уязвимости. Для распознавания этих уязвимостей требуется сопоставить нашу модель SBOM со списком известных уязвимостей. В большинстве случаев уязвимости публикуются в виде бюллетеня безопасности Common Vulnerabilities and Exposures (CVE) — бюллетеня безопасности, содержащего информацию о конкретной уязвимости и версиях продукта, подверженных ей. Поставщики часто публикуют CVE в системе CVE, когда обнаруживают, что их продукт уязвим для эксплуатации.

Примечание: Система CVE поддерживается компанией Mitre и предоставляется бесплатно. База данных CVE также доступна через Национальную базу данных уязвимостей (NVD), поддерживаемую Национальным институтом стандартов и технологий США.

Более сложные инструменты также могут использовать перекрёстные ссылки на отчёты Vulnerability Exploitability eXchange (VEX) для предоставления информации об области действия уязвимости и возможных способах её устранения. CVE, VEX и другая информация об уязвимостях могут предоставить контекст и понимание уязвимостей, унаследованных от вышестоящих разработчиков, а также способов их устранения или минимизации.

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

В настоящее время наиболее распространёнными инструментами с открытым исходным кодом для автоматической проверки SBOM являются Trivy и Grype. Существует также множество других бесплатных, платных и открытых инструментов. Многие из этих инструментов, помимо простых проверок на CVE, включают в себя сканирование уязвимостей, например, автоматизированные инструменты для обнаружения уязвимостей в коде, автоматическую генерацию запросов на извлечение (PR) для их устранения и интеграцию в систему сборки.

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

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

- Интеграция с нашими существующими репозиториями и конвейерами CI/CD (единый обзор нашего кода)

- Автоматизация создания PR для устранения неполадок

- Отслеживание снижения уровня уязвимости с течением времени (графическое отображение количества уязвимостей в нашем коде с течением времени)

- Устранение необходимости в отдельном SBOM

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

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

Примечание: Бывают случаи, когда мы обнаруживаем уязвимость или ошибку в зависимости раньше других, включая поставщика. В таких случаях важно сообщить об ошибке поставщику или уведомить его, чтобы можно было подать CVE-запрос и как можно быстрее создать исправление, что позволит нам устранить уязвимость в нашем продукте.

Своевременное устранение неполадок

Как только мы осознаём, что зависимость уязвима для эксплуатации, мы должны быстро устранить уязвимость. Устранение уязвимости обычно осуществляется одним из трёх способов:

- Обновление – обновление зависимости до версии, которая не уязвима.

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

- Удаление – полное удаление зависимости

Примечание: Бывают случаи, когда зависимость достигает конца жизненного цикла (EOL) и больше не поддерживается. Это означает, что дальнейшие обновления для этой зависимости производиться не будут. Для зависимостей, срок поддержки которых подходит к концу, важно иметь запасной вариант или альтернативное решение. Если обнаружена уязвимость в зависимости, срок поддержки которой истек, у нас есть несколько вариантов действий:

- Используйте новую зависимость, которая заменяет функциональность существующей.

- Изменим наш код так, чтобы не использовать функциональность зависимости, что позволит нам удалить эту зависимость.

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

Скорость, с которой мы можем применить одну из этих стратегий исправления, во многом зависит от двух факторов:

- Как быстро мы можем обновить наш исходный код

- Как быстро мы сможем выпустить обновленную версию нашего продукта

Первый фактор обычно определяется сложностью нашего кода. Например:

- Имеем ли мы многочисленные, тесно связанные зависимости, или они разъединены, и изменения в одном компоненте будут иметь минимальное влияние на другие компоненты?

- Поддерживаем ли мы наш код в актуальном состоянии?

- Организован ли наш список зависимостей, есть ли у нас центральный список версий, который можно легко обновлять?

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

Вот несколько советов, которые помогут обеспечить быстрый выпуск исправленного продукта:

- Оптимизируйте процесс выпуска и удалите как можно больше ненужной информации.

- Создайте автоматизированный конвейер CI/CD для релизов.

- Увеличьте охват автоматизированного тестирования и сократите объем ручного тестирования.

- Сократить официальные циклы релизов (в идеале каждое изменение может привести к релизу).

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

Проверка законности зависимостей

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

Мы осуществляем эту проверку посредством:

- Проверка подписи наших зависимостей и отклонение неподписанных или измененных зависимостей

- Проверка сертификата для репозитория, из которого мы получаем зависимость

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

Безопасность сборки

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

Безопасность системы построения базируется на двух принципах:

- Обеспечение безопасности нашего конвейера сборки

- Обеспечение безопасности нашей инфраструктуры сборки

Цель защиты наших систем сборки — создание доверенного процесса сборки.

Обеспечение безопасности трубопровода

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

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

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

Чтобы предотвратить нападения с использованием СИЗ, нам следует:

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

- Отозвать доступ к репозиторию, если он больше не нужен разработчику.

- Требуйте создания запросов на извлечение при внесении изменений и обязательного рассмотрения каждого PR (в идеале двумя или более разработчиками) перед объединением PR.

- Минимизируйте количество секретов и конфиденциальной информации, раскрываемой сборке системой сборки.

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

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

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

Безопасность инфраструктуры

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

- Человеческая ошибка и халатность

- Незакаленные машины или контейнеры

- Недостаточная криптографическая безопасность

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

- Максимально возможное написание скриптов и автоматизация, включая этапы сборки, развертывание контейнеров и конвейеризацию в виде кода

- Обеспечение надлежащих и минимальных списков контроля доступа для всех машин и процессов, к которым пользователи могут получить доступ

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

- Предоставление только тех разрешений, которые нужны пользователю, и ничего больше

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

Чтобы укрепить наши сборочные машины, нам также следует применять основные практики обеспечения ИТ-безопасности, включая:

- Минимизация поверхности атаки путем закрытия всех ненужных точек доступа и портов

- Регулярное тестирование наших систем на проникновение

- Регулярный аудит доступа каждого пользователя к системе

- Постоянное обновление пакетов на сборочной машине с использованием ИТ-автоматизации

- Поддержание легковесных систем (например, контейнеров), чтобы можно было быстро уничтожить скомпрометированные системы и легко запустить новые системы

- Резервное копирование данных для обеспечения возможности быстрого устранения атак программ-вымогателей и других блокирующих атак

Примечание: Этот уровень безопасности должен быть обеспечен по всему стеку нашей системы сборки. Например, если мы разворачиваем контейнеры Docker для выполнения сборки, контейнеры и хост-машина должны быть защищены.

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

Безопасность на нисходящем направлении

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

- Развернуто в производственной среде

- Используется в качестве зависимостей в последующих продуктах (внутри и вне нашей команды)

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

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

Примечание: Мы по-прежнему обязаны обеспечивать безопасность наших артефактов, даже если они никогда не покидают нашу команду. Например, если у нас есть конвейер сборки, создающий JAR-файл, и этот JAR-файл используется в качестве входных данных в другом внутреннем конвейере, этот JAR-файл ни при каких обстоятельствах не может быть использован извне. Тем не менее, мы по-прежнему несем ответственность за надлежащее предоставление доказательств надёжности JAR-файла. Невыполнение этого требования создаёт брешь в безопасности цепочки поставок второго проекта, как и в случае, если бы какая-либо внешняя зависимость не предоставила таких доказательств.

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

На практике обеспечение безопасности на нисходящем направлении предъявляет три требования:

- Подписание наших артефактов

- Доказательство подлинности наших хранилищ артефактов

- Мониторинг наших производственных сред

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

Подписание артефактов

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

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

- Артефакт не подвергался изменениям после выпуска.

- Артефакт был создан на доверенном узле сборки, имеющем закрытый ключ.

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

Примечание: Эта безопасность основана на безопасности закрытого ключа. Если закрытый ключ каким-либо образом скомпрометирован, он должен быть немедленно отозван, а новый открытый ключ опубликован, чтобы злоумышленник не смог действовать самозванцем. При условии надлежащей защиты узлов сборки (см. раздел «Безопасность сборки» выше) подписание артефакта даёт уверенность следующему пользователю нашего артефакта, будь то мы сами или третья сторона, в том, что нашему артефакту можно доверять.

Автоматизированное подписывание поддерживается большинством систем сборки. Подробнее см. в следующих ресурсах:

- « Плагин Apache Maven Jarsigner », Maven

- « Плагин для подписи », Gradle

- « О подписях реестра ECDSA », NPM

- « PEP 458 – Безопасные загрузки PyPI с использованием подписанных метаданных репозитория Sith », PyPI

Подлинность хранилища артефактов

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

Доверие к хранилищу артефактов и хранящимся в нём артефактам основано на подтверждении их подлинности. Это подтверждение осуществляется посредством сертификатов и использования протоколов, проверяющих эти сертификаты. На практике это означает:

- Наше хранилище артефактов всегда должно иметь действительный сертификат.

- Сертификат должен быть подписан доверенным центром сертификации (ЦС).

- Любой доступ к нашему хранилищу артефактов, например получение артефактов, должен осуществляться через защищенный протокол, который проверяет сертификат через TLS (например, HTTPS, FTPS).

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

Наконец, по возможности следует ограничить любой доступ к нашему репозиторию артефактов достаточно безопасными протоколами. Например, если мы разрешим доступ к нашему репозиторию по старой версии TLS или по протоколам, не включающим проверку сертификатов (например, HTTP), мы нарушим цепочку безопасности. Хотя клиент сам должен убедиться в использовании безопасного протокола, исключение возможности использования таких небезопасных протоколов гарантирует устранение как можно большего количества точек недоверия.

Мониторинг производства

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

- Частое обновление уязвимой инфраструктуры для устранения или смягчения уязвимостей

- Аудит производственных сред для обеспечения соответствия декларативному состоянию нашей инфраструктуры (например, конфигурации Ansible или Puppet )

- Аудит производственной инфраструктуры, включая контейнеры Docker, для обеспечения соответствия ее конфигурации развертывания (например, Kubernetes ) конфигурациям

- Обеспечение безопасности всего стека — от ядра до уровня приложений

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

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

Дополнительные советы по безопасности, от специалистов DST Global

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

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

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

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

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

Стандарты безопасности

Поскольку безопасность цепочки поставок программного обеспечения становится всё более важным требованием к разработке программного обеспечения, были разработаны стандарты, обеспечивающие систематизацию принятых в отрасли практик. Эти стандарты также позволяют нам оценивать безопасность и соответствие цепочки поставок программного обеспечения требованиям. В настоящее время основными стандартами являются:

- Уровень цепочки поставок программных артефактов (SLSA)

- Безопасная среда разработки программного обеспечения

- Указ президента США 14028

- Стандарт проверки компонентов программного обеспечения OWASP

Эти стандарты не являются взаимоисключающими, и в зависимости от отрасли нам может потребоваться соблюдать несколько из них. SLSA занял лидирующие позиции как один из наиболее широко принятых стандартов и включает четыре уровня безопасности:

- Сборка L0 – без гарантий

- Сборка L1 – происхождение существует

- Сборка L2 – размещенная платформа сборки

- Сборка L3 – усиленные сборки

Заключение

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