Как превратить конвейер DevOps в конвейер DevSecOps: обзор концепции сдвига влево

Привет, ХакерНун! Меня зовут София, я DevOps/Cloud-инженер. Я решил поучаствовать в конкурсе от HackerNoon и Aptible.

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

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

Концепция сдвига влево

Основная цель методологии DevSecOps — внедрить автоматизированные проверки безопасности в конвейеры DevOps, т. е. в сам процесс разработки программного обеспечения.

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

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

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

Исправление проблем на этапе сборки артефакта обходится минимум в два раза дороже. Вам придется внести изменения в процесс сборки, например отредактировать Dockerfile, а значит, вам понадобится помощь DevOps-инженеров.

Если при интеграционном тестировании будет обнаружена ошибка, исправить ее будет в 10 раз дороже. В этом случае необходимо перезапустить цикл разработки и привлечь разработчиков, DevOps-инженеров и тестировщиков.

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

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

Структура конвейера DevSecOps

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

На изображении выше показана структура DevSecOps Pipeline со всеми основными этапами проверок безопасности. Вот несколько слов о каждом из них:

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

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

• Пост-сборка. Это проверка безопасности артефакта, созданного на основе исходного кода, например файла Docker, пакета RPM или архива JAR. Инструменты анализируют среду приложения и зависимости, находя устаревшие версии пакетов и библиотек, для которых уже есть исправления в более новых версиях.

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

• После развертывания. Он подразумевает проверку безопасности приложения после его развертывания в производственной среде. Инструменты отслеживают открытые реестры известных уязвимостей в режиме реального времени и уведомляют при обнаружении угрозы приложению.

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

Предварительные проверки

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

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

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

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

Инструменты для проверок перед фиксацией

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

1. Гитликс
2. git-секреты
3. Тривиальное секретное сканирование
4. Шепот
5. все секреты git
6. обнаружение секретов
7. грязные утечки

Это отличные инструменты для проверок перед фиксацией.

Проверки перед сборкой

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

Существует несколько типов проверок перед сборкой:

• Секретное обнаружение
• Статическое тестирование безопасности приложений (SAST)
• Анализ состава программного обеспечения (SCA)

Теперь давайте обсудим их подробно.

Проверка обнаружения секрета перед сборкой

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

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

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

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

Инструменты для обнаружения секретов

Обнаружение секретов можно настроить с помощью Гитликс , git-секреты , или обнаружение секретов . Однако лучше всего использовать сервисы известных CI/CD-платформ, например, Обнаружение секретов GitLab .

Предварительная проверка SAST

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

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

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

По этой причине не следует ограничиваться только анализом SAST. Лучше подойти к вопросу комплексно и использовать разные виды анализа: SCA, DAST, IAST и OAST.

Инструменты SAST

Собственные решения:

• СонарКуб и
• Галочка SAST
• Солнечное приложениеScreener

Бесплатное решение — GitLab SAST.

Проверка SCA исходного кода перед сборкой

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

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

Source SCA анализирует исходный код и, в частности, зависимости приложения, определенные в исходном коде. Этот анализ часто называют сканированием зависимостей.

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

Хорошим примером является Журнал4Shell . Эта уязвимость была обнаружена в конце 2021 года в Log4j, популярной платформе ведения журналов Java. Она стала одной из самых опасных уязвимостей, поскольку позволяла злоумышленникам выполнять произвольный код Java на сотнях миллионов устройств.

Инструменты SCA

Триви является решением с открытым исходным кодом.

Коммерческое решение с бесплатными тарифными планами:

• ФОССА
• Исправить SCA

В рамках GitLab (доступно только в Ultimate-версии) вы можете использовать Сканирование зависимостей GitLab .

Проверки после сборки: двоичный SCA

Фаза после сборки наступает после того, как из исходного кода в конвейере CI были созданы артефакты: образ Docker, пакет RPM или архив JAR. С помощью проверок после сборки вы можете проанализировать зависимости в этих двоичных артефактах.

Бинарный анализ SCA включает проверку двоичных артефактов, таких как образы Docker, пакеты RPM и архивы JAR/WAR/EAR. Его также часто называют сканированием контейнера. Имеет смысл запускать его после сборки двоичных артефактов, т. е. не до этапа после сборки.

При работе с образами Docker есть несколько интересных особенностей. Бинарные анализаторы SCA проверяют слои образов Docker и ищут их в виде хеш-сумм в общедоступных базах данных уязвимостей, таких как Национальная база данных уязвимостей (NVD) или База данных уязвимостей Snyk .

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

Примеры популярных бинарных SCA-анализаторов

Бесплатное решение Сканирование контейнеров GitLab .

Решения с открытым исходным кодом:

• Пустяки
• Клер
• Виноград
• Набережная
• JFrog рентген
• Докер-Хаб

Docker Registry со встроенными анализаторами — Гавань .

Проверки во время тестирования: DAST, IAST и OAST.

На этом этапе выполняется динамическое тестирование серого ящика и тестирование черного ящика. Когда внутренняя структура приложения частично или полностью неизвестна, эти проверки безопасности выполняются путем имитации действий злоумышленника, который находит уязвимости и пытается «сломать» приложение, используя их. Давайте кратко обсудим каждый из них: DAST, IAST и OAST.

Проверка DAST во время тестирования

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

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

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

В этом случае сканер DAST выдаст некоторые ошибки, связанные с отсутствием шифрования трафика между клиентом (анализатором) и сервером (экземпляром приложения).

Примеры инструментов DAST

Инструменты, которые заслуживают вашего внимания:

• GitLab DAST — доступно только в Ultimate версии
• Прокси-сервер OWASP Zed Attack (ZAP) — решение с открытым исходным кодом, которое также используется в GitLab DAST.
• Акунетикс
• Укрепить WebInspect
• HCL Security AppScan
• Управляемый Synopsys DAST
• Tenable.io (Сканирование веб-приложений)
• Динамический анализ Veracode

Отлично, идем дальше.

Проверка IAST во время тестирования

IAST (интерактивное тестирование безопасности приложений) — это тестирование «серого ящика», которое сочетает в себе преимущества и сильные стороны тестирования «белого ящика» SAST и тестирования «черного ящика» DAST.

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

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

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

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

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

Примеры инструментов IAST

Вот отличные инструменты для вас:

• Искатель Синопсиса
• Интерактивный анализ Veracode
• Microfocus Fortify WebInspect
• Галочка CxIAST
• Контрастная оценка
• Обнаружение Hdiv (IAST)

Отлично, идем дальше.

Проверка OAST во время тестирования

OAST (внеполосное тестирование безопасности приложений) — это метод, разработанный ПортСвиггер и является расширением DAST, которое находит уязвимости, которые DAST не видит, например log4shell.

Примеры инструментов OAST

Я рекомендую вам:

• Люкс «Отрыжка»
• OWASP ZAP с Плагин OAST
• Услуги ОАСТ ХВАСТАТЬСЯ , ТукТук , и взаимодействовать

Двигаться дальше.

Проверки после развертывания

Это важнейший этап обеспечения безопасности и работоспособности приложения. В отличие от проверок pre-commit, которые выполняются на этапе разработки, проверки post-deploy позволяют выявить возможные проблемы уже во время работы приложения в естественной среде.

Мониторинг сохранности артефактов

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

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

Мониторинг безопасности приложений

Еще один способ обеспечить безопасность — следить за самим приложением. Для этого существует несколько технологий:

• Брандмауэр веб-приложений (WAF) — это инструмент фильтрации трафика. Он работает на уровне приложений и защищает веб-приложения путем анализа трафика HTTP/HTTPS.

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

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

В отличие от WAF, RASP работает внутри приложения и вместе с ним. WAF можно обмануть. Если злоумышленник изменит код приложения, WAF не сможет это обнаружить, поскольку не понимает контекст выполнения.

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

Технология RASP по умолчанию фокусируется на предотвращении атак. Система не требует доступа к исходному коду.

RASP дураки

Я рекомендую вам:

• Укрепить
• Экран
• ОпенРАСП это решение с открытым исходным кодом, разработанное Baidu
• Сигнальные науки
• Джскремблер
• Хдив
• Имперва

Отлично, идем дальше.

Визуализация результатов конвейеров DevSecOps и управление уязвимостями

На разных этапах Pipeline я использую множество анализаторов Application Security Testing/DevSecOps. Каждый из них формирует отчет в своем формате, а некоторые генерируют так называемые ложные срабатывания. Из-за этого нелегко анализировать безопасность приложения в целом.

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

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

Инструменты DevSecOps

В качестве панелей безопасности обычно используется широкий спектр инструментов: например, классические системы SOAR/SIEM и специализированный оркестратор DevSecOps AppSec.Hub от Swordfish Security или набор инструментов управления уязвимостями с открытым исходным кодом DefectDojo.

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

Однако приятно то, что разработчики и сопровождающие DefectDojo помогают разобраться в сложностях. Разработчики DefectDojo очень отзывчивые люди — мы рекомендуем обращаться к ним напрямую через раздел «Проблемы» на GitHub.

Концепция сдвига влево: подведем итоги

Еще раз, вот краткий обзор того, что было в статье.

Я объяснил, что такое концепция «Shift Left» и как она помогает сократить затраты на исправление ошибок и время разработки: чем раньше в процессе разработки вы начнете проверки безопасности, тем лучше.

Затем я деконструировал структуру конвейера DevSecOps и посмотрел, какие проверки безопасности выполняются на каждом этапе конвейера:

• Предварительная фиксация. Он подразумевает проверку безопасности исходного кода перед его попаданием в систему контроля версий.

• Предварительная сборка. Это проверка безопасности исходного кода в системе контроля версий (Secret Detection, SAST, SCA).

• Пост-сборка. Это проверка безопасности артефакта, созданного из исходного кода (Source SCA, Binary SCA).

• Время испытаний. Оно подразумевает тестирование безопасности приложения, запускаемого на основе собранного артефакта (DAST, IAST и OAST).

• После развертывания. Подразумевается проверка безопасности приложения после развертывания в производственной среде (WAF, RASP).

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