Об эксперте: Дмитрий Шилов, CTO, директор по технологическому развитию компании IT_One.
Для наиболее эффективной, быстрой и надежной разработки программного обеспечения и его вывода на рынок требуется тесное взаимодействие разных команд: не только программистов (Development) и системных администраторов (IT Operations), но также специалистов по информационной безопасности, которые тестируют софт на наличие уязвимостей и других потенциальных угроз.
Концепция, которая подразумевает сотрудничество этих подразделений и применение agile-подходов (таких, как технология непрерывной интеграции, доставки и развертывания кода CI/CD — автоматизированные практики, которые позволяют разработчикам чаще и надежнее развертывать изменения ПО), получила название DevOps. Сегодня под этим термином могут понимать и методологию, и культуру, и инструментальное обеспечение гибкой разработки.
DevSecOps — следующий этап развития DevOps, который меняет традиционное представление о роли подразделения ИБ (информационной безопасности, Security) в обеспечении качества и надежности кода. Если раньше, к примеру, специалист ИБ подключался к тестированию ПО на безопасность только после завершения основных этапов разработки, перед выпуском релиза, то сейчас его присутствие необходимо на всех этапах.
DevSecOps как требование времени
Тема DevSecOps долгое время считалась нишевой, поскольку для применения этой методологии компания должна соответствовать ряду критериев: например, иметь многочисленную команду разработчиков и практику автоматизации разработки (DevOps), потребность в быстром выводе продукта на рынок, ориентацию на микросервисную архитектуру (принцип создания ПО, при котором оно состоит из нескольких сервисов вместо одного большого монолита) и подход Infrastructure as Code (автоматизированный процесс настройки серверного оборудования).
Однако таких компаний в России становится все больше. Полноценные IT-подразделения — больше не привилегия крупнейших отраслевых игроков вроде «Сбера», «Тинькофф» или «Яндекса». Мы видим, как постепенно на рынке IT-компаний со своими программными продуктами появляются Ozon, «Авито» и многие другие «непрофильные» игроки. Разработка приложений силами собственных программистов позволяет им быстрее реагировать на запросы пользователей, меньше зависеть от внешних факторов и таким образом сохранять гибкость и конкурентоспособность в быстро меняющейся среде.
В то же время, разрабатывая софт как для клиентов, так и для внутренних задач автоматизации, компания должна гарантировать безопасность этих программных продуктов. В тысячах строк кода могут оставаться десятки уязвимостей, которые необходимо выявить и устранить. С ростом геополитической напряженности случился и всплеск кибератак на российские ресурсы, поэтому сейчас безопасность программного обеспечения — крайне актуальная задача. В первую очередь она касается финансовых организаций, но, учитывая «всеядность» злоумышленников, затрагивает и любую другую отрасль: ретейл, производство и так далее.
Получается, что команда разработки оказывается между двух огней: с одной стороны — требования бизнеса к скорейшему запуску новых продуктов и релизов. С другой — статистические данные, свидетельствующие о росте кибератак с использованием «дыр» в программном обеспечении. Positive Technologies в отчете «Актуальные киберугрозы: I квартал 2022 года» отмечает, что эксплуатация уязвимостей за отчетный период использовалась в 42% атак на организации.
Концепция DevSecOps призвана решить эту дилемму и предоставить разработчикам необходимые инструменты для интеграции ИБ в бизнес-процессы DevOps. Это действительно требование времени.
При традиционном подходе сначала разработчики создавали пилотную версию приложения, а затем служба ИБ испытывала ее на безопасность. Для тестирования ПО на возможность проникновения планировались специальные проекты, задействовались целые команды пентестеров (программист, который тестирует уязвимости информационных систем), тратились огромные бюджеты и время. Сегодня такая система неэффективна, и вот почему:
- в командах разработки практикуется методология непрерывной интеграции и развертывания кода (CI/CD), в которой нет места длительным задержкам на проверку ИБ;
- микросервисная архитектура, применяемая для создания современных приложений, гораздо сложнее монолитной, в том числе с точки зрения мониторинга угроз.
DevSecOps как критерий эффективности бизнеса
В случае DevSecOps безопасность становится неотъемлемой частью цикла разработки с самого начала. Проверки на уязвимость производятся на каждом этапе: в момент планирования архитектуры приложения, написания кода, сборки, тестирования и так далее. Уязвимости выявляются и устраняются сразу после их появления, а не накапливаются в приложении и тем более — не остаются в нем на момент ввода в продуктивную эксплуатацию. Этому способствует концепция Shift Left («сдвиг влево») — широко применяемая в DevSecOps практика, согласно которой задачи безопасности перемещаются с финального этапа цикла разработки в его начало.
Основная выгода DevSecOps для бизнеса — в экономии времени и бюджета на тестирование приложений службой ИБ, а также в большей гарантии защиты от критических инцидентов, связанных, в том числе, с угрозами «нулевого дня». Программные инструменты автоматически тестируют каждый новый фрагмент кода.
Как и DevOps, DevSecOps подразумевает высокую степень автоматизации процессов разработки, а значит — их ускорение и оптимизацию. Согласно отчету Google Accelerate State of DevOps 2021, в командах, применяющих принципы работы DevSecOps, развертывание кода происходит в 973 раза чаще, а восстановление после инцидента — в несколько тысяч раз быстрее.
К примеру, один из наших клиентов, крупная финансовая организация, уже более двух лет занимается интеграцией процессов контроля безопасности в разработку. За это время ей удалось сократить Time to Market (запуск) программных продуктов с трех месяцев до нескольких дней, учитывая при этом все требования информационной безопасности.
Новые вызовы DevSecOps в России
До недавнего времени одной из ключевых проблем при внедрении практик DevSecOps в России считалась проблема организационная, связанная с преодолением исторически сложившегося конфликта между разработчиками и безопасниками. Руководители ИБ зачастую придерживались консервативного подхода к безопасности и не всегда были готовы к взаимодействию и открытости. Эту сложность многие компании со временем преодолели.
Но появился новый нюанс: ограничение пула доступных инструментов DevSecOps. Большинство из них — это доработанный зарубежными вендорами Open Source, программные продукты на основе открытого кода, но с коммерческими лицензиями: системы тестирования, сканеры уязвимостей и прочее. Поскольку эти вендоры по большей части покинули российский рынок и прекратили поддержку своих продуктов, нам необходимы аналогичные по функциональности альтернативные решения.
То же касается платформ разработки, которые поддерживают весь жизненный цикл создания приложения от планирования до поставки и мониторинга. Если раньше наиболее популярными у разработчиков системами были Enterprise-версии GitLab и GitHub, то сейчас и они становятся недоступными. На замену им крупные компании создают самописные insource-решения на основе «голого» Open Source (готового кода другой компании, который берется, например, с того же GitHub) — довольно дорогостоящие в разработке и поддержке системы.
Решить эту проблему можно будет с появлением универсальной отечественной среды разработки — российской платформы, которая сможет контролировать все стадии создания приложения, отслеживать реализацию требований по кибербезопасности, выявлять проблемы и уязвимости и способствовать их устранению.
Кроме того, по-прежнему крайне важна организационная, а порой и психологическая составляющая DevSecOps: усиление взаимодействия разработчиков со специалистами по ИБ, взаимная интеграция их рабочих процессов. Подчеркну, что инициатива здесь может исходить не только от программистов. Безопасники должны проявлять активность не c этапа приемо-сдаточных испытаний, а с этапов планирования и проектирования: предъявляя необходимые требования и регламенты, анализируя риски и демонстрируя потенциальные ошибки и уязвимости. В этом им помогают программные инструменты разных классов — программы для анализа исходного кода, контейнеров, компонентов Open Source, для консолидации информации об уязвимостях и другие.