
Сегодня код создаётся быстрее, чем когда-либо: команды активно используют 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 году?
Приглашенные эксперты:
|
|
Александр Гадай Руководитель службы консалтинга, Swordfish Security |
![]() |
Сас Арустамян Директор Центра оценки соответствия и тестирования, НПО «Эшелон» |
Модераторы:
|
|
Виктор Бобыльков Директор по кибербезопасности, MWS Cloud |







