Меня зовут Тимур Гильмуллин, я руководитель направления по построению процессов безопасной разработки в компании Positive Technologies. Раньше я работал в DevOps-отделе, где инженеры занимаются автоматизацией различных процессов и помогают программистам и тестировщикам. В числе прочего мы проводили работы, связанные с внедрением инструментов безопасной разработки в CI/CD-конвейер. В этой статье я рассмотрю концепцию безопасной разработки DevSecOps (или SecDevOps) в целом: разберемся, что это за концепция, что она дает бизнесу, разработчикам, инженерам DevOps и безопасникам, какие инструменты можно при этом использовать и насколько трудоемко их внедрение.
Про DevSecOps
По версии компании «Майкрософт», методология DevSecOps подразумевает интеграцию процессов и внедрение инструментов безопасной разработки поверх уже выстроенных DevOps-процессов и работающих CI/CD-конвейеров.
Сами по себе идеи безопасной разработки и тестирования безопасности ПО не новы. Уже в конце 80-х годов в России существовали ГОСТы, например ГОСТ 28195-89, включающие в себя в том числе проверки на ошибки обслуживания, то есть нарушение порядка взаимодействия с программой со стороны пользователя, — фактически это были проверки безопасности. Аналогичные стандарты были и за рубежом. DevSecOps — это более современный подход к быстрой разработке надежного и безопасного продукта, учитывающий все последние технологические новинки в этой области.
Однако сами по себе процессы и безопасная разработка как сервис мало кого интересуют, важны лишь конечные результаты, к которым приводит внедрение идей и инструментов DevSecOps. К ним можно отнести:
быстрое и безопасное развертывание приложений в продакшн-окружении, то есть уменьшение времени time-to-market за счет автоматизации;
удешевление исправления ошибок и уязвимостей в ПО за счет их обнаружения на ранних этапах разработки;
снижение критических и неприемлемых рисков для вендора ПО, например, недопущение встраивания вредоносного кода в компоненты разрабатываемого продукта или защита инфраструктуры от атак типа supply chain.
Альтернативой процессам DevSecOps можно назвать только отказ от этих идей и возвращение к классическому подходу к разработке. Напомню, как это было до использования гибких методологий разработки и DevOps. Программисты писали код и сами же его собирали, тестировщики тестировали то, что им отдали программисты, а дальше инженеры по эксплуатации вручную устанавливали это на «боевые» серверы. Добавьте сюда различные регламенты и противоречивые требования команды безопасников. А еще — распределение всех этих команд по разным городам и разным часовым поясам. Разработка могла затянуться на месяцы и даже годы. Сейчас мало кто захочет вернуться к тем временам. Чтобы решать такие проблемы, нужно объединить всех участников в едином и понятном для них процессе. Это могут помочь сделать инженеры и идеологи подходов DevSecOps.
Построить DevOps-процессы и наладить автоматизацию разработки — задача сама по себе уже достаточно сложная и трудоемкая. Типовой процесс разработки включает в себя CI/CD-конвейер, который автоматизирует все этапы сборки продукта, деплой на тестовой инфраструктуре, проведение автотестов, продвижение продукта в релиз и его публикацию на серверах обновлений для дальнейшей доставки в инфраструктуру заказчика. Этот конвейер сопровождают на всех этапах DevOps-инженеры, к которым относятся инженеры по инфраструктуре и CI-инженеры. Они занимаются автоматизацией различных процессов разработки, помогают программистам и тестировщикам работать с продуктовыми конвейерами и инструментами автоматизации.
Security-часть необходимо внедрять в этот процесс комплексно, включая встраивание инструментов DevSecOps поверх конвейера разработки совместными усилиями инженеров IT, DevOps и специалистов-безопасников.
Про инструменты
Инструменты, обеспечивающие безопасность инфраструктуры и каждого из этапов разработки, могут быть различными. Есть множество вендоров, предлагающих отдельные технические инструменты, но очень мало тех, кто предлагает решения под ключ, обеспечивающие защиту всех этапов разработки, и в этом есть определенная проблема.
Кроме того, недостает и технических решений, тех же сканеров кода, которыми программист мог бы пользоваться самостоятельно. Я считаю, что в этом вопросе разработчикам сканеров следует двигаться в сторону исправления уязвимостей «одной кнопкой», без привлечения так называемых security champions — специалистов-безопасников. Программисты вряд ли захотят, чтобы такие специалисты постоянно сидели около них и объясняли, как исправлять уязвимости. Это как если бы рядом с пользователями редактора Word сажали учительницу русского языка, которая бы объясняла, почему редактор подчеркнул ошибку и как ее исправить :) Но для этого сканер кода должен включать в себя достаточно обширную базу знаний по уязвимостям и типовые шаблоны их исправления для большинства языков программирования.
Хотелось бы отметить, что само по себе сканирование кода не дает результатов. Подход должен быть комплексным: сканирование должно быть встроено в CI/CD-процесс, должны быть настроены правила безопасности (security gates) для автоматической блокировки сборки в случае обнаружения уязвимостей, а разработчики — пользователи сканера — должны пройти обучение.
Насколько сложно внедрить в компании процесс безопасной разработки? На мой взгляд, трудоемкость внедрения инструментов DevSecOps в CI/CD зависит от множества факторов: от масштабов проекта, готовности инфраструктуры разработки, достаточной квалификации инженеров и принципиального желания самих разработчиков использовать внедряемые инструменты. Два последних фактора я считаю наиболее важными. Инженеры и разработчики должны быть сами заинтересованы в использовании инструментов безопасной разработки, эти инструменты должны им нравиться, быть удобными и легко интегрироваться в CI/CD-конвейеры корпоративной разработки.
В одной из наших прошлых статей мы подробно рассказали о внедрении анализатора исходного кода PT Application Inspector (комплексное решение SAST/DAST/IAST) в DevSecOps-процессы одного из наших продуктов и о том, с какими нюансами при этом столкнулись. Тогда это потребовало усилий двух CI-инженеров и одного инженера по инфраструктуре на протяжении нескольких месяцев работы, включая разработку архитектуры внедрения сканера. Но зато потом мы получили шаблоны и типовой процесс сканирования кода, тиражирование которых уже не занимает много времени. Все эти наработки, включая шаблоны сканирования, мы выложили в опенсорс-проект dohq-ai-best-practices.
Как же организовать процесс безопасной разработки? Во-первых, прежде чем выстраивать DevSecOps-процессы, компания сначала должна построить DevOps-процессы. Для автоматизации процессов может использоваться любой CI/CD-конвейер, их достаточно много (GitLab CI/CD, GitHub Actions, TeamCity, Travis CI, Jenkins, CI платформы Microsoft Azure, AWS и Google).
Во-вторых, необходимо на уровне CI/CD-конвейера обеспечить защиту каждого этапа разработки и развертывания ПО. Ведь, согласно концепции shift left, чем раньше будут найдены потенциальные уязвимости в коде и инфраструктуре, тем дешевле будет стоить исправление этих ошибок. А если они будут обнаружены только в продакшн-окружении у заказчика, их исправление может привести даже к переделке всей архитектуры приложения.
Расположение SEC на схеме подразумевает, что security-процесс должен рассматриваться как непрерывный — так же, как и процессы разработки, деплоя, тестирования и доставки. То есть безопасность должна обеспечиваться соответствующими инструментами на каждом этапе технологического процесса.
На этапах разработки и сборки продукта для этого могут использоваться различные сканеры кода (например, PT Application Inspector). После развертывания продукта в тестовой среде могут быть использованы сканеры black box (например, PT BlackBox Scanner в составе MaxPatrol 8), которые фактически имитируют внешний пентест приложения. И, наконец, после завершения всех тестов, исправления найденных уязвимостей и развертывания продукта в продакшн-окружении, он может быть защищен от хакерских атак межсетевым экраном (например, таким как PT Application Firewall). Кстати, PT Application Firewall может защитить не только разрабатываемый продукт, но и вообще любые корпоративные приложения и сервисы, в том числе от 0-day атак (например, он из коробки умеет предотвращать эксплуатацию критической уязвимости в Apache Log4j 2, затрагивающей большое число Java-проектов).
Дальнейший контроль за инфраструктурой и развернутым продуктом может вестись более комплексными системами аудита ИБ и SIEM-системами, такими как MaxPatrol SIEM, системой управления уязвимостями MaxPatrol VM, а также системами контроля трафика по всей сети, где развернуто приложение, для предотвращения хакерских атак. Например, системой анализа трафика PT Network Attack Discovery, которая умеет выявлять техники MITRE ATT&CK. Дополнительно обеспечить безопасность серверов можно при помощи PT Sandbox — песочницы для выявления сложных атак с применением вредоносного ПО, или системы антивирусной защиты PT MultiScanner.
В-третьих, необходимо обеспечить безопасное развертывание всей инфраструктуры, виртуальной или «железной». Для этого используется множество инструментов и подходов, в том числе написание сценариев подготовки и развертывания инфраструктуры через SaltStack, Ansible, Kubernetes или OpenShift. О технологических новинках из мира построения безопасной инфраструктуры можно узнавать на различных ресурсах, например, в канале DevSecOps Wine. Его автор, Денис Якимов, участвуя в одном исследовании нашей компании, подчеркнул важность правильного выбора подходов DevSecOps: «В погоне за маркетинговыми лозунгами shift left компании так увлеклись встраиванием сканеров в пайплайны, что забыли про не менее важную часть безопасности разработки — инфраструктуру и цепочку поставок».
Неизменяемая и версионированная инфраструктура также важна, потому что DevOps-инженерам необходимо обеспечивать повторяемость сборок для одного и того же коммита в кодовой базе. Оркестрация контейнеров сборки помогает избежать досадных проблем, которые могут возникать при ручном конфигурировании инфраструктуры (например, как это было в недавнем нашумевшем случае с «Фейсбуком»). Не менее важна и защита самих контейнеров сборки — минимальный базовый образ и использование минимальных привилегий для запуска приложений внутри контейнера, использование систем аудита для контроля запущенных процессов и сетевой активности.
Ко всем перечисленным инструментам можно добавить следующие:
внедрение в пайплайны сборки автоматизированных тестов безопасности (функции безопасности должны тестироваться так же качественно, как и основная функциональность продукта);
автоматическая проверка сторонних зависимостей (например, с помощью OWASP Dependency-Check);
внедрение ролевой модели доступа к ресурсам разрабатываемого продукта;
защита кодовой базы (например, подписывание коммитов в хранилище и использование верификации коммитов);
цифровая подпись собранных компонентов (например, при помощи SignTool) и ее проверка при формировании бандла (инсталлятора) продукта из этих компонентов.
О безопасной разработке в части процессов и инструментов много было сказано на встрече Positive Tech Press Club с экспертами в области DevOps, DevSecOps, AppSec и защиты инфраструктуры. Участники встречи рассказали о трендовых угрозах и примерах кибератак, которые стали возможны из-за брешей в исходном коде, а также обсудили, нужна ли компаниям безопасная разработка, как эксперты оценивают степень проникновения этого подхода в российский бизнес и какие результаты уже достигнуты.
Отдельной темой беседы стало обсуждение элементов DevSecOps и SSDL не только в плане технологий и инструментов, но и культуры безопасной разработки, подходов и принципов. Из важного стоит отметить, что мнения экспертов по поводу того, безопасность каких элементов процесса разработки необходимо обеспечить в первую очередь, разделились. Кто-то считает, что самое важное — защитить инфраструктуру разработки и эксплуатации, а другие, что инфраструктура вторична и что главное — это защитить само приложение и сделать безопасным код. То есть ключевые элементы DevSecOps — это безопасная инфраструктура для CI/CD-конвейера и процесс безопасной разработки, работающий поверх этой инфраструктуры.
Если обобщить мнения экспертов, то можно дать следующую комплексную формулу: DevSecOps = AppSec + SecDev + Infrastructure Security. В каждом из этих трех направлений кибербезопасности нужно, конечно же, исходить из лучших его практик.
Про культуру
По мнению специалистов «Тинькофф», «безопасность как сервис» часто интерпретируется только в контексте предоставления шаблонов подключения WAF/SAST/DAST и прочих инструментов ИБ, которые могут быть легко встроены в CI/CD-конвейер через IaC (infrastructure as code). При этом каждый разработчик может сам встроить все проверки безопасности отдельными шагами в свой сборочный процесс. Но здесь есть проблемы, тормозящие внедрение культуры безопасной разработки, с которыми часто сталкиваются крупные компании:
До сих пор в компаниях не везде есть единый согласованный CI, под который нужно писать шаблоны. Часто бывает «зоопарк» технологий: одновременно могут использоваться TeamCity, GitLab CI/CD, TFS, Jenkins и самописные системы сборки.
До сих пор есть разработчики, которые собирают код руками и выкладывают артефакты сборки в хранилище, вперемешку с артефактами, собранными автоматически.
Разработчики могут просто отключить шаги безопасности или не встраивать их в свой сборочный процесс, а у команды ИБ нет механизмов по своевременному выявлению таких ситуаций.
Все инструментальные решения имеют свой воркфлоу по работе с уязвимостями. Где-то проставляются комментарии и статусы в трекере или в системе контроля версий, а где-то таких механизмов в принципе нет. У многих инструментов вообще нет UI.
У каждого решения есть своя консоль управления и, соответственно, свой набор доступов, который нужно предоставлять для разработчиков и безопасников. А это приводит к большему усложнению и без того сложных ролевых политик компании.
Специалистов со стороны ИБ, как правило, всего несколько человек, а разработчиков сотни. Это приводит к классической проблеме «вас много, а я один», из-за чего разработчикам просто не хочется обращаться к безопасникам.
В итоге для решения указанных проблем команды разработчиков из крупных компаний с большой разношерстной инфраструктурой разработки постепенно приходят к концепции предоставления безопасности не просто в виде шаблонов, а в виде полноценного внутрикорпоративного SaaS-решения — платформе DevSecOps/AppSec, или «безопасности под ключ».
Тем не менее простое внедрение подходов и инструментов DevSecOps не приведет к одномоментной трансформации всей инфраструктуры компании в сторону большей безопасности. Здесь нет универсальных решений. Для успешного развития идей безопасной разработки в компании должны сложиться определенная культура разработки и тесное сотрудничество между безопасниками и различными группами инженеров. Однако многие компании по-прежнему ведут разработку, используя традиционные подходы, где инженеры по эксплуатации, разработчики и безопасники достаточно сильно изолированы друг от друга. Это подтверждается и нашим опросом о состоянии безопасной разработки в компаниях — вендорах ПО.
Только треть опрошенных инженеров сообщили, что компании, в которых они работают, включили меры по обеспечению безопасности в цикл разработки ПО. А половина опрошенных готовы участвовать в DevSecOps-процессах, только если у них появится понимание, что этот подход сможет защитить разрабатываемые продукты от хакеров. Здесь я бы рекомендовал инженерам, разработчикам и руководителям разработки ПО принимать участие в различных профильных конференциях по кибербезопасности, хакатонах и киберучениях (например, The Standoff или PHDays), где они смогут приобрести необходимые знания и навыки, в том числе по безопасной разработке.
Руководителям компаний и подразделений разработки также стоит поощрять культуру сотрудничества между инженерами служб ИБ, ИТ, DevOps и самими разработчиками. DevSecOps-специалисты, которые им помогают, должны быть хорошо знакомы с процессами и методологиями разработки, принятыми в конкретной компании. Кроме того, они должны не только очень хорошо разбираться в вопросах безопасности, но и уметь донести свое видение до всех участников процесса разработки.
DevSecOps — это не только про инструменты или конкретный набор технологий, но еще и про новое глобальное направление в компании. Для его развития нужен ответственный человек, который будет его идеологом, а также заинтересованные инженеры и программисты в командах. Понятно, что процессы разработки различаются в каждой компании, у всех есть своя специфика. Но, несмотря на все преимущества подходов безопасной разработки, многие компании все еще сомневаются в принятии DevSecOps. Как и DevOps, который когда-то изменил подходы к разработке ПО, идеи DevSecOps также требуют изменений в способе мышления. Современные компании должны понять, что ответственность за безопасность лежит на всех участниках процесса разработки, а не только на специалистах по информационной безопасности. Внедрить идеи DevSecOps будет непросто, но изменения того стоят.
Дополнительные материалы по теме DevOps и DevSecOps
Личный опыт: как выглядит наша система Continuous Integration (2016)
Автоматизация процессов разработки: как мы в Positive Technologies внедряли идеи DevOps (2017)
Моделирование производственных процессов в ИТ-компании (2018)
Управление хаосом: наводим порядок с помощью технологической карты (2019)
Личный опыт: как выстроить карьерный рост в отделе DevOps (2020)
DevSecOps: как мы внедряли PT Application Inspector в наш продуктовый конвейер (2020)
DevSecOps. PT Application Inspector в разработке ПО: блокировка релиза (2021)
Positive Technologies: опыт внедрения инструментов DevSecOps (2021)
Безопасная разработка: как жить в цифре, писать много кода и не стать жертвой хакеров (2021)
Если вам интересна тема кибербезопасности и безопасной разработки, следите за нашими вебинарами и новыми статьями в этом блоге. На этом пока все, ждем ваших вопросов в комментариях :)
