Владимир Арышев, STEP LOGIC: DevSecOps – это не про мгновенные результаты

Владимир Арышев, эксперт по комплексным ИБ-проектам STEP LOGIC рассказал порталу Cyber Media о сложностях внедрения методики DevSecOps и ее перспективах.

Cyber Media: Как меняется отношение российских компаний к DevSecOps? Становятся ли популярнее эти инструменты?

Владимир Арышев: По данным аналитиков, в ближайшие годы более 90% зарубежных производителей ПО будут применять инструменты DevSecOps в том или ином виде. По России прогноз скромнее – всего около 30%. Но и эти цифры свидетельствуют о росте интереса к безопасной разработке.

Рынок, в свою очередь, активно реагирует на запросы – за последние пару лет появилось большое количество продуктов, предоставляющих инструментарий DevSecOps, в том числе отечественного производства. Их ассортимент расширяется за счет как лидеров отрасли (Aqua Security, Check Point, Positive Technologies), так и развивающихся игроков (Luntry, AppSec.Hub). Все они, безусловно, заслуживают внимания и изучения.

Cyber Media: Назовите топ-3 отраслей, которые дальше всех продвинулись на этом пути. Есть ли разница в выборе инструментов, в зависимости от специфики бизнеса?

Владимир Арышев: Безопасная разработка наиболее актуальна для компаний, предоставляющих своим клиентам ИТ-сервисы, зачастую в виде целых экосистем. Это, в первую очередь, банковский сектор, телеком, ритейл, транспорт.

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

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

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

Многие разработчики используют Cloud Native-подход – переходят в коммерческие облака, которые также нуждаются в контроле и защите.

Разработчики ПО «на заказ» обращают больше внимания на безопасность в части интеграции. В компаниях-заказчиках фокус сдвигается в сторону безопасности доставки. Полный набор инструментов DevSecOps применяется в компаниях, которые создают ПО «для себя».

Cyber Media: Как выглядит ваш средний заказчик?

Владимир Арышев: К нам обращаются как компании, которые разрабатывают ПО для внутренних потребностей, так и разработчики софта «на заказ». Они обладают развитой инфраструктурой DevOps и осознают важность приведения своего ПО к безопасному состоянию.

Как правило, в таких организациях уже используются инструменты проверки исходного кода (в т.ч. open source), однако чаще всего в самом конце цикла разработки. Поэтому наша первая задача – это перенос тестирования внутрь CI/CD pipeline для обеспечения возможности ранней корректировки кода, возможно, с заменой инструмента. Далее, если статический анализ работает адекватно, можно приступать к динамическому анализу и защите контейнеров или оркестрации.

Cyber Media: Про технический инструментарий более-менее понятно: DAST, SAST, автоматизация CI/CD, quality gates. Какие организационные меры, процессы и подходы дополняют эти системы?

Владимир Арышев: Допустим, компания выполнила внедрение инструментов DevSecOps, получив большое количество информации: ошибки, уязвимости кода, подозрительные сетевые взаимодействия и т.д.

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

В нашей практике недавно был случай, когда сотрудники отдела безопасности заказчика директивно решили проверять разрабатываемый код на наличие уязвимостей. Анализ кода выполнялся перед переводом ПО в продуктив. После каждой проверки на разработчиков «высыпался» огромный список уязвимостей, без устранения которых запуск приложения не согласовывался. Таким образом, из раза в раз список на доработку разрастался, а выход в продуктив откладывался. В итоге наша компания была привлечена в качестве подрядчика, задачами которого стал полный пересмотр процесса разработки и интеграция анализатора кода «в нужные места». 

Разработкой ПО часто занимается не одна, а несколько команд, каждая со своим уровнем развития, навыками и менталитетом. В начале внедрения технологий DevSecOps лучше выбирать команду с более высоким уровнем зрелости, которая готова совместно работать над повышением безопасности кода. Но, даже имея дело с опытной командой, не нужно внедрять сразу все возможные инструменты, стоит начать с наиболее понятного разработчикам решения, например, класса SCA (Software Composition Analysis), предназначенного для проверки применяемых в разработке библиотек. В дальнейшем успешный опыт внедрения можно распространить на другие команды.

Также стоит рассмотреть рекомендации различных организаций в сфере DevSecOps: OWASP DevSecOps Guideline, OWASP DevSecOps Verification Standard или более специфичный CTR Kubernetes Hardening Guide.

Cyber Media: Обрисуйте дорожную карту внедрения DevSecOps.

Cyber Media: Как быстро DevSecOps начинает приносить результаты? Сколько уходит, чтобы решения раскрыли полный потенциал?

Владимир Арышев: DevSecOps – это история не про мгновенные результаты. К примеру, при проверке исходного кода статическим анализатором на выходе разработчик видит длинный перечень возможных проблем, по каждой из которых необходимо сделать разбор и определить - это «false positive» или реальная уязвимость. Затем следует этап корректировки кода и только потом исправленное приложение переводится в продуктив. В среднем, весь процесс занимает от одного до трех месяцев.

Для «обучения» решений класса run-time protection также требуется время: на этапе ввода в действие разрабатываются политики безопасности, которые на начальной стадии применяются только в режиме мониторинга (detect), чтобы исключить влияние на существующие отлаженные процессы. Таким образом, период внедрения решения растягивается на один - два месяца.

Cyber Media: Некоторые эксперты говорят, что в ближайшей перспективе не стоит ожидать, что ИБ станет конкурентным преимуществом, которое будет помогать бизнесу продвигать свои продукты. Вы согласны с этим? Не может ли нынешняя волна кибератак поднять интерес аудитории к защите своих данных и, как следствие, заставить компании внедрять средства безопасной разработки?

Владимир Арышев: Судя по последним опросам, порядка 90% пользователей электронных сервисов не чувствуют, что их персональные данные надежно защищены. Каждый день мы получаем новости о крупных утечках данных из компаний. При таком информационном фоне внедрение DevSecOps действительно становится серьезным конкурентным преимуществом, доказывающим заботу бренда о своих клиентах.

Применение DevSecOps также положительно сказывается на сроках разработки и отношениях с заказчиками. Возьмем простую ситуацию - компания разработала ПО на заказ. Заказчик проверяет код анализаторами и возвращает обратно с длинным перечнем потенциальных уязвимостей. Исполнитель вносит корректировки, снова отправляет код, а в результате получает очередные требования для доработки. Несколько таких итераций – и вот разработчик уже рискует потерей не только клиента, но и репутации.

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