DevSecOps: как российским компаниям выстроить процессы безопасной разработки

Развитие DevSecOps – один из главных трендов в современной ИТ-разработке. Понятие объединяет подходы, инструменты и технологии, позволяющие с первых дней работы над продуктом защитить его от взлома и утечек данных. Журналист портала Cyber Media обсудил с экспертами рынка, как выстраивается DevSecOps и что нужно для быстрого получения результатов.

В подготовке материала приняли участие:

Роман Карпов, Руководитель комитета по ИБ АРПП «Отечественный софт», Директор по стратегии и развитию технологий Axiom JDK компании «БЕЛЛСОФТ», Советник Министра цифрового развития по системному ПО

Сергей Черномашенцев, исполнительный директор «Смарт-Софт»

Антон Прокофьев, руководитель технического взаимодействия с клиентами центра Solar appScreener компании «РТК-Солар»

Роман Кравцов, технический директор NGR Softlab

Сергей Головашов, ведущий инженер DevOps, руководитель центра компетенций, Bell Integrator

Алексей Смирнов, основатель CodeScoring

Cyber Media: Что представляет собой DevSecOps как парадигма?

Роман Карпов, «БЕЛЛСОФТ»

DevSecOps – это эволюция идей DevOps с учетом обеспечения безопасности. Согласно концепции DevSecOps, нужно учитывать вопросы ИБ на всех ключевых этапах и переходных процессах разработки и обслуживания. Сюда входит непрерывная интеграция (CI), непрерывная поставка и развертывание (CD).

Следует понимать, что по-настоящему безопасные системы должны изначально проектироваться с учетом вопросов безопасности и проносить эту идею вдоль всего жизненного цикла продукта.

Сергей Черномашенцев, «Смарт-Софт»

Очень важно, чтобы разработчик писал код, который поддается диагностике. И для этого тоже существует ряд правил и мер. Процесс основан на том, что перед каждым релизом, после каждой строчки кода, после каждого написанного раздела необходимо провести определенное тестирование.

Антон Прокофьев, «РТК-Солар»

Инструменты, которые позволяют обеспечить DevSecOps-подход – это SAST, DAST, SCA и пентест.

Роман Кравцов, NGR Softlab

Внедрение DevSecOps основывается на трех базовых положениях:

1. Обеспечение безопасности на протяжении всего цикла разработки ПО, его цель – минимизация уязвимостей в программном коде.
2. Общая ответственность команды (DevOps, разработчиков, QA и инженеров экспликации) за соблюдение требований безопасности.
3. Автоматическая проверка безопасности на всех этапах поставки ПО благодаря интеграции средств контроля, инструментов и процессов обеспечения безопасности в рабочий процесс DevOps.

Сергей Головашов, Bell Integrator

Преимущества DevSecOps – это, прежде всего, снижение расходов на стадии поддержки продукта. Если еще до релиза исключить критические уязвимости (CVE, CWE) и баги, то не понадобится выпускать исправления или вовсе отзывать продукт с рынка.

Еще одно преимущество – это соответствие российским и международным комплаенс-требованиям: ЦБ РФ для финансовых учреждений. Cloud Security Alliance (CSA), Cloud Native Computing Foundation (CNCF), PCI DSS, GDPR и т.д. Это дает возможность проходить аудиты контролирующих органов, получать соответствующие лицензии и сертификаты на вид деятельности (особенно критично для бирж, обменников, систем банк-клиент), подтверждать свою ответственность перед клиентами и партнерами.

И непосредственно – это внутренняя инфраструктурная безопасность облачной среды, которую периодически пытаются взломать хакерские группы, боты и потенциально нечестные конкуренты по нише, разделяемой на рынке. Средствами исключительно стандартного DevOps эти вопросы никогда не решить.

Cyber Media: Насколько DevSecOps меняет устоявшийся конвейер разработки с точки зрения процессов, если до этого компания не применяла никакие подобные средства?

Роман Карпов, «БЕЛЛСОФТ»

DevSecOps – новая ступень в эволюции представлений об обеспечении информационной безопасности. Согласно данным DevOps Institute, 56% респондентов считают DevSecOps важнейшим трендом в категории инструментов автоматизации, который обязательно (must-have) учитывать.

Разработка и внедрение современных продуктов и сервисов проходит длинный путь – от выбора библиотек-зависимостей на GitHub до обеспечения системы в промышленной эксплуатации свежими обновлениями, эффективной поддержкой и своевременными патчами безопасности. Если где-то по пути разработка или эксплуатация не справилась с вопросами безопасности, о такой работе могут написать во всех новостях – но не в том ключе, в каком хотелось бы. Всем известны громкие кейсы, которые являются следствием не столько программных ошибок, сколько неправильной организации процессов и автоматизации.

DevOps решает проблему взаимодействия между людьми и отделами. Так исторически сложилось, что программисты, безопасники, сисадмины (и, на самом деле, многие другие специальности) имеют друг к другу множество неприятных вопросов, либо приучены работать в изоляции. Проблема решается с помощью комплекса технических и процессных мер.

Тем не менее, можно ориентироваться на устоявшиеся мировые практики. Хорошим примером является процесс безопасной разработки SDL (secure development lifecycle). В частности, он внедрен у нас в компании и показывает отличные результаты.

Нужно понимать, что никогда не будет момента, когда можно сказать «мы внедрили DevSecOps», и расслабиться. Это долгая, последовательная работа над улучшением процессов.

Сергей Черномашенцев, «Смарт-Софт»

С точки зрения процессов, если до этого компания не применяла подобные средства, то в целом это прямо все кардинально по-другому. Если вы планируете ввести безопасную разработку и принимаете в команду человека на эту задачу, он начнет все-все-все переделывать: принципы разработки, тестирования, проверок и т.д.

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

Переход на новые процессы, если люди вообще раньше с этим не сталкивались, будет занимать около года. Этот год нужен для того, чтобы разработчики вникли в тему, написали определенные регламенты, переделали текущие регламенты под новые, научились пользоваться всеми необходимыми инструментами.

Если требуется перейти быстрее, то можно пригласить какую-нибудь стороннюю команду. Есть отличные, сертифицированные ФСТЭКом ФСБ испытательные лаборатории, которые за разумную цену всю разработку могут перевести на безопасную в течение двух месяцев. А дальше, соответственно, начнется процесс адаптации. Он уже может длиться до полугода.

Одна из трудностей заключается в том, что довольно большое количество зарубежных инструментов перестали быть доступными для покупки отечественными разработчиками. У нас есть Институт системного программирования РАН, где созданы инструменты для статического и динамического анализов кода. Сотрудники института очень активно общаются с разработчиками. Но что касается только глобального программного обеспечения.

Сергей Головашов, Bell Integrator

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

Осознание современных угроз и скрытых рисков, понимание того, как баг может повлиять на конечный продукт, знание средств и систем защиты – все это поможет выстроить некую дорожную карту того, как необходимо внедрять DevSecOps-практики в каждодневную работу команды разработчиков и DevOps-инженеров.

Самое сложное, что специалистов такого уровня в РФ не учат: это должна быть смесь бумажного безопасника (которых у нас сейчас хватает) и программиста-хакера, который должен уметь читать исходный код и понимать, что он делает.

Cyber Media: Как обстоят дела в российских компаниях?

Роман Карпов, «БЕЛЛСОФТ»

Мы как разработчик отечественной Java-платформы особое внимание уделяем безопасности. Все наши продукты линейки Axiom JDK, доверенной среды исполнения Java, и Libercat, стандартизованного сервера приложений, разрабатываются в концепции SDL, что позволяет поддерживать защищенность систем на их основе как на этапе построения, так и на протяжении всего срока эксплуатации.

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

• Проверку концепции ( PoC, proof-of-concept) для подтверждения безопасности рантайма в рамках тестирования на уязвимости
• Регрессионное тестирование с применением инструментов Java Regression Test Harness (jtreg) и фреймворков Spring и Apache Tomcat
• Бенчмаркинг (тесты SPECjbb и SPECjvm, JMH, микробенчмарки OpenJDK) для измерения производительности

Наши клиенты, среди которых Платежная система «Мир», фирма «1С», М.Видео, Альфа-банк, ценят такой подход наших инженеров к разработке продуктов. И большинство из них так или иначе задумывается над вопросами DevSecOps и ежедневно внедряет хорошие практики.

Повышать безопасность приложений на базе Axiom JDK Pro позволяет доверенный репозиторий для Java-библиотек. Он собран силами наших разработчиков из исходных кодов 200 библиотек с применением инструментов статического анализа кода SVACE от Института системного программирования РАН и практик безопасной разработки. Общий объем верифицированных исходных текстов составляет порядка 4 Гб.

Сергей Черномашенцев, «Смарт-Софт»

Если говорить о российских ИБ-компаниях, то по данным ФСТЭК, 90% компаний сейчас использует инструменты для DevSecOps. По моему мнению, лишь половина организаций в ИБ подходит к этому ответственно. То есть не просто проводят тесты и закупают ПО для сертификата ФСТЭК, а вводят регламенты, чек-листы, без которых не выходит релиз.

Мы уже почти 20 лет на рынке ИБ, и используем безопасную разработку для всех своих приложений. Будь то просто плагины, которые не поддаются сертификации, или обычные версии ПО. Это наша ответственность перед заказчиками, несмотря на требование регулятора о необходимости проверять только ту версию ПО, которая имеет сертификат ФСТЭК..

Сергей Головашов, Bell Integrator

Так или иначе почти все российские компании используют DevSecOps. У меня не так давно было общение с МТС, которые очень активно расширяются в сторону применения практик безопасной разработки.

В финтехе с самого начала вхождения в Agile прорабатывались вопросы контроля технической безопасности разработки – либо автоматически, либо силами отдельных команд ИТ-безопасности.

Cyber Media: Какие отрасли в России сейчас больше всего интересуются DevSecOps-подходами?

Роман Карпов, «БЕЛЛСОФТ»

Задавая вопрос: «Кому нужен DevSecOps?», мы по сути спрашиваем: «Кому нужна информационная безопасность?». Критичнее всего она в областях, где нарушение безопасности может привести к катастрофическим последствиям для бизнеса или общества в целом.

Это прежде всего критические информационные инфраструктуры (КИИ): весь финтех, энергетика, службы быстрого реагирования, цифровая инфраструктура государственных услуг, и так далее. Риски могут варьироваться от простой кражи денег до невозможности вызвать «скорую» человеку с инфарктом.

ФСТЭК предъявляет особые требования к безопасности систем такого уровня, ФСТЭК надо получать на приложение, на среду его разработки и исполнения. Например, под 4УД (четвертый уровень доверия) попадают следующие:

• государственные информационные системы до 1 класса защищенности включительно;
• значимые объекты критической информационной инфраструктуры 1 категории;
• информационные системы персональных данных до 1 уровня защищенности включительно;
• автоматизированные системы управления производственными и технологическими процессами 1 класса защищенности.

Чтобы упростить построение и аттестацию государственных информационных систем, мы обеспечили сертификацию наших технологий и выпустили сертифицированные продукты - Axiom JDK Certified и Libercat Certified (проходит испытания). Наши инженеры инвестировали десять человеко-лет в их разработку и верификацию 3 Гб программного кода.

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

Антон Прокофьев, «РТК-Солар»

Заинтересованные во внедрении DevSecOps-подходов компании чаще всего стремятся защититься в первую очередь от репутационных рисков, а во вторую – от рисков разглашения персональных данных пользователей и финансовых рисков.

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

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

Сергей Головашов, Bell Integrator

Некоторое время назад была история, когда компания-разработчик эхолокаторов не заплатила разработчику и выяснилось, что сонары на Москва-реке не просматривали гавань несколько часов в сутки. Или другой случай, такой же разработчик ПО для касс остановил на несколько дней всю Россию. Стоит ли говорить, что риски максимальны?

Любой бизнес должен, опережая события, оценивать их по максимальному для себя уровню угрозы. Пока это топ-менеджемент это не понимает, никто уровнем ниже не начнет серьезно заниматься реальной оценкой ее предотвращением угроз. К сожалению, пока гром не грянет, мужик не перекрестится.

Сергей Черномашенцев, «Смарт-Софт»

Даже если в самом скромном банке простой на пару часов в день будет стоить несколько миллионов рублей. Фактически столько же стоит ПО для тестирования исходного кода за целый год.

Cyber Media: Как выглядит дорожная карта внедрения DevSecOps?

Роман Карпов, «БЕЛЛСОФТ»

DevSecOps направлено на глобальное улучшение процессов разработки. Поэтому дорожная карта выглядит соответствующе:

1. Проанализировать всю цепочку от проектирования и до эксплуатации.
2. Найти и исправить очевидные слабые места. Наладить эффективное взаимодействие между основными группами специалистов: разработчики, архитекторы и аналитики, сисадмины, безопасники, и так далее.
3. Автоматизировать все этапы разработки с помощью конкретных технических средств (например, статических анализаторов кода и анализа логов на проде).
4. Определить метрики эффективности и работать над их улучшением.

Детали карты индивидуальны для каждого предприятия. Главное — начать.

Антон Прокофьев, «РТК-Солар»

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

Чтобы быстрее получить первые результаты, лучше начать с процессов – понять, полноценно ли выстроен и описан DevOps-процесс, выбрать инструменты и начать их тестирование на выделенном проекте. После этого – оптимизировать и автоматизировать процессы.

Ответить однозначно, сколько времени занимает переход, невозможно. Сроки зависят от команды, уже выстроенных процессов, стека технологий, языков разработки, инструментов проверки. Были проекты, когда DevSecOps внедрялся за считанные недели, в других проектах процесс может выстраиваться и оттачиваться в течение года.

Сергей Черномашенцев, «Смарт-Софт»

Один из самых правильных и простых способов – использовать регламенты ФСТЭК, которые есть в открытом доступе. Там исчерпывающе написано, что сначала нужно декомпозировать до модулей все ПО, а дальше проверять каждый модуль по отдельности. Где-то нужно статическое и динамическое исследование, где-то – фаззинг-тесты.

Если у вас возникает вопрос: «Надо это тестировать или нет?» – значит, надо.

Алексей Смирнов, CodeScoring

При правильно выстроенных процессах разработки, добавление звена Sec не должно вызывать критичных проблем, а начать можно с защиты от уязвимостей артефактов, попадающих в контур разработки, в частности, применив SCA-firewall. Далее, можно погружаться в анализ всего исходного кода и обеспечения безопасности сборок целиком.

Период раскачки, конечно же, есть, но он разный для разных инструментов, все инструменты на разной глубине погружения в процессы анализа дают требуемые результаты, а самый быстрый бизнес-эффект дает SCA (software composition analysis) для анализа open source.

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

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

Роман Кравцов, NGR Softlab

На практике компании часто сталкиваются с трудностями, которые можно решить несколькими способами:

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

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

Автоматизация является ключевым фактором, позволяющим сбалансировать интеграцию безопасности со скоростью и масштабом.

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

Инструмент для автоматизации должен обладать достаточным количеством интерфейсов для его интеграции с другими подсистемами. Хорошей практикой является возможность для специалистов выполнять сканирование в IDE в своем окружении разработки.

Управление через конфигурационные файлы, а не через интерактивное взаимодействие. Принципы «governance-as-code» и «configuration-as-code» ускоряют разработку и вывод продукта.