Содержимое для авторизованных пользователей

Евгений Балк, «Кросс технолоджис»: «Безопасная разработка станет стандартом во всех компаниях, хотят они этого или нет»

Перед руководителями ИТ и ИБ в российской промышленности встает новая реальность: атаки с использованием ИИ, растущие риски в цепочках поставок и изменение регуляторных требований делают безопасную разработку критически необходимой. Как компаниям подготовиться к вызовам ближайших лет, какие метрики убедят бизнес в необходимости DevSecOps, и почему роль CISO должна трансформироваться из «пожарного» в «архитектора безопасности», рассказал Евгений Балк, руководитель департамента развития и архитектуры компании «Кросс технолоджис».

— Вы часто говорите, что безопасная разработка скоро станет безусловным стандартом для всех компаний. Почему вы в этом так уверены, и какие основные драйверы этого процесса видите?

— Уверенность основана на двух факторах: значительном росте киберугроз, связанных с эксплуатацией известных уязвимостей, и атаками на цепочку поставок, а также ужесточении регуляторных требований. Так, в частности, по результатам 2024 года только атаки, связанные с уязвимостью веб-приложений, доступных из Интернета, составили ориентировочно 20% от общего количества кибератак. Кроме того, нужно понимать, что значительное количество таких атак из-за репутационных рисков остается неизвестными широкой общественности. Бизнес больше не может игнорировать риски финансовых потерь в результате кибератак (например, выкупы за расшифровку данных достигают 5–10 млн руб. для средних компаний) и репутационного ущерба. Вопросы безопасной разработки программного обеспечения находятся под пристальным вниманием регуляторов: так, в начале года Банк России существенно переработал набор требований для банков и других финансовых организаций в составе положений Банка России от 13.01.2025 № 850-П и от 30.01.2025 № 851-П, и совсем недавно был утверждён приказ ФСТЭК от 11 апреля 2025 г. № 117, где были внесены существенные изменения в вопросы безопасной разработки программного обеспечения для ГИС (государственных информационных систем).

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

— Мы фокусируемся на интеграции новых решений через три ключевых принципа: автоматизацию процессов, обучение и адаптацию под технологический стек клиента. Например, внедряем инструменты статического и динамического анализа кода непосредственно в конвейере CI/CD с учетом эффективности того или иного решения для используемых у заказчика фреймворков, релизных циклов и процесса в целом. Наша экспертиза заключается в глубоком понимании импортозамещения: мы помогаем компаниям перейти от legacy-решений к наиболее подходящим российским платформам без снижения функционала безопасности, учитывая специфику отраслей — от телекома и промышленности до финансов.

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

— Реальная ценность DevSecOps — в устранении конфликта между скоростью выхода новых релизов продуктов и их безопасностью. Например, автоматизация проверок в пайплайне сокращает время на рефакторинг кода из-за уязвимостей с недель до часов. Это не теория: наши заказчики отмечают снижение количества критических инцидентов на 40% при сохранении темпов релизов. Ключ здесь — в shift-left подходе: переносе security на этапы проектирования и разработки, а не в продуктивную среду.

Контейнеризация приложений стала повсеместной, но принесла новые риски. Насколько критична безопасность контейнеров в современном DevSecOps-конвейере?

— Это, действительно, критично. 60% образов в публичных реестрах содержат уязвимости. За последние годы эта проблема также стала предметом пристального внимания регуляторов. Необходимо отметить, что традиционные средства защиты, такие как антивирусы, сканеры безопасности и т.д., не адаптированы под их динамическую природу. Поэтому DevSecOps-конвейер обязан включать специализированные инструменты для защиты контейнеров, которые сканируют образы на этапе сборки, выявляя уязвимости, вредоносное ПО и секреты в конфигурациях до их развертывания.

Расскажите о решениях для контейнерной защиты. Какие их основные возможности и преимущества вы считаете наиболее важными для интеграции в процесс безопасной разработки?

— Специализированные решения для защиты контейнеров уникальны по трём аспект. Во-первых, они обеспечивают сквозную защиту жизненного цикла: от сканирования артефактов в репозиториях (например, Docker Hub) до мониторинга runtime-активности в Kubernetes. Во-вторых, автоматизируют соответствие требованиям (NIST, ISO) с помощью встроенных политики, что критично для госсектора и финтеха. В-третьих, их компоненты для агентов детектируют аномалии в работающих контейнерах, например, незаконный майнинг криптовалюты на серверах компании или подозрительные сетевые соединения. Это существенно снижает нагрузку на команду SOC в компании.

Интеграция инструментов безопасности в CI/CD-пайплайны часто вызывает сложности. Как такие продукты решают проблему автоматизации проверок безопасности контейнеров на ранних этапах без замедления релизов?

— Специализированные решения для защиты контейнеров встраиваются в CI/CD через плагины для Jenkins, GitLab или Kubernetes Operators. Их сканеры работают как контрольные точки качества: автоматически проверяют каждый новый образ в реестре на соответствие политикам безопасности. Если обнаруживаются критические уязвимости, сборка останавливается. Это не замедляет процесс разработки потому, что сканирование происходит параллельно с тестами, а результаты интегрируются в SIEM для коррекции без остановки пайплайна. Для ускорения реагирования эти решения используют актуальные базы уязвимостей.

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

— Без изменений в культуре и процессах даже лучшие инструменты бесполезны. Считаю, что каждой компании необходимо, в первую очередь, создать кросс-функциональные команды, где Dev, Sec и Ops разделяют общий KPI, и внедрить threat modeling на этапе дизайна приложений. Также не будет лишним проводить регулярные тренировки по реагированию на инциденты с участием подразделений ИБ, таких как SOC и других. Мы помогаем нашим заказчикам реструктурировать workflows, обучаем их команды (например, через воркшопы по Kubernetes security) и разрабатываем Security-as-Code стратегии, где политики IaC описаны в Git.

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

— Парадокс в том, что включение элементов безопасности ускоряет разработку, а не замедляет её. Если взять в качестве примера решения для защиты контейнеров, то они сокращают ручные проверки образов с часов до минут. Их способность блокировать запуск несоответствующих политикам контейнеров в оркестраторе предотвращает «сломанные» релизы. Добавим сюда runtime-мониторинг без перенастройки инфраструктуры — и получим не барьер, а катализатор скорости. Важно начинать с малого: внедрить сканирование только для критичных приложений, получить конкретный результат, а затем масштабировать. Кроме того, по различным оценкам, трудоёмкость устранения ошибок и уязвимостей в продукте как минимум удваивается на каждой стадии при переходе из среды разработки в продуктивную среду.

Глядя на ближайшие 2–3 года, какие новые вызовы в области безопасной разработки и эксплуатации ПО вы считаете наиболее значимыми, и как компаниям следует готовиться к ним уже сейчас?

— Главные вызовы связаны прежде всего с применением ИИ: для поиска и выбора векторов атаки на основе данных OSINT, баз эксплойтов и других данных, а также ускоренной разработки кода и конфигураций (например, тех же манифестов), что приводит к рискам появления новых уязвимостей. Таким образом, критичность своевременного закрытия уязвимостей возрастёт многократно. С точки зрения объектов угроз мы ожидаем рост атак на цепочки поставок ПО (вспомним кейс SolarWinds), поэтому компаниям, оказывающим соответствующие услуги, и их заказчикам необходимо максимально серьёзно относиться к этой тенденции.

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

— Начните с цифр. Без метрик (например, % сборок с критическими уязвимостями или time-to-fix) вы не сможете доказать эффективность бизнесу и акционерам. Проведите аудит безопасности критичных приложений, оцените, существует ли для них POC (proof of concept?), оцените, сколько времени найденные уязвимости уже существуют у вас в продуктивной среде и в какие сроки они могут быть исправлены, обсудите эти результаты с максимально широким кругом заинтересованных лиц. Внедряйте практики безопасной разработки поэтапно: сначала определите текущее и целевое состояние процесса, определите промежуточные состояния для достижения указанной цели с учетом критичности сервисов, определите объем проверок для каждой стадии в части сканирования кода, библиотек и зависимостей, базовых образов контейнеров. Обеспечьте интеграцию с системами мониторинга. Интегрируйте оркестраторы, которые дают единую картину с детализированными отчетами. И главное: 99% CISO в России сегодня переосмыслили свою роль из-за новых технологий. Ваша задача — быть не «пожарным», а архитектором безопасности, который говорит на языке бизнеса.

Прокрутка наверх