Разработка под защитой: как внедрить в компании DevSecOps
Компании, регулярно разрабатывающие программное обеспечение, рано или поздно сталкиваются с универсальным принципом: чем раньше выявляется уязвимость, тем менее затратно ее устранение. Ведь в некоторых случаях разница в стоимости может составлять несколько порядков. Особую значимость это правило приобрело на фоне ухода большинства иностранных вендоров, в результате которого многие отечественные компании активизировали процессы внутренней разработки.
Практики и инструменты DevSecOps
В последние годы на российском рынке появилось много продуктов, предоставляющих инструментарий DevSecOps. Их ассортимент расширяется за счет как доступных иностранных вендоров, например Aqua Security и Checkmarx, так и отечественных — сегодня подобные решения предлагают Kaspersky, Positive Technologies, Swordfish Security, Ростелеком Солар, Code Scoring, Антифишинг, Luntry и другие.
Учитывая «зоопарк» продуктов и технологий, многим компаниям пока сложно самостоятельно выстроить процесс безопасной разработки, поэтому они обращаются к опытным ИБ-интеграторам. Среди наших заказчиков есть как компании, которые разрабатывают ПО для внутренних потребностей, так и разработчики софта на заказ. Как правило, они обладают развитой инфраструктурой разработки, используют практики DevOps и осознают важность приведения своего ПО к безопасному состоянию.
Основной задачей данных проектов является интеграция в существующий процесс разработки практик и инструментов DevSecOps, позволяющих значительно уменьшить стоимость исправления уязвимостей и снизить вероятность успешных атак на приложения и связанных с ними материальных и репутационных рисков. Среди них:
-
Управление требованиями ИБ — формулировка и управление требованиями по информационной безопасности к приложениям в зависимости от актуальных угроз.
-
Обучение персонала — формирование навыков безопасного кода без отрыва от рабочего процесса.
-
Композиционный анализ ПО для проверки проекта на наличие проблемных зависимостей.
-
Статический анализ исходного кода методом white box, при котором тестировщик обладает всей информацией о приложении.
-
Поиск секретов, которые могут быть вшиты разработчиками.
-
Динамический анализ запущенного приложения методом black box, при котором у тестировщика нет информации о приложении.
-
Интерактивное тестирование методом gray box, которое позволяет анализировать приложение изнутри во время его работы.
-
Анализ уязвимостей всех компонентов образов контейнеров: базового ПО, переменных окружения и других слоев.
-
Создание безопасной конфигурации инфраструктуры.
-
Автоматическая проверка конфигураций средств контейнеризации, контроль взаимодействия между контейнерами, сбор и анализ событий, поступающих от контейнеров.
-
Межсетевой экран уровня приложений для выявления и блокировки атак на веб-приложения, в том числе с использованием уязвимостей нулевого дня.
- Управление средствами DevSecOps для обеспечения оркестрации, корреляции и аналитики.
В DevOps широко применяется CI/CD pipeline — автоматизированный процесс, обеспечивающий непрерывную интеграцию и непрерывную доставку. Он позволяет разработчикам вносить изменения в код и интегрировать их в основную ветку разработки в режиме реального времени, проводить тесты, готовить продукт для продуктива вплоть до выполнения автоматического развертывания.
На практике мы часто сталкиваемся с тем, что заказчик уже использует инструменты проверки исходного кода (в том числе компонентов open source) в самом конце цикла разработки. Поэтому первоочередной задачей становится так называемый Shift Left, перенос тестирования внутрь CI/CD pipeline для обеспечения возможности ранней корректировки кода, возможно, с заменой самого инструмента. Далее, если статический анализ работает адекватно, можно приступать к динамическому анализу и защите контейнеров или оркестрации.
Дорожная карта внедрения DevSecOps
Примерный алгоритм интеграции практик DevSecOps в процесс разработки выглядит следующим образом:
Допустим, компания выполнила внедрение инструментов DevSecOps, получив большое количество информации: ошибки, уязвимости кода, подозрительные сетевые взаимодействия и т. д. Но дальше у нее возникает логичный вопрос: что с этим делать?
По опыту работы с нашими заказчиками, самое важное — выстроить диалог между службами ИБ и разработчиками. Разработчики должны понимать, что происходит и зачем пытаются влиять на их код, а безопасники — четко представлять нюансы реализации технологий DevOps в компании.
В нашей практике был случай, когда сотрудники отдела безопасности заказчика директивно решили проверять разрабатываемый код на наличие уязвимостей. Анализ кода выполнялся перед переводом ПО в продуктив. После каждой проверки на разработчиков «высыпался» огромный список уязвимостей, без устранения которых запуск приложения не согласовывался. Таким образом, из раза в раз список на доработку разрастался, а выход в продуктив откладывался. В итоге наша компания была привлечена в качестве подрядчика, задачами которого стал полный пересмотр процесса разработки и интеграция анализатора кода «в нужные места».
Разработкой ПО часто занимается не одна, а несколько команд, каждая со своим уровнем развития, навыками и менталитетом. При внедрении технологий DevSecOps мы рекомендуем выбирать команду с более высоким уровнем зрелости, которая готова совместно работать над повышением безопасности кода. Если разработчики понимают важность ИБ и владеют навыками безопасного кода, процесс внедрения проходит гораздо легче и эффективнее. Для обучения команды и тренировки Security Champion пользуются популярностью специализированные курсы.
Но, даже имея дело с опытной командой, не следует внедрять сразу все возможные инструменты, можно начать с наиболее понятного разработчикам решения — например, класса SCA, предназначенного для проверки проекта на наличие проблемных зависимостей. В дальнейшем успешный опыт внедрения распространяется на другие команды.
Вместе с этим следует помнить, что DevSecOps — это история не про мгновенные результаты. К примеру, при проверке исходного кода статическим анализатором на выходе разработчик видит длинный перечень возможных проблем, по каждой из которых необходимо сделать разбор и определить — это false positive, или реальная уязвимость. Затем следует этап корректировки кода, новое сканирование анализатором и новая корректировка, и так далее до получения приемлемого с точки зрения ИБ результата. Только потом исправленное приложение переводится в продуктив. В среднем весь процесс обычно занимает до трех месяцев.
Безопасная разработка как конкурентное преимущество
По данным аналитиков, 50% компаний подвергаются атакам из-за уязвимости в исходном коде веб-приложений. Если к этому добавить многочисленные новости о крупных утечках данных, то внедрение DevSecOps действительно становится серьезным конкурентным преимуществом, доказывающим заботу бренда о клиентах и партнерах.
Применение DevSecOps также положительно сказывается на сроках разработки и отношениях с заказчиками. Возьмем простую ситуацию — компания разработала ПО на заказ. Заказчик проверяет код анализаторами и возвращает обратно с длинным перечнем потенциальных уязвимостей. Исполнитель вносит корректировки, снова отправляет код, а в результате получает очередные требования для доработки. Несколько таких итераций – и вот разработчик уже рискует потерей не только клиента, но и репутации.
В целом, безопасная разработка — важная часть комплексного обеспечения корпоративной безопасности. DevSecOps — это циклический процесс, требующий непрерывных итераций и применения кода в каждом новом развертывании, но его внедрение позволяет уменьшить стоимость исправления уязвимостей, автоматизировать процессы, сокращая трудозатраты персонала, и повысить качество ПО.
Реклама ООО"СТЭП ЛОДЖИК" erid: LjN8JvMB5
Опубликовано 26.06.2023
