Практика DevSecOps: анализ исходного кода

Сегодня код создаётся быстрее, чем когда-либо: команды активно используют open source, подключают внешних разработчиков, внедряют ИИ-ассистентов и всё чаще пробуют vibe coding — подход, при котором значительная часть кода создаётся по описанию задачи с помощью генеративного ИИ. Но вместе со скоростью растут и риски: уязвимости в собственной разработке, небезопасные зависимости, утечки секретов и чувствительных данных, ошибки во frontend-приложениях, проблемы legacy-кода и результаты проверок, которым разработчики не всегда доверяют.

Покупка SAST-сканера сама по себе уже не решает проблему. Без понятного процесса, политик безопасности, приоритизации находок и участия разработчиков анализ исходного кода быстро превращается в поток алертов. Поэтому в 2026 году важен не сам факт наличия сканера, а то, как он встроен в разработку: какие проверки запускаются, в какой момент, какие находки блокируют релиз, кто разбирает результаты, как учитываются требования ФСТЭК России и как не превратить DevSecOps в DevStopOps.

В прямом эфире AM Live разберём, как выстроить практику анализа безопасности исходного кода в современной разработке. Обсудим, какие проверки нужны помимо классического SAST, как работать с open source-зависимостями, frontend и ИИ-сгенерированным кодом, как выбирать российские решения, внедрять сканеры в CI/CD, работать с legacy-кодом и бороться с ложными срабатываниями.

Программа

Анализ исходного кода как часть DevSecOps

Почему тема анализа исходного кода на безопасность важна для российских компаний в 2026 году?
Какие риски возникают из-за недостаточного внимания к безопасности исходного кода?
Насколько опасен vibe coding (код, сгенерированный искусственным интеллектом) с точки зрения безопасности?
Почему установка SAST-решения сама по себе не делает разработку безопасной?
Кто должен быть владельцем процесса анализа кода: ИБ, AppSec, разработка, DevOps или продуктовые команды?
Какие классы проверок исходного кода нужны сегодня помимо классического SAST?
Почему анализ собственного кода без контроля open source-зависимостей уже недостаточен?
Почему безопасность frontend-приложений часто недооценивают?
Что именно и с какой периодичностью нужно проверять?
Какие находки нужно блокировать в pipeline, а какие лучше оставлять в режиме уведомлений и рекомендаций?
Как не превратить DevSecOps в DevStopOps (когда безопасность начинает тормозить разработку)?

Практика выбора и внедрения сканеров безопасности исходного кода в CI/CD

Насколько российские решения сегодня закрывают потребности в проверках безопасности исходного кода?
На что смотреть при выборе оптимального решения для проверки исходного кода?
Возможно ли внедрить все необходимые проверки кода на базе продуктов одного вендора?
Стоит ли одновременно использовать несколько сканеров от разных производителей?
С чего правильно начинать внедрение анализа исходного кода?
Какие языки программирования могут стать проблемой для анализа безопасности кода?
Кто должен разбирать результаты сканирования и подтверждать уязвимости?
Что делать с legacy-кодом, где после первого сканирования появляются сотни или тысячи алертов?
Как бороться с false positive и не потерять доверие разработчиков?
Какие метрики показывают, что анализ исходного кода реально работает?

Итоги и прогнозы

Какие технологии РБПО будут наиболее востребованы в ближайшие 2–3 года?
Как использование AI-ассистентов и vibe coding меняет риски безопасности исходного кода?
Как ИИ изменит практику поиска и исправления уязвимостей?
ТОП-3 рекомендации по повышению безопасности исходного кода, которые обязательно нужно сделать в 2026 году?