DevSecOps (безопасная разработка приложений) помогает выпускать устойчивые к угрозам ИТ-продукты, снижая риск появления уязвимостей. Методология объединяет средства автоматического анализа кода, сканеры контейнеров, а также набор организационных подходов.
- Введение
- DevSecOps и DevOps: в чём разница
- Чем грозят небезопасные процессы разработки
- Что включает в себя DevSecOps
- Выводы
Введение
Сейчас собственные отделы разработки есть у самых разных организаций. Бизнесу нужно учитывать ответственность и риски, которые связаны с выпуском собственных программных продуктов: ненайденные уязвимости могут стать причиной утечек, заражения систем вредоносными программами, компрометации инфраструктур контрагентов и партнёров.
Чем позже уязвимость обнаруживается в течение жизненного цикла ПО, тем дороже она обходится организации. По некоторым оценкам, стоимость устранения угрозы в продуктивной среде в 100 раз выше, чем при исправлении её до релиза.
Концепция DevSecOps разработана для снижения этих затрат и рисков, чтобы безопасность интегрировалась уже на ранних стадиях конвейера разработки.
DevSecOps и DevOps: в чём разница
Для начала проведём границу между DevOps и DevSecOps. Оба эти понятия обозначают методологии, объединяющие подходы к организации процессов, набор программных средств, прежде всего для автоматизации рабочих задач, и даже определённые «идеологические» компоненты.
DevOps служит тому, чтобы команды разработки могли быстрее создавать и развивать приложения. Эта концепция помогает перейти от крупных обновлений к небольшим регулярным релизам, сокращая время поставки продукта на рынок (Time-To-Market, TTM).
Внедрение DevOps предполагает высокую степень автоматизации на всём жизненном цикле разработки (Software Development Lifecycle, SDLC), переход от монолитной архитектуры приложений к микросервисной, миграцию в облачные среды и применение контейнеров для высокой масштабируемости и устойчивости продуктов к изменениям нагрузки.
Многие составляющие методологии DevOps значительно повышают угрозы безопасности. Автоматизация доставки, работа с микросервисами и контейнерами приводят к появлению множества «подкапотных» модулей, каждый из которых представляет собой фрагмент площади атаки. Кроме того, злоумышленники могут применять для своих целей и сами инструменты DevOps: серверы сборки, оркестраторы контейнеров, репозитории кода и т. д.
Если раньше вопросы безопасности становились актуальными ближе к концу разработки, на этапе тестирования, то теперь команды должны помнить о них на всём протяжении процесса.
Рисунок 1. Цикл разработки программного обеспечения: от анализа требований до передачи на поддержку. Источник: ZenTao
Средства защиты, автоматизации и безопасного управления процессами нужно внедрять практически на каждом этапе разработки. Именно эти задачи и решает DevSecOps. Как показывает практика, в сегодняшних условиях это — единственный надёжный способ защитить компанию, её партнёров и клиентов от кибератак.
Чем грозят небезопасные процессы разработки
Дело в том, что злоумышленникам требуется всё меньше времени, чтобы превратить ошибку в коде в оружие. Вот уже несколько лет исследователи обращают внимание на растущее число обнаруженных уязвимостей и сокращающееся время появления эксплойтов к ним (Time-To-Exploit, TTE).
По данным Google, в 2018–2019 годах среднее значение TTE составляло 63 дня, к началу 2021-го оно снизилось до 44 дней, а к концу 2022-го — до 32 дней. Выпуск исправлений к продукту вовсе не останавливает атаки: исследователи подсчитали, что основная часть эксплойтов начинают применяться уже в первые две недели.
Рисунок 2. На практике большинство уязвимостей получают применение сразу после публикации. Источник: Mandiant
Многие крупные атаки последних лет эксплуатировали уязвимости «нулевого дня» задолго до того, как разработчики смогли устранить угрозы. Приведём несколько примеров.
- CVE-2023-29059: хакерам удалось внедрить вредоносный код в приложение 3CX, которое обеспечивает корпоративную цифровую связь. Атаки коснулись версий для Windows и macOS; злоумышленники смогли перехватывать конфиденциальную информацию из пользовательских систем. От инцидентов страдали сотни тысяч организаций.
- CVE-2023-23397: уязвимость в Microsoft Outlook позволяла злоумышленникам получить несанкционированный доступ, отправив специально созданное электронное письмо. Эксплойт запускался при обработке сообщения в почтовом клиенте и не требовал действий со стороны пользователя. В результате злоумышленникам удавалось отправлять электронные письма от чужого лица и красть корпоративные данные.
- CVE-2023-38831: уязвимость в WinRAR, которая в 2023 году стала одной из самых популярных среди злоумышленников, активно применяли различные группировки. Киберпреступники отправляли жертвам специально созданные архивные файлы, чтобы обойти проверки безопасности и внедрить вредоносный код.
- CVE-2024-27198: уязвимость обхода аутентификации в сервере управления сборкой и непрерывной интеграции JetBrains TeamCity. Угроза была связана с ошибкой альтернативного пути доступа в веб-компоненте TeamCity. Злоумышленник мог обойти проверки аутентификации и получить несанкционированный доступ к хостам. В июле 2024 г. злоумышленники начали атаки через 22 минуты после публикации эксплойта.
- CVE-2024-4577: уязвимость удалённого выполнения кода в PHP обнаружили в мае 2024 года. Несмотря на оперативное устранение 0-day, эксперты сразу предупредили, что на практике обновление всех непропатченных систем может занять непредсказуемо долгое время. При этом атаки начались уже в течение дня после появления эксплойта; особенно активно эту брешь эксплуатировали операторы шифровальщиков.
Последние примеры показывают: выпуск исправлений безопасности может спровоцировать ещё большую волну атак. Причина — в том, что инструментарий сегодняшних киберпреступников упрощает им работу по применению уязвимостей.
Сейчас подготовить эксплойт можно с помощью того же ChatGPT. Это доказали исследователи Ричард Фанг (Richard Fang), Рохан Бинду (Rohan Bindu), Акул Гупта (Akul Gupta) и Дэниел Канг (Daniel Kang), которые смогли получить демонстрационный образец (proof-of-concept) к 15 реально существующим уязвимостям «первого дня».
Эксперты работали с версией GPT-4 и добились успеха в 87 % случаев. Они отметили, впрочем, что у метода есть технический порог: использовался очень подробный стимул (промт) с 91 строкой кода, в том числе с командами отладки и операторами регистрации. Кроме того, другие протестированные инструменты, включая GPT-3.5 и сканеры уязвимостей с открытым исходным кодом, не справились с задачей.
У GPT-4 также обнаружилось существенное ограничение: на успех сильно влияло наличие кода CVE, без которого успешный эксплойт получался только в 7 % случаев. Однако в случае 1-day это условие будет нетрудно соблюсти. Исследователи заключили, что ИБ-специалистам и поставщикам нейросетей нужно уже сейчас продумывать, как интегрировать большие языковые модели в системы защиты, как злоумышленники могут применять LLM и как им в этом помешать. Ведь очевидно, что даже если запретить ChatGPT писать эксплойты, злоумышленники смогут создать и собственные модели без таких ограничений.
Все эти особенности нынешнего ландшафта ИБ позволяют сделать главный вывод: разработчики не могут надеяться на патчи, нужно сдвигать безопасность влево на конвейере разработки, чтобы обнаруживать и устранять уязвимости до того, как они станут доступными для эксплуатации. Методология DevSecOps предлагает инструменты для достижения этих целей.
Что включает в себя DevSecOps
Как DevOps упрощает и автоматизирует разработку на каждой стадии конвейера, так и DevSecOps интегрирует безопасность во все фазы цикла создания ПО.
Благодаря сотрудничеству всех участвующих в работе над продуктом подразделений, автоматизации процедур и чётким процессам команды разделяют ответственность за вопросы безопасности. Это позволяет не оставлять задачи по защите приложения на этап тестирования, а планомерно решать их буквально с первых дней разработки, когда устранять проблемы проще и дешевле.
Основные цели DevSecOps:
- Свести к минимуму уязвимости, программные ошибки и другие угрозы в выпущенном программном обеспечении, не замедляя темпа релизов.
- Сократить потенциальный ущерб от реализации уязвимостей.
- Устранить возможные причины повторяющихся проблем, например за счёт непрерывного тестирования и улучшения методов разработки.
- Улучшить взаимодействие между разработчиками, специалистами по безопасности, продуктовыми командами для стабильной скорости и гибкости процессов.
Глобально внедрение DevSecOps означает принципиально новый подход к безопасности, который получил название «сдвиг влево» (Shift Left).
Что значит сдвинуть безопасность влево
Как говорилось выше, одна из ключевых проблем, которую призвана решать DevSecOps, — это то, что вопросы безопасности раньше появлялись в повестке дня только на этапе тестирования. Подход Shift Left предполагает, что о киберугрозах должны думать не только тестировщики и пентестеры, но и разработчики, аналитики, менеджеры и другие участники работы над продуктом.
Рисунок 3. Сдвиг влево означает, что над безопасностью продукта работают с первых дней проекта. Источник: APIsec
Интеграция безопасности в ранние этапы SDLC помогает нейтрализовать эти угрозы без лишних затрат, а главное — без риска реальных инцидентов. В значительной степени это — задачи организационного плана: разработчики должны учиться методам безопасного программирования, опираясь на рейтинги наподобие OWASP Top 10, проводить пересмотр (ревью) кода с привлечением внутренних и внешних экспертов.
Как это часто бывает в области ИБ, темы защищённости могут конфликтовать с вопросами скорости работы. Специалисты предостерегают компании от того, чтобы оценивать успешность спринта по одному TTM: уровень защищённости приложений должен стать не менее важным критерием. Это означает, что и продуктовым директорам, и ИБ-руководителям следует давать разработчикам достаточно времени для обеспечения безопасности.
Во многом это требует изменения концептуального видения процессов разработки. Однако помимо процессной составляющей DevSecOps опирается на комплекс технических решений.
Программные инструменты DevSecOps
В контексте DevSecOps автоматизация безопасности включает в себя набор инструментов для анализа кода и средства интеграции этих инструментов в автоматизированные конвейеры (пайплайны) CI / CD.
Статические и динамические анализаторы кода (SAST / DAST)
SAST (статическое тестирование безопасности приложений) и DAST (динамическое тестирование) — два основных типа инструментов для выявления программных уязвимостей.
Инструменты SAST используются на ранних этапах цикла разработки: во время программирования или до развёртывания приложения. Они работают по принципу «белого ящика», т. е. у анализатора есть полное представление о структуре программы.
SAST-системы могут находить ошибки и небезопасные шаблоны (например, SQL-инъекции, межсайтовый скриптинг, переполнение буфера), обнаруживать нарушения стандартов ИБ. Они предоставляют разработчикам подробную информацию об основной причине появления уязвимостей, значительно упрощая процедуру их устранения. Главное ограничение SAST — в том, что этими методами не удаётся проанализировать работающее приложение.
За эту часть отвечают инструменты DAST, которые имитируют атаки для выявления уязвимостей в реальной или промежуточной среде. Это больше похоже на «чёрный ящик», поскольку взаимодействие с приложением идёт без доступа к исходному коду, аналогично тому, как это делает злоумышленник.
Динамические анализаторы используются после развёртывания приложения или в среде тестирования. Они позволяют проверить, как программа ведёт себя в реальных сценариях.
Многие организации внедряют SAST и DAST вместе, чтобы реализовать комплексную стратегию ИБ. SAST обеспечивает раннее применение безопасных методов программирования, в то время как DAST выявляет проблемы, которые могут проявиться во время работы приложения.
Средства интерактивного тестирования безопасности приложений (IAST)
Инструменты IAST (Interactive Application Security Testing) объединяют элементы статического и динамического анализа, обеспечивая более комплексный подход к тестированию на различных этапах — например, во время проверки качества (QA) или в реальной среде.
Инструменты IAST действуют во время работы приложения, как и DAST, но они также имеют более глубокий обзор кода, как SAST. Для этого на веб-сервере или виртуальной машине, где работает программа, разворачиваются IAST-агенты, которые в настоящем времени отслеживают взаимодействие между кодом, данными и потоком выполнения, контролируют внутреннее состояние приложения, регистрируют входные и выходные данные.
В результате, в отличие от SAST и DAST, IAST может выявлять проблемы связанные с файлами конфигурации, недостатками логики сервера, приложения или сторонних библиотек, конфигурацией времени выполнения и специфичными для конкретной среды уязвимостями.
IAST требует более сложной настройки по сравнению с традиционными инструментами. Кроме того, инструменты IAST имеют повышенные требования к производительности, поэтому приложение может работать медленнее.
Решения для анализа компонентного состава (SCA)
Инструменты SCA (Software Composition Analysis) помогают управлять компонентами с открытым исходным кодом и сторонними модулями, которые всё чаще применяются в программной разработке. Эти средства анализируют кодовую базу для определения всех внешних библиотек и пакетов, используемых в приложении, а также прямых и косвенных зависимостей.
Ручное отслеживание подобных проблем может отнимать значительные ресурсы, особенно в крупных проектах. SCA-инструменты автоматизируют процесс, гарантируя, что ничего не будет упущено. Для проектов, которые в значительной степени зависят от библиотек с открытым исходным кодом и сторонних разработок, инструменты SCA предоставляют важные сведения об угрозах безопасности и юридических рисках.
Что выявляют инструменты SCA:
- уязвимости в сторонних библиотеках, такие как возможность переполнения буфера, выполнения SQL-инъекции и др.,
- устаревшие зависимости, которые больше не поддерживаются или имеют известные проблемы,
- проблемы с лицензиями — например, требование раскрытия исходного кода,
- угрозы из цепочек поставок, в том числе зависимости, которые исходят из ненадёжных источников.
Главное ограничение SCA — в том, что они используют базы данных известных уязвимостей. Таким образом, они не могут найти в сторонних компонентах неизвестные бреши или уязвимости «нулевого дня».
Сканирование контейнеров и сред разработки
С распространением парадигмы Cloud Native компаниям потребовались средства выявления уязвимостей, неверных конфигураций и проблем соответствия в новых архитектурах.
Сканеры контейнеров фокусируются на защите образов, т. е. приложений со всеми их зависимостями, собранных в портативный формат. Они ищут уязвимые пакеты, небезопасные базовые образы, неверные конфигурации, вшитые в код учётные данные или конфиденциальную информацию, хранящуюся внутри среды контейнера.
Эти инструменты сканируют образы контейнеров (например, Docker), анализируют библиотеки, двоичные файлы и зависимости. Далее компоненты внутри образа проверяются по известным базам уязвимостей, по аналогии с тем, как это делают SCA-системы. В результате удаётся выявить небезопасные программные пакеты или известные неверные конфигурации в базовых образах (скажем, устаревшие версии ОС и библиотек).
Сканеры контейнеров также проверяют конфигурации (доступные извне порты, небезопасные переменные, неверные разрешения для файлов), а в некоторых случаях — и соответствие политикам безопасности. Таким образом, в производственные среды смогут попасть только те образы, которые соответствуют заданным стандартам.
Инструменты сканирования среды разработки сосредоточены на обеспечении безопасности локальных машин программистов, IDE-сред, конвейеров CI / CD и инфраструктур, в которых те развёртываются (кластеры Kubernetes, облака). Они проверяют неправильные конфигурации облаков, определяют открытые S3-контейнеры, ошибки обеспечения доступа или некорректные настройки файрволов, ищут небезопасные сторонние библиотеки, жёстко закодированные ключи API, пароли и другую конфиденциальную информацию.
Компании используют такие сканеры, чтобы контролировать конфигурации публичных облачных сред (AWS, Azure, GCP), кластеров Kubernetes и серверов разработки. Многие подобные инструменты обладают возможностями аудита на соответствие практикам безопасности.
Выводы
Концепция DevSecOps помогает встроить информационную безопасность в саму практику разработки. Это уменьшает число уязвимостей в ПО без замедления процессов выпуска кода, а также укрепляет взаимодействие между продуктовыми командами и ИБ-специалистами.
Это — продолжение методологии DevOps, которая призвана снять с программистов рутинные задачи, автоматизировать проверки и сделать их частью самой культуры разработки. DevSecOps применяет эти принципы ко всему жизненному циклу программного обеспечения, чтобы вопросы безопасности прорабатывались на каждом этапе.
В результате все участники процессов начинают задумываться о том, как защитить приложение от киберпреступников и не допустить угроз корпоративным и пользовательским данным. Вероятность успешных кибератак снижается, а если злоумышленникам удаётся найти брешь, то их действия наносят значительно меньший ущерб.
