Стратегия DevSecOps (от development, security и operations — разработка, безопасность и операции) заключается в том, чтобы автоматизировать задачи выявления и устранения критичных ошибок и уязвимостей уже на ранних стадиях разработки приложений или сервисов. Анализ, тестирование, доставка и выпуск кода при этом выполняются в непрерывном режиме.
При классической схеме выявления проблем с безопасностью было заключительной фазой процесса создания ПО и сервисов, которой часто пренебрегали. Директор департамента по инструментам и технологиям выпуска версий и тестированию «Диасофт» Александр Захаров приводит такой типичный пример подхода к безопасности по остаточному признаку: «Нам часто приходится слышать слова о том, что раньше ведь жили без этого, у нас безопасность и так есть: приложение содержит электронную подпись для самопроверки на целостность, и хватит».
К тому же процесс тестирования в классическом режиме, как отметил руководитель направления по построению процессов безопасной разработки Positive Technologies Тимур Гильмуллин, сложен как с технической, так и с организационной точки зрения: «Программисты писали код и сами делали его сборку, тестировщики тестировали то, что им отдали программисты, а далее инженеры по эксплуатации вручную устанавливали это на «боевые» серверы. Добавьте сюда различные регламенты и противоречивые требования от команды специалистов по ИБ. А если все эти команды распределены по городам и разным часовым поясам, то разработка затягивалась на месяцы и годы. Сейчас мало кто захочет вернуться к тем временам. Чтобы решать такие проблемы, нужно объединить всех участников в едином и понятном для всех процессе».
В итоге данным этапом все чаще пренебрегали — по мере того, как количество релизов начинало превышать два за год. Последствия обычно не заставляли себя долго ждать. Наиболее ярким примером стала утечка данных о почти 150 млн клиентов из кредитного бюро Equifax, которая до сих пор является крупнейшей в истории. Только прямые потери на устранение последствий инцидента превысили $100 млн, а прибыль бюро снизилась на 27%. Причиной успеха кибератаки, которая и привела к утечке, стало использование уязвимых разделяемых библиотек.
Что дает DevSecOps
Еще задолго до начала пандемии скорость выхода приложений и сервисов стала главным параметром для разработчиков. Это и обусловило появление методологии быстрой разработки Agile и DevOps. Но когда эти методологии начали массово внедряться, прежний подход к обеспечению безопасности перестал работать. Но очень быстро появилась стратегия DevSecOps, направленная как раз на то, чтобы встроить методы безопасной разработки в процесс создания приложений, причем без потерь в скорости и гибкости.
Технический директор ISPsystem Игорь Десятников считает появление DevSecOps закономерным этапом развития концепции быстрой разработки: «DevSecOps органично выросла из DevOps. В крупных компаниях предполагается, что инженер по безопасности перед релизом продукта будет проверять код, в современных реалиях разработки это долго, нужно выпускать релизы быстрее и как можно чаще. Самый простой вариант — встроить инструменты проверки: безопасности в pipeline доставки — так появилась DevSecOps».
«DevSecOps — это не технология, а модель или подход, который позволяет встраивать безопасность в разработку и эксплуатацию ПО. По сути, можно применять любые технологии, позволяющие повышать уровень безопасности разрабатываемого продукта. Основное преимущество DevSecOps состоит в том, что она основана на принципе «Shift Left» — нахождении дефектов как можно раньше, всеми возможными способами», — такой видит суть концепции DevSecOps директор Центра продукта Solar appScreener ООО «Ростелеком-Солар» Даниил Чернов.
Как напомнил заслуженный системный инженер Cisco Михаил Кадер, формально методология DevOps была оформлена в конце 2000-х годов, требования по безопасности были включены немногим позже,
но при этом на концептуальном уровне основы были заложены существенно раньше: «И до появления DevSecOps во многих компаниях существовал подход по обязательному и многократному тестированию выпускаемых решений на предмет их безопасности. В качестве примера можно привести Secure Development Lifestyle компаний Cisco и Microsoft, которые в дальнейшем были доработаны с учетом методологии DevOps». По мнению эксперта по информационной безопасности ООО «Киберпроект» Евгения Родыгина, это произошло еще в конце 1990-х годов.
Тимур Гильмуллин напоминает: «В целом идеи тестирования ПО на безопасность не новы. Еще в конце 1980-х годов в России существовали ГОСТы по разработке и тестированию ПО (например, ГОСТ 28195-89), включающие пункты проверок на наличие ошибок в обслуживании при взаимодействии с пользователем, — фактически это были проверки на безопасность. Аналогичные стандарты были и за рубежом».
Руководитель направления по развитию бизнеса DevOps/DevSecOps компании Axoft Иван Соломатин видит сразу несколько плюсов от внедрения DevSecOps, хотя для этого необходимо выполнение некоторых важных условий:
«Если ваш интегратор или партнер-консультант умеет правильно описывать процессы и грамотно смог описать все перестроения внутри команд ИТ-подразделений, то на финише должны получиться следующие плюсы: ускорение вывода продукта на рынок (time-to-market); увеличение количества обнаружения уязвимостей еще до этапа сборки и ввода в эксплуатацию, их оперативное устранение; возможность перехода из проекта в проект и быстрое вовлечение сотрудников в рамках новой задачи. С точки зрения бизнеса, такой подход во всех случаях будет оправдан и выгоден, хотя на первых этапах придется основательно вложиться в развитие сотрудников, софтверного инструментария, а также расширить ИТ-инфраструктуру».
«Когда в компании безопасность полностью встроена в процесс разработки и проверка кода автоматизирована, можно рассчитывать, как минимум, на двукратное сокращение времени, которое тратится на устранение уязвимостей и ошибок в коде ПО», — делится наблюдениями Даниил Чернов.
«Ключевой целью внедрения DevOps изначально было повышение качества программных продуктов. С включением в процесс темы безопасности цель осталась прежней. Это связано с тем, что проблематика безопасности связана не только со свойствами кода программы, но и в большой части с условиями выполнения этого кода в целевой информационной системе,- делает вывод Евгений Родыгин.
— Выстраивается следующая цепочка неопределенности уязвимостей: уязвимость команды ≠ уязвимость функции ≠ уязвимость метода ≠ уязвимость класса ≠ компонента программы ≠ информационной системы. Например, небезопасная программа может состоять из полностью безопасных компонентов. Не утихают споры о том, какие свойства ПО считать безопасными, а какие нет».
По оценке DevOps-инженера ГК DZ Systems Ярослава Наконечникова, можно заметить явный тренд на внедрение DevSecOps: все больше компаний начинает применять эту методологию, появляется все больше различных сервисов, упрощающих интеграцию. Внедрять DevSecOps стало модно, а в крупнейших компаниях сегмента финтех это является фактическим стандартом.
«Залогом успеха формирования методологии и ее внедрения в практику разработки безопасного системного ПО является объединение в этом направлении усилий отечественных регуляторов, научного сообщества и разработчиков такого ПО. При этом специалисты ИСП РАН вносят свой вклад как научными исследованиями, созданием специализированных инструментальных средств, так и организационно, обеспечивая функционирование «Центра верификации ОС Linux», в рамках которого новые методы и инструменты применяются к компонентам ОС. Только в ядре ОС Linux специалистами Центра было выявлено и исправлено более 500 ошибок», — отметил в выступлении на Открытой конференции по безопасной разработке директор «Центра верификации ОС Linux» в Институте системного программирования РАН Алексей Хорошилов.
Так что не случайно активными сторонниками использования технологий безопасной разработки являются регуляторы, в том числе и российские. В нашей стране наибольшую активность проявляет Федеральная служба по экспортному и техническому контролю (ФСТЭК), что нашло отражение в приказах №55 и №239 данного ведомства. И это неудивительно, поскольку применение таких методик заметно упрощает проведение тестирования на наличие недекларируемых возможностей, что является важной частью процедур сертификации. В итоге, как отметил заместитель директора ФСТЭК Виталий Лютиков в выступлении на конференции OS Day 2021, процесс сертификации сокращается кратно, и будет занимать недели, а не месяцы. А уже с начала 2023 года применение несертифицированного ПО на объектах критической информационной инфраструктуры (КИИ) допускаться не будет. И именно позиция регуляторов, по мнению Евгения Родыгина, может стать в РФ главным драйвером внедрения DevSecOps и других методологий безопасной разработки.
Что нужно для DevSecOps
Важной частью методологии DevSecOps является широкое использование автоматизации для решения задач тестирования и анализа кода. И, как показало исследование Positive Technologies, результаты которого были опубликованы в сентябре 2021 года, использование инструментария является одной из основных сложностей при практическом внедрении.
При этом таких инструментов, как предупреждает Евгений Родыгин, много: «Инструментов огромное количество, они бывают внешние и внутренние, интегрированные в системы разработки или нет. Если внедрен DevOps, то зачастую можно найти дополнения к уже применяемым средствам».
Игорь Десятников предлагает классификацию таких инструментов: «Их можно условно разбить по категориям использования: инструменты интеграции (Jenkins, GitLab CI и проч.); среды разработки (Visual Studio, Intellij IDEA и проч.); анализ кода (SonarQube, Checkmarx, ручное ревью); дефект-трекеры (Jira, YouTrack, Bugzilla и проч.); инфраструктура (Docker, Terraform, Ansible и проч.)».
На разных стадиях процесса используются разные инструменты. Даниил Чернов приводит примеры: «Когда проверяется исходный код, применимы технологии статического анализа (SAST), SCA (Software Composition Analysis) и др. На стадии готового приложения, предшествующей эксплуатации, применим бинарный анализ, динамический анализ (DAST). Все это компоненты безопасности приложений. В целом здесь нет жестких требований к применению того или иного инструмента. Например, если приложение уже разработано и его нужно запустить в эксплуатацию, но в нем обнаружена уязвимость, то можно обеспечить защиту с помощью WAF на время, пока уязвимость будет устраняться разработчиками. DevSecOps — это модель, поэтому здесь применимы все технологии, обеспечивающие безопасность приложения».
Некоторые из этих инструментов не требуют установки и развертывания. «Один из лидеров в автоматизации процессов разработки — GitLab Enterprise Edition, удобный и хорошо проработанный универсальный веб-инструмент для разработки программного обеспечения», — приводит пример Ярослав Наконечников.
Как отмечает Александр Захаров, на рынке существует большое количество свободно распространяемых средств, что позволяет снизить расходы: «Сейчас много свободно распространяемого ПО для реализации этих практик. Конечно, совсем без расходов не получится, нужно приложить некоторые разумные усилия: продумать внедрение, развернуть продукты, подключить к конвейеру, исправить найденные в продукте уязвимости и другие недостатки, поддерживать выполнение этого процесса. Среди проприетарных продуктов также есть хороший выбор, тут нужно ориентироваться на потребности и возможности каждой организации». В Diasoft также применяют инструментарий собственной разработки.
Иван Соломатин рекомендует использовать хорошо известное на рынке ПО: «По опыту коммерческого рынка я выделил бы решения следующих игроков: Red Hat, Aqua Security, GitLab, Jfrog, SonarSource, Microfocus, Sonatype, Atlassian, Dynatrace. Самые популярные инструменты в Open Source — части, не требующие покупки: Kubernetes, Trivy, Jenkins, Teamcity, Cucumber, Terraform, Zabbix, Grafana, Prometheus».
Независимый эксперт и консультант в сфере безопасной разработки Денис Якимов предупреждает: «В погоне за маркетинговыми лозунгами компании так увлеклись встраиванием сканеров в пайплайны, что забыли про не менее важную часть безопасности разработки — инфраструктуру и цепочку поставок».
«Концепцию непрерывного и безопасного процесса разработки можно развивать только при условии интереса и инициативы самих сотрудников, которые трансформируются в комфортные для них инструменты, — уверен Тимур Гильмуллин. — Нужно, чтобы разработчики были заинтересованы в продуктах, чтобы эти решения их устраивали и были удобны в использовании. Многих проблем с безопасностью кода можно избежать еще на стадии разработки, если использовать сканеры уязвимости, такие как PT Application Inspector. При этом сканер кода, внедренный в конвейер разработки, не должен мешать программистам разрабатывать фичи, а работать параллельно с основными процессами сборки и блокировать выпуск релиза в случае обнаружения уязвимого кода».
Всем ли это нужно
Как показало исследование Positive Technologies, голоса опрошенных разделились ровно пополам на тех, кто уже внедрил DevSecOps или планирует это сделать, и тех, кто не считает нужным внедрять данную стратегию. По оценке Евгения Родыгина, в реальности ситуация еще более драматична, и те, кто полагает что внедрил DevSecOps, на самом деле применяет лишь отдельные его элементы для некоторых процессов. Как оказалось, для скептицизма есть целый комплекс причин. Например, значительная часть разработчиков просто не использует технологии быстрой разработки и может обойтись классическим подходом к тестированию.
На фоне активного развития импортозамещения растет и разработка ПО для отечественных аппаратных платформ. Но для них инструментарий безопасной разработки может отсутствовать. Как отметил начальник отдела «ОС реального времени и ОС Е90» АО «МЦСТ» Вадим Ревякин в выступлении на конференции OS Day 2021, многих анализаторов кода для архитектуры «Эльбрус» просто не существует.
К тому же внедрение DevSecOps является довольно трудоемким процессом. «Внедрение DevSecOps — процесс непростой, поэтапный и в некотором смысле болезненный, так как требует внесения изменений в культуру разработки и взаимоотношения в команде. Процесс занимает минимум два года, после чего процедуры не вызывают резкого отторжения, а результаты применяются. Также полноценное глубокое вовлечение в DevSecOps-процессы обязательно затрагивает корпоративную культуру компании, а это очень индивидуальная история», — полагает Евгений Родыгин. По его оценке, более экономически эффективно использование статического анализа кода, что позволяет при минимуме затрат устранить явные ошибки.
Тимур Гильмуллин не столь категоричен: «Когда мы внедряли сканер кода PT Application Inspector (комплексное SAST/DAST/IAST-решение), в первый раз это потребовало усилий двух CI-инженеров и одного инженера по инфраструктуре в течение нескольких месяцев работы. Но зато потом мы получили шаблоны и типовой процесс сканирования, тиражирование которых уже не отнимает много времени. Большее время тратится на разъяснительную работу и обучение конечных пользователей — программистов, работающих в продуктовых командах». Трудоемкость внедрения инструментов безопасной разработки зависит от множества факторов: масштабов проекта, готовности инфраструктуры, квалификации инженеров и принципиального желания самих разработчиков использовать инструменты DevSecOps.
В том же ключе высказался и Даниил Чернов: «Может оказаться и так, что все необходимые люди и инструменты для внедрения DevSecOps в компании есть, и нужно докупить совсем немногое, подстроить процессы — это будет легко и недорого. Но может оказаться и обратное: разработка слабая, процессы безопасности отсутствуют в принципе — тогда будет и трудоемко, и дорого».
По мнению Ивана Соломатина, во многом неготовность к внедрению DevSecOps связана с общим отставанием России от передовых стран: «Исторически, ИТ в России несколько отстает от западных стран, по внедрению популярных технологий — на 2-3 года. Пик применения этой методологии в РФ еще только близится, так как наше законодательство находится в процессе подготовки регулирующих требований к безопасной разработке. На данный момент есть только несколько правовых актов, которые относятся к этой тематике».
Михаил Кадер соглашается: «Основная причина — в том, что сам по себе подход DevOps и, соответственно DevSecOps рассчитаны на создание быстро изменяемого ПО, т.е. с микросервисной архитектурой, активно применяемой при разработке облачных сервисов. Так как Россия отстает по скорости внедрения облачных сервисов, то и количество компаний, применяющих этот подход, пока невелико. Хотя их количество непрерывно растет. Для тех компаний, которые «выпускают» облачные сервисы для своих внешних и внутренних пользователей, использование методологии DevSecOps — это просто часть стандартного процесса выпуска ПО».
Но, по общему мнению, ситуация будет меняться по мере роста настойчивости регуляторов и выхода на рынок кадров, которые привыкли использовать инструменты DevSecOps в практической работе.