Привет, Хабр! На связи Николай Лузгин, DevSecOps Lead и Илья Шаров (@issharov), Head of DevSecOps из МТС Web Services. Те самые безопасники, которые приходят в каске, запускают сканеры и доводят разработчиков до слез (нет).
На самом деле DevSecOps — это не про страдания и бесконечные отчеты сканеров в PDF, а про здравый смысл и взаимодействие. У нас в MWS это полноценный процесс, состоящий не только из инструментов, пайплайнов, требований и Security Gate.
В своей работе мы учитываем особенности продуктовой разработки большого количества команд — от крупных до малых инженерных групп, создающих MVP. Вместе с ними боремся за Time-to-Market и оптимизацию расходов, но при этом делаем ставку на повышение безопасности выпускаемого продукта.
И главное — помогаем находить уязвимости на ранних этапах. Объясняем их суть на понятном языке, проверяем эксплуатируемость, придумываем меры митигации и составляем план по устранению — причем не где-то там в своих кабинетах, а вместе с командой при планировании работы на спринт или квартал.
Звучит неправдоподобно? Из-за образа безопасников-церберов, кот��рый складывался в ИТ-тусовке десятилетиями, работа DevSecOps и правда представляется по-другому. Мы решили разобрать четыре главных мифа, которые встречаются при выстраивании отношений между ИБ и ИТ. Погнали рушить стереотипы!
Миф № 1. Да там же просто сканеры внедрить!
Типичная ситуация с командой продукта:
— Да у нас Bandit, Trivy, Checkov… Все есть!
— А как результаты смотрите?
— А их нужно смотреть?
Конечно, нужно. Для этого у нас в MWS есть Security Pipeline и внутренняя платформа, которая агрегирует и визуализирует данные. Если просто внедрить сканеры в CI/CD, то и результат получится соответствующий. Потому что разработчики редко читают логи задач в Gitlab, а JSON или таблицы в логах — не самый удобный формат. Даже если постараться преобразовать все в читаемый, но все же статичный файл — все равно не получится изменить статусы явных False Positive, которые будут вечно мозолить глаза, а их зачастую бывают сотни. А ведь где-то там в огромном отчете есть то, что действительно требует внимания.
Безопасная разработка — это не только набор инструментов и «культура безопасности». В основе безопасного жизненного цикла разработки ПО (Secure Software Development Life Cycle или SSDLC) — достаточно сложная технологическая архитектура, где безопасность интегрирована с самого начала, еще до кода (Shift Left), а проверки автоматизированы.
Речь не о разовом сканировании, а об управлении уязвимостями как циклического процесса.
Так выглядит эталонная архитектура SSDLC. А также DevOps, которому объяснили схему и «почему четыре сканера в пайплайне, которые выдают нечитаемый json, — это не безопасная разработка»
На каждом этапе SSDLC можно применять множество практик для обеспечения безопасности продукта. Это в том числе автоматические проверки на соответствие законам и стандартам — безопасная разработка регулируется на уровне государства, плюс наслаиваются внутренние требования ИБ.
Разумеется, это идеальная картина, когда архитектура продукта строится с нуля. В реальном мире код и разработка зачастую уже существуют и практики DevSecOps надстраиваются или встраиваются в существующие и зачастую эффективные процессы разработки, фокус которых сильно смещен на скорость выпуска продукции. Главный вызов в этом случае — не внедрить все практики сразу, а выбрать те, что дают максимальный профит и минимально тормозят процесс.
Поэтому безопасностью занимаются специально обученные люди, которые знакомы с инструментарием DevOps и специализированными сканерами, а также разбираются в процессах и адаптируют их под компанию и команды разработки, взаимодействуют с регуляторами и так далее.
Миф № 2. DevSecOps — те же DevOps, только в профиль
Как правило, сотрудников с компетенцией DevSecOps единицы даже в большой компании. MWS не исключение, у нас есть сервисная команда и по одному-два специалиста на выделенные бизнес-вертикали, где в ИТ-кластерах разрабатываются десятки и сотни продуктов. DevOps-специалист при этом есть в каждом продукте.
DevSecOps строят целую архитектуру вокруг безопасного производственного процесса, составляют требования к автоматическим проверкам, поддерживают платформу безопасности со множеством сервисов на уровне всей компании. А DevOps поддерживает практики безопасной разработки на уровне своей продуктовой команды. Это, можно сказать, «руки» безопасности на местах.
Если сравнить матрицы компетенций DevSecOps- и DevOps-инженера, и правда можно найти много общего. Специалисты варятся в области одного производственного цикла, где нужно знать языки программирования, работать с CI/CD, артефактурой, контейнеризацией и так далее.
Из-за этого пересечения в компетенциях логичны и неизбежны, но глубина знаний и специфика работы разительно отличаются. Если говорить образно, DevOps создает среду, в которой разработка становится предсказуемой, масштабируемой и быстрой. А DevSecOps встраивается в эту среду и делает все, чтобы в этой гонке никто не забыл «пристегнуть ремни».
В таблице ниже — компетенции DevSecOps, касающиеся именно Security. Благодаря этим знаниям и навыкам они могут показать команде разработки, где и в чем проблема, расписать рисковую модель и объяснить последствия, предложить варианты решения.
Hard Skills | Process Skills |
Знание инструментария (Scanner Stack): глубокая экспертиза в SAST / SCA / DAST / IAST. Безопасность контейнеризации: работа с Docker, Kubernetes (K8s), сканирование образов и контроль рантайма. Infrastructure as Code (IaC) Scanning: проверка манифестов Terraform, Ansible, Helm (инструменты типа Checkov, TFSec). Secrets Management: внедрение и администрирование HashiCorp Vault, управление ротацией ключей. Security Hardening: настройка ОС, сетей и сред исполнения по стандартам (CIS Benchmarks). Cloud Security (CSPM): контроль настроек облачной инфраструктуры. Supply Chain Security: работа с SBOM, подпись артефактов (Cosign/Sigstore). CI/CD Pipeline Security: защита от инъекций и подмены кода. | SSDLC методологии: понимание жизненного цикла безопасной разработки от идеи до вывода из эксплуатации. Моделирование угроз (Threat Modeling): умение находить дыры в дизайне еще до написания первой строчки кода (STRIDE/PASTA). Принципы и практики DevSecOps: философия Shift Left, культура Shared Responsibility. Security Quality Gates: определение критериев «прохода» (что блокируем, а что пропускаем в прод). Работа с уязвимостями и оценка критичности: умение отличить реальный риск от «мусора» (Triage, CVSS, EPSS). Работа с рисками: понимание, когда риск можно принять, а когда — нужно блокировать разработку. Нормативные требования: перевод «бумажных» законов (ГОСТ, PCI DSS, GDPR) на язык автоматических проверок. Построение процессов: настройка взаимодействия между ИБ, DevOps и разработкой. OWASP Top 10 (API, Mobile, Web): знание актуальных векторов атак для обучения команд и настройки сканеров. |
Такие глубокие знания по безопасности не нужны DevOps-инженеру на постоянной основе. Как и DevSecOps, например, не обязан знать, как настроить определенную ОС под максимальную производительность конкретного процессора.
Еще важный момент: DevSecOps — это не «настройка фильтров», чтобы разработчиков не бесили алерты. Мы отвечаем за честность и качество анализа — сюда входит не только борьба с «шумом» (False Positives), но и полнота покрытия (Transitive Dependencies).
Например, без контроля транзитивных зависимостей безопасность превращается в иллюзию. У вас может быть 30 прямых зависимостей в NPM, но с учетом «дочек» и «внучек» их становится 3600. Задача DevSecOps здесь — подсвечивать команде реальный масштаб проблем, но при этом помогать приоритезировать их.
Сканер «из коробки» — это всего лишь база. Настоящий DevSecOps постоянно дорабатывает сценарии анализа. Это не только убирает ложные срабатывания, но и позволяет найти то, что раньше сканер пропускал из-за несовершенства технологии или дефолтных настроек. Если понимаем, что стандартный сканер не видит специфический для нашего кода паттерн уязвимости, — пишем свое правило.
Миф № 3. DevSecOps замедляет разработку и релизы
На самом деле DevSecOps ускоряет Time-to-Market и повышает ROI. Чем раньше мы понимаем, что библиотека устарела, уязвима или идет с запрещенной для компании лицензией и ее нужно сносить под корень, тем больше времени специалистов и ресурсов можем сэкономить.
Если разработчик узнает об уязвимой библиотеке через месяц после деплоя, а не в первом коммите, цена исправлений вырастет в разы. Придется переписывать код, заново проходить регресс-тесты и, возможно, менять архитектуру. В этом главная ценность философии Shift Left.
Зачастую именно DevSecOps помогают бизнесу правильно инвестировать: вкладываться не в «латание дыр» в старом легаси, а в модернизацию стека. Чем эффективнее платформа, тем в итоге выше ROI.
По части комплаенса автоматизация аудита — это экономия времени юристов, снижение рисков огромных штрафов. В идеале все проверки зашиты в Quality Gates, и релиз улетает в прод без недельных согласований от безопасников.
При этом в идеале — проводить пентесты после джентльменских проверок в CI/CD и устранения критических уязвимостей. На опыте мы неоднократно сталкивались с эксплуатацией ошибок, где корни причин уходили либо в код, либо в используемые зависимости. Разумеется, это усложняет работу команде тестировщиков на проникновение, но в то же время позволяет сфокусироваться и найти более серьезные дефекты и не распылять ресурсы — как команде разработки, так и DevSecOps.
Все это, разумеется, требует настройки и умного распределения ресурсов. Если 400–500 коммитов валятся в мастер-ветку, а вы сканируете не только ее, один бедный GitLab-раннер это не вывезет. Ладно, вывезти-то он вывезет — вопрос в том, через сколько дней прилетят результаты и будет ли их кто-то смотреть?
Если настроить сканирован��е так, чтобы все не летело в общую кучу на один сервер, простоев будет меньше. Релиз не должен ждать, пока сканируется чья-то фича «покраски кнопки». Именно поэтому важно не просто внедрить все, что есть под рукой в CI/CD, а продумать архитектуру. Что сканируем, как часто, почему, зачем, для чего и где? На все эти вопросы у DevSecOps должен быть готов ответ еще до появления первого сканера в чьем-то пайплайне.
Обычно принято считать, что безопасники только тратят ресурсы. Даже пресловутый Shift Left — это «экономия на будущих исправлениях», которую бизнес редко ощущает здесь и сейчас. Это как со страховкой: платишь сегодня, чтобы не разориться завтра, но радости от этого мало.
И все же мы в MWS видим другой эффект. Когда безопасность начинает заниматься цифровой гигиеной, оптимизация ради ИБ дает прямой экономический профит, понятный и DevOps, и бизнесу.
А теперь к цифрам.
Что все это значит:
–70% веса образа — это не просто «красивая цифра». Это реальное снижение затрат на хранение (Storage) и объема трафика. В масштабах облака и сотен сервисов это прямая экономия в счете за инфраструктуру.
Ускорение деплоя — за счет того, что образы «похудели», а сборки Go стали в четыре раза быстрее, сокращается Time-to-Market. Фича долетает до продакшена быстрее не потому, что мы «забили» на проверки, а потому, что мы вычистили из процессов лишний балласт.
Помимо этого, мы наблюдаем и измеряем сокращение технического долга по безопасности и снижение плотности риска в разрабатываемых продуктах.
ИБ — это всегда про порядок. А там, где появляется порядок, неизбежно наступает стандартизация. Именно она в итоге дала тот самый буст, от которого выиграли все:
Бизнес получил «омоложение» приложения: оно стало быстрее, легче в поддержке и стабильнее, а значит, надежнее.
Разработка получила современный стек и чистые пайплайны без «мертвого кода».
Безопасность — чистое приложение, собираемое по уже проверенным на уязвимости и миссконфиги-шаблонам, где все уязвимости можно закрыть за пару дней.
Вывод тут простой:
Безопасность, внедренная по уму, а не ради галочки в отчете у регулятора, дает реальную пользу бизнесу. DevSecOps не «доедает» ресурсы команды, а помогает ей выбраться из болота техдолга. Когда мы убираем лишнее и стандартизируем процессы ради ИБ — автоматически делаем разработку быстрее, а продукт — качественнее.
Миф № 4. После сканирования приложение закроют
А в сканировании ли дело? Чтобы разобраться, рассмотрим два случая из нашей практики. А вы пока делайте ставки — выстрелит или не выстрелит технический долг по безопасности.
Кейс с Java
Дано: старая Java (8-я или 9-я) и старый Spring. При сканировании мы нашли огромное количество уязвимостей и предложили команде обновиться. Идея, конечно, хорошая, но для команды это значит переписать половину кода, заменить половину функций и еще тестированием все это шлифовать. Команда сказала: «Спасибо за ваше офигительное предложен��е, нам это не нужно».
Тогда мы пошли по другому пути — и начали все эти уязвимости обрабатывать. (Кстати, устранение уязвимостей ≠ обновление версии, это еще один пятый бонусный миф.)
Выяснилось, что из десяти уязвимостей два неприменимы к продукту, пять можно закрыть средствами защиты информации, а остальные не закрываются вообще ничем. Чтобы полностью их митигировать, нужен сервис-прокладка, который будет фильтровать пользовательский ввод, подготавливать данные и отправлять в сервис. Команде это тоже не понравилось.
В итоге они подумали: «А что реально будет, если мы Java обновим?» Исправление багов, повышение совместимости с текущим стеком — хорошие возможности для развития. Еще и бизнес хотел фичи докинуть. Затраты на накручивание всяких приблуд по безопасности были соизмеримы с обновлением.
Так и решили обновляться.
На все про все ушел месяц. Собрали, выкатили, начали тестировать — получили плавающие баги.
Проблема была не в самих обновлениях, а в том, что код приложения был настолько хрупким, что любая попытка привести его к современным стандартам вызывала каскад ошибок. В итоге обновленную версию убрали из продакшена через несколько недель — уж слишком много было ошибок и слишком непонятны их причины. А через некоторое время старое приложение не выдержало реальной нагрузки и умерло.
В бизнесе так бывает: когда мы посчитали, сколько стоит бесконечный ремонт этого зомби-сервиса, стало понятно — проще написать новый. Там, где безопасность вшита в фундамент с первого дня, а производительность предсказуема.
Эта история стала уроком для всех:
— Если бы команда актуализировала версии постепенно, шаг за шагом, объем проблем остался бы управляемым.
— Если бы безопасность начала «третировать» команду уязвимостями вовремя, склоняя к обновлению на одну-две минорные версии, переход не стал бы смертельным.
Вместо этого получился резкий прыжок — попытка сменить каменный топор сразу на ядерную боеголовку. Хрупкий код такой нагрузки просто не выдержал.
Но есть и другой кейс, когда DevSecOps стал гирькой, которая перевесила все «но» от бизнеса.
Кейс с .NET
В одной команде ребята мечтали о новом .NET — видели, что там новые фишки, устранение багов, упрощение разработки. Задача уже давно была в техбэклоге, но руководители бизнеса профита для себя в этом не видели.
При сканировании приложения мы нашли кучу уязвимостей, рассказали о предыдущем кейсе из-за старого стека. Менеджмент прикинул риски и затраты, дал добро на обновление.
В итоге бизнес получил чистое приложение без уязвимости, а команда — желаемый новый .NET. Ребята продолжают его обновлять и радуются. Ведь когда постепенно обновляешься, а не волнами, времени уходит не так много. В конечном счете выиграли три стороны: бизнес, ИБ и команда. А сканирование, которое все так не любят, сыграло положительную роль.
В общем, причина не в самом сканировании, а в техдолге по безопасности, который порой копится годами. А сканирование как раз подсвечивает его масштаб и точку невозврата.
Вот, кажется, и все. Надеемся, что главные мифы про DevSecOps мы развеяли. Если с чем-то не согласны или хотите добавить — добро пожаловать в комментарии. Обсудим!
