Безопасность приложений и DevSecOps:
что в приоритете?

Безопасность — важная составляющая в разработке. Этот опрос был проведен для того, чтобы понять, как команды встраивают защиту в каждый шаг CI/CD, какие инструменты реально работают и что мешает масштабировать практики на уровне организации.

1. Есть ли у вас встроенные автоматические проверки безопасности в CI/CD?
2. Какие типы сканирования вы используете в пайплайне?
3. Как быстро вы реагируете на критические уязвимости в зависимостях?
4. Кто отвечает за приоритизацию исправлений уязвимостей?
5. Есть ли препятствия, которые мешают внедрять DevSecOps-практики? Если да, то какие?

В опросе принимают участие эксперты российских компаний

Максим Лапшев,
ИТ-директор РДТЕХ

«Трудности сопровождают любой процесс внедрения и развития. Моя команда работает над устранением барьеров. Часть ее сотрудников до сих пор считает, что безопасность приложений к ним не относится. Я борюсь с этим через KPI, обучение и прозрачную отчетность по результатам деятельности»

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

2. Мы не используем изощрённые методы проверки. Традиционно сканируем зависимости и компоненты приложений. Используем решения SCA (Software Composition Analysis), которые анализируют кодовую базу приложения на наличие дефектов. Получаем результаты сканирования и работаем над исправлениями — обновляем устаревшие элементы, минимизируем риски.

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

3. У нас есть формализованный SLA для устранений уязвимостей. Сроки обработки обращений разнятся в зависимости от степени инцидента. Критические уязвимости стараемся исправить за 72 часа или, как вариант, накатываем новый патч. Все метрики отслеживаем — это и время до обнаружения уязвимостей, до их исправления, и процент ложноположительных срабатываний.

4. Мы стараемся держать ответ сообща. Придерживаюсь принципа, что команда разработки несет ответственность за продукт с момента его создания до вывода из эксплуатации. Тем не менее формально в нашей практике роль Security и Product Owner закреплена за одним сотрудником, поэтому за ним окончательное решение о приоритизации какой-либо уязвимости в бэклоге против бизнес -задач.

5. Трудности сопровождают любой процесс внедрения и развития. Моя команда работает над устранением барьеров. Часть ее сотрудников до сих пор считает, что безопасность приложений к ним не относится, и является проблемой какого-то другого отдела. Я борюсь с этим через KPI, обучение и прозрачную отчетность по результатам деятельности.

Также есть препятствия в виде Legacy-систем, которые устарели, но используются в работе. Чтобы вывести старый софт из эксплуатации, нужно смело планировать бюджеты на модернизацию таких систем.

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

«Реагируем на критические уязвимости, как и везде — заводится тикет, и пока уязвимость не будет устранена, ПО не допускается на следующий стенд для дальнейшей работы»

1. После введения в нашей стране ГОСТов по безопасной разработке у нас остаются актуальными только решения от ИСП РАН и PTAI. Только данные решения сертифицированы и могут выполнять свою роль, как инструменты обеспечения безопасной разработки.

2. Мы используем следующие методики проверки:

• SAST (Static Application Security Testing) — Статическое сканирование кода, которое проверяет исходный код, конфигурационные файлы, скрипты, чтобы выявить уязвимости до выполнения кода (например, SQL-инъекции, XSS, небезопасная сериализация) на этапе разработки и в CI (Continuous Integration).
• DAST (Dynamic Application Security Testing) — Динамическое сканирование приложения в работающем состоянии (runtime) с целью поиска уязвимостей, которые проявляются только при исполнении (например, ошибки аутентификации, CSRF, уязвимости в API).
• SCA (Software Composition Analysis) — Анализ зависимостей сторонних библиотеки и пакетов, чтобы выявлять известные уязвимости в зависимостях, устаревшие или небезопасные версии библиотек.
• IAST (Interactive Application Security Testing), который сочетает подходы SAST и DAST внутри приложения во время тестирования для более точного обнаружения уязвимостей с контекстом исполнения кода.
• Container & Infrastructure Scanning, который проверяет контейнеры, образы, инфраструктуру как код (IaC), конфигурации облака, чтобы найти уязвимости в образах Docker, misconfigurations, открытые порты, RBAC-проблемы.
• Secrets & Credential Scanning с проверками на наличие секретов, токенов, ключей в коде и конфигурациях.
• Security Unit & Integration Testing для проверки бизнес-логики, авторизации и аутентификации на уровне тестов, чтобы убедиться, что безопасные практики встроены в код, а не только в сторонние инструменты.

3. Реагируем на критические уязвимости, как и везде — заводится тикет, и пока уязвимость не будет устранена, ПО не допускается на следующий стенд для дальнейшей работы. Подходы к SDLC мы применяем уже давно, и они у нас в компании стандартные.

4. За приоритизацию отвечает как тимлид проекта, так и DevSecOps-инженер. Проверку же ведет DevSecOps и QA-лид. Можно сказать, что мы используем следующий подход к исправлению и проверке:

• Обнаружение уязвимости Приоритезация (Team Lead + DevSecOps) Исправление Проверка/Верификация (DevSecOps + QA-лид) Деплой.

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

Владимир Арышев,
эксперт по комплексным проектам информационной безопасности STEP LOGIC

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

В своей практике при внедрении DevSecOps мы часто встречаемся с различными препятствиями. Главная сложность в том, что DevSecOps — это не просто внедрение новых инструментов, а фундаментальное изменение подхода к разработке и культуре работы команд.

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

Дополнительную сложность создает культурное сопротивление внутри компаний. DevSecOps требует, чтобы безопасность стала общей задачей — от разработчика до менеджера проекта. Но на практике нередко можно услышать: «Это не моя зона ответственности». Пока осознание совместной ответственности за безопасность не станет частью корпоративной культуры, внедрение DevSecOps будет идти медленно.

Также свою роль играет и дефицит компетенций. Специалистов, которые одновременно разбираются в коде, инфраструктуре и принципах кибербезопасности, крайне мало, а их стоимость высока. Без таких кадров трудно выстроить полноценные процессы, автоматизировать проверки и корректно интегрировать инструменты безопасности в CI/CD, поэтому здесь может потребоваться помощь организаций, специализирующихся на внедрении практик DevSecOps.

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

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

Павел Пилькевич,
инженер-разработчик отдела систем анализа машинных данных STEP LOGIC

«Проблемы возникают из-за слабой коммуникации между отделами и недостаточно чёткого распределения ответственности. Если в вашей инфраструктуре не будет „чёрных дыр“, то и наладить её работу по методике DevSecOps не будет критически сложно»

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

Главная рекомендация — распространять проверки безопасности на весь цикл разработки ПО, без исключения этапов. Это и статический анализ утечки секретов на pre-commit, анализ уязвимых зависимостей на pre-build, и внедрение тестирования безопасности перед деплоем. Отдельное внимание советую уделить стадии деплоя, так как на данный момент могут возникать нетривиальные уязвимости Docker-образов, что открывает дыру в безопасности всего сервиса.

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

Ограниченные навыки, отсутствие опыта, непонимание возможных угроз также делают невозможным налаживание безопасного цикла разработки. Большие трудозатраты и проблемы с наследованием legacy-инфраструктуры может усложнить обоснование необходимости перехода на безопасные пайплайны.

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

Максим Захаренко,
СЕО «Облакотека»

«У нас в конвейере CI/CD проверки встроены на каждом шаге и по умолчанию блокируют релиз: статический анализ кода, поиск секретов, SCA для зависимостей, анализ инфраструктуры как кода, сканирование контейнерных образов еще до сборки и перед выкладкой»

Как генеральный директор облачного провайдера, я вижу безопасность не как надстройку, а как часть производства. Если код едет в прод без автоматических проверок — это не DevOps. Это лотерея.

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

Типы сканов выбираем по принципу «раньше и ближе к разработчику». Линтеры и SAST запускаются на PR, секрет-скан — при каждом коммите, SCA — при сборке и по расписанию, IaC-политики — до применения Terraform.

Контейнеры проверяем на базе-имидже и финальном слое, чтобы не ловить «ложняк» по уже закрытым уязвимостям. DAST идёт параллельно регрессу, а поверх — лёгкий fuzz на чувствительных эндпоинтах. Важно, что выводы сканов видны в MR рядом с кодом, а не в отдельном «чёрном ящике» безопасности.

На критические уязвимости в зависимостях реагируем как на инцидент: автоматическое оповещение, горячая ветка, фриз фич, патч-релиз в тот же день с канареечным раскатом. Для «high» даём до трёх дней, всё что ниже — в обычный спринт. Это работает только при четких SLO и договорённости, что безопасность — не просьба, а производственный критерий качества.

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

Что мешает масштабировать DevSecOps? Нас чаще всего бьют три вещи.

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

Во-вторых, зоопарк инструментов и ложные срабатывания — разработчики быстро перестают верить алертам.

В-третьих, культура, когда KPI команд — это только скорость доставки, безопасность всегда «после релиза». Мы лечим это унификацией стека (меньше, но лучше), политиками как кодом, автосогласованием типовых исключений, общими метриками «время до фикса» и «уязвимости на тысячу строк», и, главное, обучением разработчиков как первому рубежу обороны.

Николай Алёшин,
инженер-программист

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

1. У нас настроены линтеры и автоматические тесты на каждый PR. Линтер для Go, например, проверяет и потенциальные секреты в коде, что очень помогает избегать утечек. Плюс есть базовые статические анализаторы и проверки форматирования. Специализированные security-инструменты пока внедряем постепенно, но основа уже работает стабильно.

2. У нас несколько уровней проверки. Используем golangci-lint с security-правилами, который отлично ловит небезопасные паттерны и секреты в коде. Запускаем unit и integration тесты для проверки логики, отслеживаем code coverage. Также настроены автоматические уведомления от GitHub/GitLab о проблемных зависимостях и pre-commit hooks для базовой валидации.

Планируем добавить более глубокий SAST, регулярный SCA и сканирование Docker-образов.

3. На критические CVE реагируем довольно быстро. Обычно в течение 2-3 дней. Получаем сигнал (alerts), обсуждаем в команде, оцениваем потенциальный ущерб (impact) и приоритизируем.

Если уязвимость действительно критична и касается нашего кода напрямую, можем залить hotfix в течение суток. Для менее критичных — включаем в ближайший спринт. Процесс работает, но есть куда расти в плане проактивного мониторинга.

4. Приоритизация исправлений уязвимостей — это зона ответственности команды разработки совместно с Tech Lead. Когда приходит alert, обсуждаем на дейли или в Slack: анализируем серьезность, impact на наш продукт, наличие эксплойтов. Tech Lead или Senior-разработчик принимает финальное решение по приоритету.

Если требуется значительное время на исправление, подключаем Product Owner для согласования. Это работает эффективно, так как решения принимаются быстро, без бюрократии.

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

Мы сталкивались с ложными срабатываниями при тестировании некоторых SAST-инструментов. Но это вопрос правильной настройки.

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

В целом видим прогресс. Год назад было меньше автоматизации, сейчас многое уже работает из коробки. Двигаемся в правильном направлении, постепенно усиливая security-практики без ущерба для delivery.

Анатолий Полтавский,
генеральный директор компании МАДРИГАЛ

«С технологической точки зрения, трудности вызывает интеграция с унаследованными (legacy) системами. Старый код зачастую использует устаревшие библиотеки и сомнительные подходы»

Безопасность встроена в саму философию нашей разработки и охватывает процессы шире, чем CI/CD. Любое изменение кода, инфраструктуры или конфигурации автоматически проходит проверки. Они являются неотъемлемой частью нашего корпоративного стандарта качества.

Мы работаем по принципу Secure Software Development Lifecycle. Ни одна сборка не дойдет до клиента, пока не пройдет полный контроль уязвимостей, зависимостей и соответствия внутренним политикам.

Мы используем в пайплайне комплексный набор сканирований:

• SAST (SonarQube): Статический анализ исходного кода.
• Secret Detection (gitleaks): Поиск секретов в коде.
• IaC-сканирование (tflint, hadolint): Проверка конфигураций Terraform и
• SCA (Проверка зависимостей): Аудит сторонних компонентов для каждого языка (например, govulncheck, pip-audit).
• Container Scanning (grype): Сканирование Docker-образов на уязвимости.
• DAST (NUCLEI): Динамический анализ уже развернутого на стенде приложения.
• Pentest/Assessment: регулярные ручные проверки перед мажорными релизами.

На критические уязвимости мы реагируем немедленно на этапе сборки: критическая уязвимость в зависимостях автоматически блокирует релиз до её устранения.

За приоритизацию исправлений уязвимостей отвечает Product Owner.

Классифицируем уязвимости по шкале CVSS. Критические (Critical) и высокие (High) уязвимости немедленно блокируют релиз и исправляются в первую очередь. Задачи со средним (Medium) приоритетом включаются в ближайший спринт, а с низким (Low) — обрабатываются в плановом порядке.

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

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

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

Александр Дёмин,
руководитель отдела администрирования и DevOPS MD Audit (ГК Softline)

«Постепенный переход к DevSecOps снижает риски и формирует культуру ответственности за безопасный код у всех участников разработки»

Автоматические проверки безопасности — это обязательная часть конвейера CI/CD. Они позволяют выявлять уязвимости на раннем этапе, до попадания кода в продакшн. Это статический (SAST) и динамический (DAST) анализ, проверка зависимостей, анализ конфигураций контейнеров и инфраструктуры. Такой подход снижает нагрузку на команды ИБ и разработчиков, позволяя интегрировать безопасность в процесс естественным образом. Главное здесь — не замедлять релизы, сохранив контроль за качеством кода.

Из типов сканирования, которые мы используем в пайплайне, наиболее эффективна комбинация SAST, DAST, SCA (анализ открытых зависимостей) и контейнерного сканирования. SAST используется на ранних этапах, DAST — ближе к интеграции, а SCA позволяет отслеживать уязвимости в сторонних библиотеках, что особенно важно при активном использовании Open Source.

Приоритизация уязвимостей — совместная зона ответственности разработчиков, инженеров по безопасности и владельцев продуктов. Решения принимаются на основе бизнес-критичности систем, вероятности эксплуатации и метрик CVSS. Для крупных проектов используется централизованный Security Dashboard, где все уязвимости агрегируются и ранжируются по риску. Такой подход обеспечивает баланс между скоростью релиза и уровнем защищенности.

Основные барьеры для внедрения DevSecOps-практики —это дефицит специалистов, низкий уровень зрелости DevOps-культуры и страх потери скорости релизов. Часто безопасность воспринимается как тормоз для разработки, а не часть жизненного цикла продукта. Решение — автоматизация, обучение команд и внедрение метрик, где безопасность становится измеримым KPI. Постепенный переход к DevSecOps снижает риски и формирует культуру ответственности за безопасный код у всех участников разработки.

Денис Тюменцев,
ведущий DevOps инженер в Integro Technologies, Москва

«Основные сложности заключаются в недостатке экспертизы в безопасности: часть разработчиков не полностью понимает, как правильно устранять уязвимости»

1. Пока автоматических проверок безопасности в CI/CD у нас нет. Безопасность контролируется вручную на этапах ревью и тестирования. Но планируем внедрить хотя бы базовое сканирование зависимостей (SCA) в CI/CD.

2. Уязвимости отслеживаем вручную — обычно при обновлении зависимостей или когда приходит информация о критичных CVE. Критические уязвимости стараемся устранять в течении одного-двух дней после их обнаружения.

3. В нашей команде процесс приоритизации исправлений уязвимостей пока не формализован. Разработчики отвечают за исправление, DevOps при необходимости сопровождают, TeamLead разработчиков может приоритизировать задачи.

4. Основные сложности заключаются в недостатке экспертизы в безопасности: часть разработчиков не полностью понимает, как правильно устранять уязвимости.

Аблайхан Аяпов,
директор imperyiacvetov.ru

«Сегодня безопасность приложений — это уже не отдельный этап после релиза, а часть всей цепочки разработки. Мы в imperyiacvetov.ru прошли этот путь сами: от „проверим потом“ к модели, где DevSecOps встроен на каждом шаге. Это не просто тренд, а вопрос выживания — особенно для компаний, которые работают с клиентскими данными и онлайн-платежами»

У нас автоматические проверки безопасности встроены прямо в CI/CD. Каждый коммит и билд проходят через статический анализ кода (SAST), сканирование зависимостей на уязвимости (SCA) и тесты контейнеров перед деплоем. Это позволяет поймать большинство проблем ещё до выхода кода в прод. Для динамического анализа (DAST) мы используем внешние сервисы, чтобы тестировать уже готовое приложение под «боевыми» нагрузками.

Реагируем на критические уязвимости максимально быстро — в течение суток. Это стало возможным только после того, как мы разделили ответственность: разработчики не просто пишут код, а отвечают за его безопасность. Приоритизацию исправлений ведёт технический директор совместно с DevOps-командой. Есть правило — если критическая уязвимость угрожает пользовательским данным или финансовым операциям, работа над фичами останавливается до полного закрытия риска.

Главное препятствие для масштабирования DevSecOps-практик — не технологии, а люди. Нередко безопасность воспринимают как «тормоз» для релизов. Поэтому важно внедрять её постепенно и объяснять, что защищённое приложение — это не замедление, а гарантия устойчивого роста. Мы в imperyiacvetov.ru прошли через этапы скепсиса, но теперь видим результат: скорость релизов не упала, а риски утечек и ошибок сократились на треть.

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

Андрей Кисин,
руководитель команды DevOps ИТ-компании CUSTIS

«Мы не видим препятствий для внедрения DevSecOps-практик. Главная задача DevSecOps-инженеров донести ценность проверок до остальных сотрудников. Сделать проверки и процессы вокруг них прозрачными и управляемыми. Для этого мы проводим внутренние митапы»

1. Mы используем проверки кода на безопасность параллельно с тестированием кода. Процесс проверки идет в отдельных downstream-пайплайнах gitlab, чтобы избежать замедления процессов тестирования бизнес-логики.

2. В пайплайнах мы запускаем banword проверки, которые позволяют найти запрещенные слова и выражения. Ищем уязвимые библиотеки с помощью OWASP dependency-check, который пытается обнаружить публично раскрытые уязвимости, содержащиеся в зависимостях проекта.

Он делает это, определяя, существует ли идентификатор перечисления общей платформы (CPE) для данной зависимости. Если идентификатор будет найден, утилита сгенерирует отчет, ссылающийся на соответствующие записи CVE.

Также мы используем retire.js, который обнаруживает версии библиотек JavaScript с известными уязвимостями. Результаты передаются в SonarQube, где с ними работают DevSecOps-инженеры и разработчики.

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

3-4. Команды разработки оперативно реагируют на найденные уязвимости. Приоритеты зависят от загрузки команды и определяются руководителями подразделений. Как правило критические уязвимости устраняются в течении текущего или следующего спринта, т.е. от 2 до 4 недель.

5. Мы не видим препятствий для внедрения DevSecOps-практик. Главная задача DevSecOps-инженеров донести ценность проверок до остальных сотрудников. Сделать проверки и процессы вокруг них прозрачными и управляемыми. Для этого мы проводим внутренние митапы, где рассказываем, как работать с инструментами DevSecOps и собираем обратную связь от подразделений.

Александр Кучин,
руководитель направления DevOps, Рексофт

«У нас согласованы и выставлены Quality Gates, которые не позволяют объединить новый код с основной веткой разработки, пока не исправлены все уязвимости»

1. Безопасность — неотъемлемая часть процесса разработки ПО в Рексофт. Мы внедрили автоматические проверки безопасности не только в конвейере CI/CD, но и в средах разработки (IDE). Это позволяет обнаруживать и устранять уязвимости на самой ранней стадии.

2. Мы применяем статический анализ (SAST) для поиска уязвимостей в исходном коде, динамический анализ (DAST) для тестирования работающего приложения, а также сканируем сторонние библиотеки на уязвимости и проверяем код на случайно оставленные секреты, такие как API-ключи. Такой подход позволяет нам комплексно закрывать основные векторы угроз на ранних этапах разработки.

3. Ответственность за исправление уязвимостей и багов лежит на всей команде разработки, но процесс строго регламентирован. У нас согласованы и выставлены Quality Gates, которые не позволяют объединить новый код с основной веткой разработки, пока не исправлены все уязвимости. Таким образом безопасность является наивысшим приоритетом и обязательным условием для продвижения кода дальше по циклу разработки.

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

Ключевые слова: DevSecOps-практики, конвейер CI/CD, в среда разработки (IDE), пайплайны, критическая уязвимость.

Подпишитесь на журнал

Комментарии могут оставлять только зарегистрированные пользователи