Специфика того, что происходит внутри конвейеров CI/CD, печально известна непрозрачностью. Несмотря на то, что вы написали файл конфигурации YAML, который представляет собой список инструкций конвейера, как вы можете быть уверены, что все происходит именно так, как описано? Хуже того, большинство конвейеров являются полностью временными, поэтому даже в случае сбоя остается мало свидетельств, кроме зарегистрированных, которые могут включать или не включать подробности проблемы.
Быстрое развитие достигается за счет использования автоматизированных конвейеров непрерывной интеграции/непрерывной доставки (CI/CD). Наличие триггеров или планирования, которые автоматически компилируют, создают, тестируют и отправляют ваш код, — это просто фантастика. Однако большинство конвейеров не учитывают безопасность, поскольку они разработаны для скорости и удобства использования. Поскольку конвейерам обычно требуется доступ к Интернету для загрузки зависимостей и файлов, после взлома конвейера у злоумышленника есть множество возможностей нарушить вашу работу или украсть информацию или секреты.
В этой статье я расскажу о некоторых лучших практиках, которые вы можете использовать для защиты своего конвейера CI/CD. Для наших целей не имеет значения, какие инструменты или системы автоматизации вы используете — принципы безопасности по-прежнему действительны. Вам просто нужно найти подходящий инструмент для защиты этого участка вашего трубопровода.
Что такое конвейер CI/CD (непрерывная интеграция/непрерывная доставка)?
Конвейер CI/CD — это автоматизированный процесс создания, тестирования и публикации вашего программного обеспечения, приложения или артефакта. Эти трубопроводы становятся все более распространенными и сложными. Конвейеры — отличный инструмент для повышения продуктивности команды и более последовательного и предсказуемого создания программных продуктов. Значение автоматизации этих процедур становится гораздо более очевидным, если принять во внимание, что более крупные предприятия могут иметь сотни взаимосвязанных, хореографически организованных конвейеров, хорошее функционирование которых зависит друг от друга.
Автоматическое и регулярное создание и тестирование изменений кода в новом конечном продукте называется непрерывной интеграцией или CI. Изменения в коде доставляются, тестируются и интегрируются в рамках двухэтапного процесса, называемого непрерывной доставкой и/или развертыванием (CD). Непрерывное развертывание автоматически доставляет обновления в производственную среду, а непрерывная доставка прекращается непосредственно перед автоматическим производственным развертыванием. Использует ли ваш конвейер тот или иной вариант, полностью зависит от вас и от того, как настроены ваши среды и результаты.
Важность безопасности CI/CD для вашей цепочки поставок программного обеспечения
Большинство компаний полагаются на CI / CD инструменты для автоматизации своих конвейеров. Это означает, что, как и многие другие атаки на цепочку поставок программного обеспечения, все, что нужно злоумышленникам, — это пробить одну цель, чтобы получить огромный радиус взрыва. Одним из ключевых недостатков является необходимость конвейерной загрузки и интеграции зависимостей в конечный продукт или артефакт. Даже одной плохой зависимости достаточно, чтобы нежелательный элемент закрепился в конвейере. Поскольку конвейер имеет доступ к исходному коду и различным другим элементам вашей инфраструктуры (при необходимости), повышение привилегий позволяет получить доступ, а затем изменить или удалить практически любую часть продукта, созданного в этом конкретном конвейере.
Простой пример можно найти в нашем объяснении отравление кеша или зависимостей.
За последние несколько лет несколько крупных компаний пострадали от атак на цепочки поставок программного обеспечения, источником которых был конвейер CI/CD. Например, вы можете посмотреть Взлом CircleCI в январе 2023 года, Компромисс Argo CD в январе 2022 года и Нарушение кодовой зоны в апреле 2021.
Потенциальные последствия таких атак серьезны, поэтому имеет смысл сделать все возможное, чтобы обеспечить максимальную безопасность ваших конвейеров.
Лучшие практики безопасности CI/CD
Какую бы платформу или инструменты CI/CD вы ни использовали, есть несколько вещей, которые вы можете сделать, чтобы усилить свою безопасность и уменьшить потенциальный ущерб в том маловероятном случае, если злоумышленнику все же удастся получить доступ к вашему конвейеру или сети.
Мониторинг и оповещение – Нарушение может произойти, даже если вы научили своих инженеров опасаться фишинга и других видов мошенничества с помощью социальной инженерии. Поскольку большинство конвейерных сред являются временными, после завершения работы не останется много следов, если вы не будете активно их регистрировать. При работе над каждым PR, объединением, сборкой и тестированием убедитесь, что все изменения, внесенные в среду или файлы конфигурации, протоколируются. Пользовательские данные также должны регистрироваться вместе со всеми другими данными для проверки, если этого потребует проблема. Целью данной работы является возможность реконструировать нарушение и определить, что пошло не так и как пошло не так. Заранее выберите события, которые должны вызвать оповещение, и убедитесь, что соответствующие стороны проинформированы. Будьте осторожны и не перегружайте людей бессмысленными или слишком деликатными оповещениями; это может привести к утомлению оповещений, что просто заставит их игнорировать оповещения или реагировать гораздо позже, чем разумно.
Используйте принцип RBAC в сочетании с наименьшими привилегиями. – Предоставление доступа к системным ресурсам на основе назначенной роли или должностной функции пользователя в организации является основой управления доступом на основе ролей или RBAC. Пользователям предоставляются роли в RBAC, которые определяют их права доступа и разрешения к различным системным ресурсам, таким как файлы, папки и программы. С другой стороны, концепция наименьших привилегий относится к практике предоставления пользователям минимального объема доступа и привилегий, необходимых для выполнения их рабочих обязанностей. Это означает, что пользователи ограничены использованием ресурсов, необходимых для выполнения назначенных им заданий, и не более того. Наименьшие привилегии и RBAC часто применяются вместе как дополнительные концепции безопасности. Принцип наименьших привилегий гарантирует, что пользователи имеют доступ только к минимальному количеству ресурсов, необходимому для выполнения их конкретных обязанностей, а RBAC назначает роли, которые предоставляют пользователям необходимый объем доступа к ресурсам, необходимым им для выполнения своих рабочих функций, и не более того. . В совокупности эти рекомендации помогают поддерживать хорошо обслуживаемую и относительно безопасную систему. Вы можете настроить его так, чтобы для выполнения важных действий системы требовалась множественная авторизация пользователей в качестве дополнительного уровня безопасности. Эту стратегию следует использовать осторожно, поскольку она может привести к заметному замедлению процесса разработки.
Сохраняйте происхождение трубопровода в неизменяемом журнале – Поддающаяся проверке информация об артефактах программного обеспечения, которая описывает, где, когда и как что-то было создано, называется происхождением. Зная точно, какие файлы были введены и что с ними произошло в конвейере, можно создать файл происхождения для формирования нефальсифицируемого журнала этого конвейера. Чтобы обеспечить безопасность, происхождение должно создаваться независимо от любого пользователя, поскольку все, что пользователь может нарушить или изменить, не заслуживает полного доверия. Валинт Писца позволяет установить происхождение в вашем конвейере для широкого спектра систем SCM. Каждый файл происхождения (JSON) доступен позже, поэтому вы можете просмотреть его, чтобы определить, произошло ли что-нибудь неожиданное или нежелательное. Между прочим, создание и управление файлами происхождения со всех ваших конвейеров — это основа Структура SLSA.
Полностью используйте свой SBOM – На тот случай, если вы пропустили несколько потенциальных применений, SBOM, созданный в конце конвейера, может помочь составить список всех используемых пакетов с открытым исходным кодом. Сравнение этого списка с известными CVE может сказать вам, какие потенциальные уязвимости существуют в вашем конечном продукте. Вы также можете использовать список, чтобы проверить, используете ли вы устаревшие версии пакетов с открытым исходным кодом, и даже использовать что-то вроде Система показателей OpenSSF чтобы проверить «здоровье» используемых вами пакетов. Поскольку новые CVE постоянно появляются, у вас должна быть служба, в отличие от одноразового SAST, которая сообщит вам, если в одном из ваших существующих пакетов обнаружено новое CVE. Служба Scribe может помочь вам сделать все это автоматически.
Проверьте соответствие вашим политикам – У каждой компании, а иногда и у каждого трубопровода, есть политика, которая должна соблюдаться, чтобы убедиться, что все в порядке. Некоторые политики являются общими (например, обеспечение процесса проверки двумя людьми), а другие уникальны (например, обеспечение того, чтобы Майк подписал последнее изменение, прежде чем мы отправим его в производство). Используя механизм проверки криптографических знаков и уникальный файл политики, вы теперь можете включать необходимые политики в каждый конвейер и проверять (себя и других), что они имели место. Это человеческая слабость, которая, если ее подчеркнуть, может привести к тому, что некоторые требования будут пропущены, а некоторые правила будут нарушены ради соблюдения сроков. Благодаря этой мере люди больше не смогут нарушать правила, и это должно помочь поддерживать безопасность вашего трубопровода как от внутренних, так и от внешних угроз. Scribe разработал новый способ обеспечения соблюдения таких политик и даже позволяет вам писать свои собственные. Проверьте это здесь.
Защитите файл инструкций конвейера – Злоумышленники могут «отравить» конвейер CI, используя метод, известный как выполнение отравленного конвейера (PPE), который существенно изменяет этапы конвейера или их последовательность, как первоначально указано в файле инструкций конвейера. Этот метод манипулирует процессом сборки, злоупотребляя разрешениями в репозиториях управления исходным кодом (SCM). Вставив вредоносный код или команды в настройки конвейера сборки, можно отравить конвейер и вызвать выполнение вредоносного кода во время завершения сборки. Вы не сможете определить, что ваши сборки работают не так, как вы планировали, пока или пока вы не проверите файл инструкций конвейера. Чтобы быть уверенным, что ваши конвейеры работают так, как вы планировали, вам следует проверять файл инструкций перед каждым запуском. С точки зрения криптографии, подписание файла и добавление проверки подписи в качестве первого шага конвейера является одним из способов достижения такой безопасности. Валинт Писца подпишите и проверьте Функции — это один из способов убедиться, что ваш файл инструкций остался неизменным, прежде чем запускать новый запуск конвейера.
Защитите свой конечный результат – Зачем злоумышленнику усердно работать, чтобы нарушить работу вашего конвейера, если заменить конечный продукт мошеннической версией гораздо проще? Поскольку источником изображения в таких типах атак является генерирующая компания, для этой компании недостаточно иметь действительный сертификат, защищающий его. Проще говоря, это повысит доверие к фейку. Решение состоит в том, чтобы криптографически подписать любой конечный артефакт, создаваемый конвейером, и позволить конечному пользователю проверить эту подпись. Валинт Писца можно использовать для подпишите и проверьте большое разнообразие артефактов, обеспечивающих дополнительную безопасность, благодаря которой ваши пользователи получают именно то, что вы им предназначали.
Взгляд в будущее
Никто не собирается отказываться от использования таких методов автоматизации, как CI/CD, для ускорения своей работы. Напротив, в мире, в котором мы живем, мы всегда стремимся к более быстрым итерациям обновлений программного обеспечения. Мы должны, по крайней мере, убедиться, что подходим к задаче с осторожностью, стараясь не поставить под угрозу нашу производственную среду или наш исходный код в процессе.
Крайне важно учитывать потенциальные последствия получения кем-либо незаконного доступа к вашему конвейеру, вашей среде или вашему исходному коду. Я уверен, что вы сможете предпринять соответствующие действия, чтобы остановить или смягчить потенциальные утечки, как только поймете, насколько они могут быть опасны и где ваши трубопроводы и сеть наиболее уязвимы.
Поскольку взаимосвязанные конвейеры будут только усложняться, крайне важно поддерживать общую безопасность вашей среды (сегментированная сеть, RBAC, нулевое доверие и т. д.) в качестве первого шага по защите ваших конвейеров. После этого постарайтесь создать надежные, не поддающиеся фальсификации доказательства и использовать криптографическую подпись и проверку данных, чтобы попытаться максимально снизить вероятность атаки на цепочку поставок программного обеспечения, которая может отравить ваш конвейер или его кеш. Бдительность и подозрительность могут избавить вашу компанию от невыразимых головных болей.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
