Что не является типовой ошибкой процесса ci cd

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

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

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

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

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

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

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

Инциденты, связанные с безопасностью CI/CD

Нарушения в инструментах CI/CD часто происходят из-за неправильной конфигурации или устаревшего программного обеспечения.

Поскольку современные взломы часто автоматизированы, “автоматическому боту” (подобному тем, что пытаются войти в систему по SSH по всему интернету) не требуется много времени, чтобы начать сканирование узлов, на которых установлены устаревшие версии, либо с помощью захвата баннеров, либо просто перебором уязвимостей PoC на общедоступном CI/CD-инструменте.

Недавняя уязвимость в GitLab позволяла использовать серверы с устаревшими установками GitLab для проведения DoS-атак, что, помноженное на количество серверов с устаревшей версией GitLab, привело к DDoS-атакам в Интернете со скоростью более 1 ТБ/с.

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

Аналогично, были уязвимости, связанные с ACL, которые позволяли взломанным, но авторизованным учетным записям выталкивать и извлекать данные из зон несанкционированного доступа в вашем экземпляре GitLab.

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

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

Глядя на приведенные выше примеры, можно подумать, что использование размещенных или SaaS CI/CD инструментов и отказ от самостоятельных инструментов кажется очевидным решением, но размещенные CI/CD инструменты могут создавать свои собственные проблемы безопасности.

Недавняя уязвимость в Travis CI привела к тому, что переменные окружения внедрялись через pull request в виде файлов .travis.yml, а учитывая принцип работы Git, простого удаления файла из Git было недостаточно для защиты различных секретов проекта.

Аналогичным образом, даже если ваш Git-репозиторий был приватным и секреты не были утечены через сам репозиторий, если ваш процесс развертывания использует Git и клонирует репозиторий на производственный экземпляр, любой пользователь, имеющий доступ к вашему производственному веб-приложению, сможет загрузить или просмотреть файл .travis.yml, содержащий секреты вашего приложения/сборки.

Наиболее распространенные ошибки CI/CD, которые приводят к утечке данных и сетевым вторжениям

Захаркоженные учетные данные

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

Эти учетные данные, хранящиеся в системах CI/CD, могут быть любыми – от SMTP-серверов, используемых для отправки почтовых уведомлений о завершении сборки или ошибках сборки, до чего-то потенциально более опасного, например, доступа на уровне SSH/root к серверным системам, которые будут использоваться для развертывания собранного кода.

Рассмотрим пример CircleCI:

version: 2.1
executors:
  my-executor:
    docker:
      - image: cimg/ruby:3.0.3-browsers
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference

jobs:
  my-job:
    executor: my-executor
    steps:
      - run: echo outside the executor

В разделе auth для контейнера docker мы видим переменную $DOCKERHUB_PASSWORD, которая вводится/заменяется CircleCI в процессе сборки, так что пароль скрыт в самом конфигурационном файле.

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

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

• 🦊 Добавление Gitleaks в пайплайн Gitlab CI
• 🌐 GitLab Watchman – Аудит Gitlab на предмет конфиденциальных и учетных данных

Неправильно сконфигурированные контейнеры

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

Контейнеры Docker стали обычным явлением в средах прода, разработки и тестирования.

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

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

см. как проверить Docker:

• 🐳 Сканирование образов Docker на наличие уязвимостей с помощью Trivy
• 🐳 Как проверить изменения в файловой системе контейнера Docker
• 🐳 dockle: линтер + проверка образов на безопасность
• 🐳 Обзор сканеров безопасности контейнеров для поиска уязвимостей
• 🐳 Как использовать Harbor для сканирования образов Docker на наличие уязвимостей

Неправильная конфигурация или неправильное использование переменных окружения

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

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

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

Поскольку члены команды работают по всему миру, команды часто полагаются на инструменты обмена сообщениями, такие как Slack, для публикации информации о состоянии сборки.

Jenkins использует пайплайны для улучшения процессов CI/CD с помощью функций, которые включают объявление статуса сборки через Slack во время или после процесса сборки; например:

import groovy.json.JsonOutput
// Add whichever params you think you'd most want to have
// replace the slackURL below with the hook url provided by
// slack when you configure the webhook
def notifySlack(text, channel) {
    def slackURL = 'https://hooks.slack.com/services/xxxxxxx/yyyyyyyy/zzzzzzzzzz'
    def payload = JsonOutput.toJson()
    sh "curl -X POST --data-urlencode 'payload=${payload}' ${slackURL}"
}

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

Чтобы предотвратить подобные ситуации, URL-адрес хука должен быть настроен как секретный и не открываться открытым текстом в конфигурационных файлах.

Неправильно настроенные инструменты CI/CD

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

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

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

GitLab – это популярный инструмент с открытым исходным кодом, используемый для собственного хостинга Git и CI/CD.

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

Использование CircleCI требует создания конфигурационного файла в формате YAML под названием config.yml, который содержит различные “инструкции”, которым CircleCI следует для запуска процесса сборки.

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

Сейчас давайте рассмотрим конфигурацию CI:

version: 2.1

# Define the jobs we want to run for this project
jobs:
  build:
    docker:
      - image: cimg/<language>:<version TAG>
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference
    steps:
      - checkout
      - run: echo "this is the build job"
  test:
    docker:
      - image: cimg/<language>:<version TAG>
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference
    steps:
      - checkout
      - run: echo "this is the test job"

# Orchestrate our job run sequence
workflows:
  build_and_test:
    jobs:
      - build
      - test:
          requires:
            - build

Как показано выше, можно ссылаться и на частные шаблоны контейнеров docker hub через параметр имя пользователя/пароль.

Но если этот конфигурационный файл утечет из-за его публичной видимости в вашем репозитории GitHub, злоумышленники могут получить доступ к вашим приватным шаблонам контейнеров docker hub.

Аналогичным образом, популярное самораспространяемое CI/CD программное обеспечение GitLab недавно поставлялось с учетными данными по умолчанию для входа пользователя  root – “5iveL!”.

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

Инструменты CI/CD, не являющиеся самостоятельными хостингами, также подвержены неправильной конфигурации.

CircleCI тоже можно очень легко неправильно сконфигурировать, выложив в открытый доступ config.yml проекта.

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

Устаревшие инструменты CI/CD

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

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

Заключение

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

Использование On Prem/SaaS-решений часто рассматривается как решение для снижения требований к безопасности организации, но, как показывает недавний опыт, размещенные/SaaS-инструменты также могут внести уязвимости безопасности в ваши проекты.

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

см. также:

🦊 GitLab настройка 2FA для всех пользователей

CI/CD (Continuous Integration, Continuous Delivery — непрерывная интеграция и доставка) — это технология автоматизации тестирования и доставки новых модулей разрабатываемого проекта заинтересованным сторонам (разработчикам, аналитикам, инженерам качества, конечным пользователям и др.).

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

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

Разработка по методике CI/CD соответствует таким основным принципам:

• Распределение ответственности. Задачи и этапы разработки разделяются между членами команды или ее подгруппами (при работе над большим проектом). Рабочий процесс организуется с учетом бизнес-логистики, внедрения сквозных функций, проведения тестов, безопасности хранения данных и т.д.
• Сокращение рисков. Каждый разработчик или подгруппа разработчиков должны стремиться минимизировать уязвимости и ошибки на всех этапах разработки. Для этого постоянно контролируется бизнес-логистика, проводится пользовательское тестирование продукта, оптимизируется хранение, обработка данных и т.д.
• Оптимизация обратной связи. Успех проекта зависит от того, как работают друг с другом разработчики, клиенты и пользователи. Это влияет на скорость внесения в приложение корректировок и обновлений. Если сборку и тестирование можно автоматизировать, то во многих других операциях требуется участие человека. Чтобы взаимодействие происходило конструктивнее, уменьшается количество посредников между заказчиком, исполнителями и пользователями.
• Создание рабочей среды. Для удобства совместной работы у разработчиков должно быть общее рабочее пространство. Помимо основной ветки процесса в нем должна быть побочная – в ней удобнее проводить тестирование, вносить корректировки, отслеживать отказоустойчивость и т.д.

СI/CD представляет собой современную аналогию конвейерного производства. Их объединяют четкое распределение труда, непрерывный, потоковый характер рабочего процесса, параллельное выполнение сразу нескольких задач (например, кодинга и тестирования). Сегодня эта концепция является доминирующей в DevOps.

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

Сборка. Заранее подобранная система контроля версий запускает автоматизированную сборку и тестирование всего продукта. Триггеры могут быть настроены автоматически или вручную. Автоматическая сборка выполняется с помощью Jenkins или другого сервера непрерывной интеграции.

Ручное тестирование. Как только CI-сервер закончит автоматизированную сборку продукта, он передается тестировщикам на проверку. Они используют различные методики тестирования для выявления и устранения ошибок и уязвимостей программы.

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

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

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

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

Таким образом, рабочий процесс по методологии CI/CD включает как последовательные, так и параллельные этапы. Именно для распараллеливания в рабочем пространстве создается побочная ветка — в ней проще вести работу, не вмешиваясь в основной код до тех пор, пока программируемый модуль не будет готов к интеграции. Условно рабочий процесс по методологии CI/CD можно представить в виде следующей схемы:

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

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

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

• GitLab. Эта платформа позволяет управлять хранилищами проекта, документировать результаты тестирования и доработок, анализировать и дополнять функциональность проекта, выявлять и устранять ошибки.
• Docker. СD-система, позволяющая контейнеризировать проект, то есть упаковать его со всем окружением и зависимостями.
• Travis-CI. Сервер, который можно подключать к виртуальным репозиториям GitHub с минимальными настройками. Благодаря использованию облачных технологий его не нужно отдельно устанавливать.
• Jenkins. Один из самый популярных DevOps-инструментов, совместимый со всевозможными плагинами для адаптации под различные проекты и задачи.
• PHP Censor. CI-сервер, автоматизирующий сборку PHP-проектов. Может работать с репозиториями GitLab, Mercurial и другими, с библиотеками для тестирования Atoum, PHP Spec, Behat.

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