Конвейеры CI/CD, как известно, непрозрачны в отношении того, что именно происходит внутри. Даже если вы написали файл конфигурации YAML (список инструкций конвейера), как вы можете быть уверены, что все происходит именно так, как описано? Хуже того, большинство конвейеров совершенно эфемерны, поэтому даже если произойдет что-то плохое, после этого не останется никаких следов.
Проще говоря, конвейер — это автоматизированный способ тестирования, сборки и публикации вашего программного обеспечения, приложения или артефакта. Такие конвейеры становятся все более распространенными и сложными. Конвейеры отлично помогают командам работать быстрее, обеспечивая более последовательные и предсказуемые результаты при создании программного продукта. Важность автоматизации этих процессов становится еще очевиднее, если учесть, что более крупные компании могут иметь сотни организованных конвейеров, которые зависят друг от друга, поэтому жизненно важно, чтобы все работало гладко и без сбоев.
Я считаю, что, являясь последним звеном в процессе разработки между разработчиками и конечным пользователем или клиентом, недостаточно внимания уделяется тому, как такие автоматизированные процессы могут использоваться в качестве потенциальных векторов атак. Доступ к конвейеру сборки может позволить злоумышленникам не только проникнуть в систему компании-производителя, но и потенциально изменить полученный артефакт таким образом, чтобы повлиять на всех будущих пользователей, тем самым создавая огромный радиус взрыва, который часто называют атака на цепочку поставок программного обеспечения.
В предыдущей статье мы обсудили принципы, которыми вы должны руководствоваться в защита вашего конвейера CI/CD. В этой статье я расскажу о некоторых наиболее распространенных потенциальных слабых местах конвейера CI/CD и предложу некоторые варианты их устранения. Для наших целей не имеет значения, какие инструменты или системы автоматизации вы используете — принципы безопасности по-прежнему действуют, вам просто нужно найти правильный инструмент для защиты этого участка вашего конвейера.
Освоение искусства CI/CD: ключевые элементы, которые нельзя игнорировать
Разные конвейеры имеют разные элементы и используют разные инструменты. Элементы, на которых я решил сосредоточиться, актуальны практически для любого конвейера, поэтому защиту этих элементов можно считать лучшей практикой независимо от вашего SCM, инструментов или существующих настроек безопасности.
Секретное управление – секреты обычно представляют собой строки или токены, используемые для подключения вашего программного обеспечения или конвейера к другим ресурсам. Типичным примером являются ключи API, используемые для подключения вашего кода к ресурсам AWS, таким как корзина S3. Большинство людей уже знают, что следует хранить эти секреты в тайне и не включать их в открытый репозиторий в виде обычного текста. Внутри конвейера CI/CD все немного сложнее. Обычно конвейеру необходим доступ к этим секретам, чтобы получить доступ к ресурсам и информации, которые они представляют. Это означает, что любой, у кого есть доступ к тому, что происходит внутри вашего конвейера, потенциально может увидеть и скопировать ваши секреты. Один из способов сохранить ваши секреты в безопасности даже внутри вашего конвейера — использовать такой инструмент управления секретами, как Хранилище Хашикорп. Такие инструменты могут не только запутывать ваши секреты даже внутри вашего конвейера, но они значительно упрощают ротацию ваших секретов, чтобы вы могли регулярно их менять, что делает кражу секретов из конвейера бесполезной. Независимо от того, какой инструмент управления секретами вы решите использовать, регулярная ротация ваших секретов может считаться хорошей практикой обеспечения безопасности.
Выполнение отравленного трубопровода (СИЗ) – Выполнение отравленного конвейера (PPE) — это метод, который позволяет злоумышленникам «отравить» конвейер CI — по сути, изменить шаги конвейера или их порядок, как определено в файле инструкций конвейера. Этот метод злоупотребляет разрешениями в репозиториях управления исходным кодом (SCM) для управления процессом сборки. Это позволяет внедрить вредоносный код или команды в конфигурацию конвейера сборки, заставляя конвейер запускать вредоносный код во время процесса сборки. Если вы не проверите файл инструкций конвейера перед каждой сборкой, вы, скорее всего, будете в неведении относительно того факта, что ваши сборки больше не выполняются так, как вы указали. Даже незначительное изменение, такое как вызов одной библиотеки вместо другой, может иметь далеко идущие последствия, например, включение бэкдоров или криптомайнеров в конечный продукт.
Один из способов избежать PPE — убедиться, что файл инструкций конвейера не изменен. Вы можете криптографически подписать файл и добавить проверку подписи в качестве первого шага каждого конвейера. Инструмент, который можно использовать для подписи и проверки файлов: Валинт, инструмент, опубликованный Scribe Security. Какой бы инструмент проверки подписи вы в конечном итоге ни использовали, идея состоит в том, чтобы убедиться, что целостность вашего файла инструкций остается неизменной.
Отравление кэша/зависимостей – Рабочие процессы конвейера CI/CD часто используются для указания конкретных действий, которые необходимо выполнить. Каждый рабочий процесс состоит из серии одного или нескольких заданий, которые характеризуются как последовательность действий. Большинство рабочих процессов не используют общие ресурсы по соображениям безопасности. Однако существуют обходные пути, когда возникает необходимость совместного использования ресурсов. Кэш, к которому все рабочие процессы имеют равный доступ, является одним из таких обходных путей. Поскольку кеш используется несколькими рабочими процессами, достаточно одного нарушения в рабочем процессе с полномочиями изменить его, чтобы кеш стал опасным для всех последующих использований рабочего процесса. Один отравленный тайник может быть активен в течение очень долгого времени, влияя на бесчисленные итерации сборок программного обеспечения, выполняемых в этом конвейере, поскольку кеш обновляется только при наличии нового артефакта или пакета для загрузки.
Как и при проверке файла инструкций конвейера, вы можете использовать Валинт чтобы подписать, а затем проверить свой кеш или папку, содержащую все предварительно утвержденные зависимости, необходимые для вашего конвейера. Если вы параноик, то разрешение вашему конвейеру независимо подключаться к Интернету и загружать любые библиотеки, которые он считает необходимыми, — это верный способ добавить больше уязвимостей и возможных эксплойтов в вашу окончательную сборку.
SSH ключей – Ключ SSH — это учетные данные доступа к сетевому протоколу SSH (безопасная оболочка). Этот сетевой протокол используется для удаленной связи между машинами в сети. незащищенная открытая сеть. SSH используется для удаленной передачи файлов, управления сетью и удаленного доступа к операционной системе. Например, с помощью SSH-ключей вы можете подключиться к GitHub, не указывая свое имя пользователя и личный токен доступа при каждом посещении. Вы также можете использовать ключ SSH для подписи коммитов. Вы также можете подключить другие приложения к своему GitHub, используя ключи SSH, например BitBucket и GitLab.
Для обеспечения безопасности учетной записи вам следует регулярно просматривать список ключей SSH и отзывать/удалять все недействительные или скомпрометированные ключи. Для GitHub вы можете найти список ключей SSH на следующей странице:
О компании настройки > Ключи SSH и GPG
Одним из инструментов, который может помочь вам следить за своими SSH-ключами, является отчет о состоянии безопасности с открытым исходным кодом, который называется GitGat. Отчет GitGat предупредит вас, если срок действия любого из настроенных вами ключей SSH истек или является недействительным. GitHub не только внимательно следит за своими ключами и часто их меняет, но и предупреждает: если вы увидите незнакомый вам SSH-ключ, немедленно удалите его и свяжитесь с нами. Поддержка GitHub для дальнейшей помощи. Неопознанный открытый ключ может указывать на возможное нарушение безопасности.
SLSA Provenance как неизменяемый журнал конвейера – SLSA означает «Уровни цепочки поставок для артефактов программного обеспечения» — это структура, разработанная Google и другими отраслевыми партнерами для повышения безопасности и целостности цепочек поставок программного обеспечения.
SLSA определяет набор из четырех уровней, каждый из которых представляет собой более высокий уровень доверия и гарантий в цепочке поставок программного обеспечения. Каждый уровень представляет собой возрастающее приращение требований безопасности. Одним из важных требований является необходимость наличия файла Провенанс. Для платформы SLSA:
Провенанс — это поддающаяся проверке информация об артефактах программного обеспечения, описывающая, где, когда и как что-то было создано. Поскольку основная цель конвейера CI/CD — создать что-то (обычно сборку), то возможность точно отслеживать, какие файлы вошли и что с ними произошло, является своего рода нефальсифицируемым машинным журналом конвейера. Для этой цели важно, чтобы происхождение SLSA создавалось независимо от любого пользователя. Целостность всего, что пользователь может прервать или изменить, может быть подозрительной.
Одним из инструментов, который позволяет вам создать источник происхождения SLSA в вашем конвейере для большого количества систем SCM, является Валинт (ага, тот же инструмент от Scribe — очень универсальный инструмент). Ссылка покажет вам, как подключить Valint к вашему конвейеру GitHub, чтобы генерировать происхождение SLSA для каждой сборки, запускаемой в этом конвейере. Позже вы сможете получить доступ к каждому файлу происхождения и проверить его, чтобы увидеть, не произошло ли чего-нибудь непредвиденного или непредвиденного. Вот фрагмент из такого файла происхождения:
Файл происхождения — это просто файл JSON, но поскольку автоматизированных инструментов для чтения файлов происхождения (пока) не существует, работа по их чтению и интерпретации ложится на вас.
Обеспечение вашего конечного результата – Одним из самых известных нарушений цепочки поставок программного обеспечения за последнее время является Инцидент с SolarWinds. В нем хакеры модифицировали некоторый код на сервере сборки так, чтобы каждая выпускаемая компанией сборка содержала секретный бэкдор. Еще один известный случай повреждения конечного результата можно увидеть во взломе Вьетнамского государственного центра сертификации (VGCA) в 2020 году, получившем название Операция SignSight. Злоумышленники проникли на сайт VGCA и перенаправили ссылки для скачивания на собственную версию программного обеспечения, содержащую вредоносное ПО. В обоих случаях у конечных пользователей не было возможности проверить, что полученное ими программное обеспечение соответствует тому программному обеспечению, которое компания-производитель намеревалась выпустить.
Более простая атака может заключаться в замене конечного образа, созданного в конце конвейера, на вредоносный и загрузку плохого образа туда, куда ему нужно. Поскольку в большинстве подобных атак изображение предположительно исходит от компании-производителя, даже если эта компания защищена действующим сертификатом, этого недостаточно. Это сделало бы фальшивку еще более правдоподобной.
И снова решение состоит в том, чтобы криптографически подписать любой конечный артефакт, созданный конвейером, и позволить конечному пользователю проверить эту подпись.
Поскольку я уже упомянул Валинт Я предлагаю использовать открытый исходный код Знак Sigstore. Cosign стремится упростить подписание, устраняя необходимость в ключевой инфраструктуре. Это позволяет пользователю использовать свою онлайн-проверенную личность (например, Google, GitHub, Microsoft или AWS) в качестве ключа. Вы можете использовать Cosign как для подписи, так и для проверки изображений, что делает его идеальным для подписания и последующей проверки окончательного созданного образа конвейера.
Независимо от того, решите ли вы использовать Valint или Cosign, предоставление пользователям возможности проверять криптографическую подпись на вашем конечном артефакте, чтобы убедиться, что они получают именно то, что вы намеревались доставить, — это идея, я уверен, что большинство конечных пользователей оценят по достоинству.
Безопасность трубопроводов в будущем
Конечно, в конвейере сборки участвуют и другие элементы, которые могут выиграть от дополнительной безопасности. В этой статье я решил рассмотреть некоторые из наиболее очевидных и некоторые из наиболее уязвимых элементов конвейера.
Какие бы инструменты конвейера или инфраструктуру вы ни использовали, следите за возможностью взлома. Никогда не доверяйте слепо какой-либо системе, которая говорит вам, что она полностью безопасна.
Учитывая растущую угрозу кражи личных данных, целевого фишинга и других форм фальсификации законного доступа, мы считаем, что механизм проверки подписи — это хороший и универсальный инструмент, который можно иметь в своем цифровом наборе инструментов.
Если вам нужно подписать изображение, файл или папку, я приглашаю вас поближе познакомиться с Valint от Scribe Security как универсальным инструментом для таких нужд.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
