В эфире AM Live ведущие эксперты рынка обсудили, как меняется цикл безопасной разработки (РБПО / SDLC), почему открытый код и цепочки поставок стали одной из главных проблем и как внедрять лучшие практики, не превращая безопасность в формальный комплаенс.
- 1. Введение
- 2. Часть I. Как проектировать, разрабатывать и сопровождать безопасное ПО
- 3. Часть II. Практика DevSecOps в 2026 году
- 4. Выводы
Введение
Мир разработки программного обеспечения изменился до неузнаваемости. Монолиты уступили место микросервисам, CI/CD-конвейеры стали стандартом, а open source-компоненты теперь составляют основу большинства приложений. Эти трансформации, ускоряющие вывод продуктов на рынок, породили новую, сложную экосистему угроз. Атаки на цепочки поставок (supply chain) из теоретической угрозы превратились в повседневную реальность, способную скомпрометировать тысячи компаний через одну уязвимую библиотеку.
Одновременно с этим изменился и сам процесс разработки. Генеративный искусственный интеллект пишет код наравне с человеком, а в некоторых компаниях уже запрещают писать код вручную. Вайб-кодинг стал новой реальностью, где объёмы кодовых баз растут в геометрической прогрессии, а вместе с ними — и количество уязвимостей.
Классические подходы к анализу кода, основанные на паттерн-матчинге, перестают справляться: нейросети научились обходить детерминированные сканеры, а злоумышленники активно используют галлюцинации LLM для внедрения вредоносных пакетов в репозитории. В этих условиях безопасная разработка требует не просто новых инструментов, а переосмысления всей философии DevSecOps — от моделирования угроз до контроля цепочек поставок и защиты самого искусственного интеллекта.
Часть I. Как проектировать, разрабатывать и сопровождать безопасное ПО
В первой части эфира эксперты обсудили фундаментальные основы безопасной разработки: что такое РБПО сегодня, как распределяется ответственность между командами, почему моделирование угроз и контроль поверхности атаки становятся критически важными, а также какие ошибки чаще всего допускают при проектировании безопасной архитектуры. В центре внимания — эволюция подходов к безопасной разработке, роль человеческого фактора и вызовы, связанные с ростом объёма заимствованного кода.
Рисунок 1. Эксперты первой части эфира в студии AM Live
Участники эфира:
- Андрей Смирнов, руководитель отдела безопасности приложений и инфраструктуры, Эфшесть / F6.
- Данила Луцив, руководитель продуктов направления Vulnerability Management (VS, SPC, ASOC), Security Vision.
- Владимир Тележников, директор департамента анализа безопасности, «Группа Астра».
- Алексей Хорошилов, руководитель Центра исследований безопасности системного ПО, ИСП РАН.
- Антон Прокофьев, директор Центра разработки решений по контролю безопасности ПО, ГК «Солар».
- Кирилл Самосадный, руководитель направления защищённой разработки, SolidLab Group.
- Дмитрий Шмойлов, руководитель отдела безопасности ПО, «Лаборатория Касперского».
Ведущий и модератор эфира — Александр Савин, руководитель службы информационной безопасности, CDEK.
Современный взгляд на РБПО
Данила Луцив считает, что РБПО — это не просто проверка кода, а вся совокупность процессов, связанных с возникновением сервиса в продакшене. Начиная от проектирования и моделирования, через разработку, формирование артефактов, CI/CD и заканчивая продакшеном, каждый этап создаёт определённые угрозы. Вся эта замкнутая цепочка Software Security Development Life Cycle (SDLC) требует внимания на каждом этапе.
Дмитрий Шмойлов отметил, что SDLC не стоит на месте и постоянно эволюционирует. Он напомнил, что впервые начали упоминать SDLC в Microsoft и Oracle почти 20 лет назад. За это время многое изменилось: появилась работа с секретами, безопасность контейнеров, а индустрия подстраивается под новые технологии вместе с доработкой процессов разработки.
Антон Прокофьев убеждён, что РБПО — это не только безопасность, но и качество, и комплаенс в определённой пропорции. Он объясняет это на практическом примере: если у продукта не будет комплаенса, его не смогут продать в банк; если он функционально не будет работать, будут проблемы с эксплуатацией; а если не будет безопасности, компания разорится на инцидентах.
При этом основное ядро — это безопасность, защита от несанкционированного доступа и нарушения целостности, конфиденциальности и доступности. Качество кода тоже связано с безопасностью, поскольку некачественный код может привести к утечкам памяти и уязвимостям. Комплаенс же он называет внешней мерой для измерения соответствия требованиям рынка и заказчика.
Антон Прокофьев, директор Центра разработки решений по контролю безопасности ПО ГК «Солар»
Алексей Хорошилов обращает внимание на ключевой тренд последних лет — заимствованные компоненты стали занимать всё больший объём в продуктах, и размер такого кода растёт практически по экспоненте. Обеспечение безопасности этого кода становится серьёзной проблемой, и именно поэтому новые решения для борьбы с этими рисками стали трендом последнего времени.
Владимир Тележников отметил, что регуляторика и отраслевые стандарты идут по правильному пути. Он считает, что минимизация объёма заимствованного кода позволяет сократить поверхность атаки и высвободить ресурсы для анализа критичных компонентов, отвечающих за функции безопасности.
В первом опросе зрители поделились, на каком этапе разработки ПО в их компании подключается информационная безопасность:
- На этапе требований и архитектуры — 36 %.
- Полноценного процесса РБПО пока нет — 31 %.
- Во время разработки — 12 %.
- По требованию регулятора — 9 %.
- Перед релизом — 6 %.
- После инцидента или аудита — 6 %.
Рисунок 2. На каком этапе разработки ПО в вашей компании подключается ИБ?
Распределение ответственности и вовлечение разработчиков
Александр Савин поднял вопрос о том, как разграничить зоны ответственности в процессе РБПО. Он отметил, что безопасность, доступность и качество — это свойства продукта, за которые могут отвечать разные команды. При этом он задался вопросом: если ответственность общая, не приводит ли это к общей безответственности? И есть ли смысл использовать матрицы ответственности или другие инструменты для чёткого распределения ролей на разных этапах разработки?
Александр Савин, руководитель службы информационной безопасности CDEK
Дмитрий Шмойлов уточнил, что коллективная ответственность — это хорошо, но за конкретную часть продукта должен отвечать конкретный человек. Проблема безопасности в том, что в команде AppSec есть экспертиза, которой нет в других командах, поэтому их выделяют в отдельные подразделения.
Идеальный сценарий — когда экспертизу можно выращивать внутри команд разработки. Один из принципов РБПО — обучать девелоперов паттернам безопасности. Он приводит параллель с тестированием: раньше разработчики говорили, что пишут код, а тестеры пусть тестируют, но сейчас за свои баги отвечает разработчик. С безопасностью, по его мнению, отрасль идёт тем же путём.
Данила Луцив добавил: «Разработчики заинтересованы в безопасной разработке как в челлендже. Если у них есть знания и целеполагание, они готовы. Концепция Security Champions идеально ложится на эти подходы. Главное — с чего-то стартовать. Разработчики вовлекаются максимально, если есть внутренние CTF или Bug Bounty».
Андрей Смирнов обратил внимание на психологический барьер. Разработчики боятся сотрудника ИБ, как шлагбаума, который не пропускает релиз. Из-за этого некоторые начинают скрывать уязвимости, утверждая, что это false positive. Особенно, по его словам, разработчики боятся регуляторов. Он советует приходить к разработчикам и разговаривать, объяснять, почему нельзя писать так и почему такая архитектура. Нужно показывать им понятный результат, и тогда они начинают исправлять уязвимости.
Кирилл Самосадный считает, что ответственность нельзя делить — все должны быть заинтересованы в том, чтобы продукт был качественным и безопасным. По его мнению, основная сложность безопасной разработки в том, что это, с одной стороны, задача специалистов по ИБ, а с другой — разработкой занимаются разработчики. Главная задача — вовлечь разработчиков и показать им ценность безопасности как на уровне рядовых программистов, так и для бизнеса.
Кирилл Самосадный, руководитель направления защищённой разработки, SolidLab Group
Второй опрос показал, что для зрителей сложнее всего при внедрении РБПО на практике (множественный выбор):
- Совместить требования бизнеса и ИБ — 53 %.
- Обосновать ценность РБПО для руководства — 41 %.
- Не превратить РБПО в формальный комплаенс — 37 %.
- Встроить проверки в процесс разработки — 34 %.
- Распределить ответственность между ИБ, разработкой и продуктом — 32 %.
- Вовлечь разработчиков в процесс безопасности — 29 %.
Рисунок 3. Что оказывается сложнее всего при внедрении РБПО на практике?
Поверхность атаки и моделирование угроз
Андрей Смирнов начал с примера. При моделировании угроз всё выглядит защищённым, но есть небольшой статус-пейдж, доступный извне, взятый из open source без проверки. В нём множество CVE, и через Command Injection или RCE злоумышленник получает доступ к инфраструктуре. Поэтому при моделировании угроз нужно рассматривать не только библиотеки, но и такие проекты, и проверять их с помощью анализа защищённости, статического и композиционного анализа. Обязательно после моделирования угроз проверяйте, действительно ли закрыты порты.
Андрей Смирнов, руководитель отдела безопасности приложений и инфраструктуры, Эфшесть / F6
Владимир Тележников считает, что поверхность атаки — это то, до чего может дотянуться потенциальный нарушитель: сетевые сервисы, интерфейсы взаимодействия. Он подчёркивает, что поверхность нужно приоритизировать, потому что исследовать всё ядро можно, но закрыть его фаззингом невозможно из-за огромного объёма. Нужно выделять модули, фильтрующие данные, и обкладывать их проверками. Уязвимости тоже нужно приоритизировать по достижимости и влиянию на продукт. Поверхность нужно минимизировать как на уровне компонентов, так и внутри них.
Владимир Тележников добавил, что нужно исключать функциональные возможности, которые не нужны по модели угроз. Часто бывает, что сервис проверили, а у него есть забытые сценарии применения, которыми пользуются нарушители.
Нужно постоянно актуализировать поверхность атаки. Если это сетевые сервисы — обкладываем фаззингом и динамическим контролем. Если аутентификация — делаем акцент на модульном и интеграционном тестировании.
Владимир Тележников, директор департамента анализа безопасности, «Группа Астра»
Данила Луцив отметил практическую пользу разметки поверхности атаки. Он объясняет, что это пререквизит Security Code Review. Если команда меняет кнопку или аутентификацию на поверхности атаки, количество Merge Request, которые нужно смотреть безопаснику, кратно уменьшается. Если же смотреть всё подряд, безопасники будут перегружены.
Алексей Хорошилов обратил внимание на сложность анализа. Данные, обрабатываемые кодом, не всегда обрабатываются на первом слое — прилетел архив, разархивировался, передался дальше. Анализ таких потоков нетривиален. Нужен экспертный анализ на основе архитектуры, а также инструменты для отслеживания потоков данных. Он подчёркивает, что в новой редакции методики ФСТЭК применение инструментов для анализа поверхности атаки уже становится обязательным.
Дмитрий Шмойлов рассказал о практическом подходе. Модель угроз — это первый артефакт и описание архитектуры для понимания, где находятся критичные элементы. Нужно правильно описать как сами части продукта, так и границы доверия. Пересечение границ доверия — это аутентификация. Если её нет или невозможно сделать, нужны очень жёсткие механизмы проверки.
Дмитрий Шмойлов, руководитель отдела безопасности ПО, «Лаборатория Касперского»
Третий опрос показал, что является для зрителей самым критичным с точки зрения процесса РБПО (мультивыбор):
- Сторонний код и open source-компоненты — 68 %.
- LLM-инструменты и разработка с помощью ИИ — 57 %.
- Архитектура и модель угроз — 52 %.
- Контейнеры и Kubernetes — 46 %.
- Репозитории, сборки и артефакты — 32 %.
- Заказная разработка и внешние поставщики ПО — 31 %.
- Low-code / no-code-платформы — 23 %.
Рисунок 4. Что является для вас самым критичным с точки зрения процесса РБПО?
Ошибки при проектировании безопасной архитектуры приложения
Андрей Смирнов считает главной ошибкой мнение, что приложение будут использовать так, как задумано. На самом деле им будут злоупотреблять, кидать «грязь» в API, работать с файлами. Нужно обязательно делать нагрузочное тестирование, crash-тестирование и AppSec-тестирование.
Данила Луцив выступает за максимальную шаблонизацию. По его мнению, чем быстрее команда переходит от запроса к конкретной части кода, отвечающей за функциональность, тем лучше. На шаблонные вопросы в рамках проектирования должны быть шаблонные ответы.
Владимир Тележников предупредил: «Интегрируйте ровно то, что нужно. Не пытайтесь затащить монстра, когда нужна небольшая функциональность. И проектируйте системы так, чтобы они использовали уже заложенные компоненты. Аутентификация должна быть завязана на один стек — не так, чтобы каждое приложение реализовывало свой подход. Это путь в никуда и расширение поверхности атаки».
Алексей Хорошилов предложил найти баланс между подходом к прототипированию и разработкой продакшн-кода. По его мнению, одна из типовых ошибок — когда разработчик сначала пишет код для проверки гипотезы, не задумываясь о безопасности, а потом оказывается, что этот код уже планируется отправлять в продакшн. Переключиться с прототипа на качественное решение в этот момент оказывается сложно, и в результате в продукт попадает код, изначально не рассчитанный на промышленную эксплуатацию.
Алексей Хорошилов, руководитель Центра исследований безопасности системного ПО, ИСП РАН
Антон Прокофьев призвал пользоваться базовыми принципами Secure by Design: принципом наименьших привилегий, а также уделять внимание аутентификации, авторизации и пользовательскому вводу — именно в этих областях чаще всего возникают ошибки.
Кирилл Самосадный заметил, что все фокусируются на технических проблемах, которые умеют находить инструменты, но забывают о бизнес-логике. Бизнес-логика сейчас плохо покрывается инструментарием, и это область, где требуется внимание эксперта.
Дмитрий Шмойлов посоветовал подойти к проектированию комплексно и не пытаться создавать временные решения, которые впоследствии приведут к архитектурному долгу и усложнят поддержку системы. Security by Design должен быть в голове у архитектора, а если не хватает экспертизы, её стоит искать у коллег из смежных подразделений или на рынке.
Топ-3 рекомендаций для усовершенствования процессов РБПО
Андрей Смирнов рекомендовал: 1. Разговаривать с разработкой — объяснять, а не приказывать. 2. Принять неизбежность ИИ и использовать его для триажа, но относиться к нему как к объекту РБПО. 3. Трезво оценивать необходимость сертификации.
Данила Луцив посоветовал начать с инвентаризации — собрать всё, что есть, особенно с большим blast radius. Затем провести приоритизацию критических компонентов. И главное — договориться с разработчиками о ресурсах на исправление уязвимостей, иначе результаты сканеров останутся невостребованными.
Данила Луцив, руководитель продуктов направления Vulnerability Management (VS, SPC, ASOC), Security Vision
Владимир Тележников рекомендовал постоянно актуализировать поверхность атаки, не останавливаться на одном инструменте (комбинировать SAST, DAST и другие методы) и участвовать в профильных сообществах для повышения экспертизы.
Алексей Хорошилов подчеркнул важность инвестиций в людей — ИИ не заменит экспертов, усиления приоритизации и анализа поверхности атаки, а также взаимодействия с апстримом open source-компонентов.
Антон Прокофьев выделил три направления: оценить текущий уровень зрелости, развивать культуру безопасной разработки через удобные процессы и использовать качественные инструменты.
Кирилл Самосадный посоветовал унифицировать процессы разработки в разных командах, следить за уязвимостями в опенсорсе и использовать тренды (включая ИИ) для автоматизации рутины.
Дмитрий Шмойлов добавил, что Bug Bounty даёт обратную связь по проблемам, и посоветовал не проламывать стену, а договариваться — искать компромиссы с теми, кто принимает решения, и оставаться в позитиве.
В рамках четвёртого опроса зрители ответили, планируют ли они усиливать процессы РБПО после эфира:
- Возможно, но пока это не приоритет — 43 %.
- Будут усиливать текущие процессы — 32 %.
- Текущего уровня РБПО достаточно — 13 %.
- Планируют запуск нового проекта — 12 %.
Рисунок 5. Планируете ли вы усиливать процессы РБПО после эфира?
Первая часть эфира показала, что РБПО — это не просто набор инструментов, а комплексная система, объединяющая процессы, людей и технологии. Ключевые выводы: безопасность должна встраиваться на самых ранних этапах разработки, ответственность за неё распределена между всеми участниками процесса, а поверхность атаки требует постоянного мониторинга и приоритизации. При этом главным вызовом остаётся не выбор инструментов, а выстраивание культуры безопасности и вовлечение разработчиков.
Часть II. Практика DevSecOps в 2026 году
Можно ли доверять коду, написанному нейросетью? Где проходит грань между ускорением разработки и компрометацией безопасности? Почему внедрение SAST само по себе не делает разработку безопасной? И как выстроить процессы, чтобы анализаторы действительно работали? Эти вопросы стали центральными в дискуссии экспертов.
Рисунок 6. Эксперты второй части эфира AM Live
Участники эфира:
- Алексей Жуков, лидер продуктовой практики AppSec, Positive Technologies.
- Анна Архипова, ведущий менеджер по развитию бизнеса SASTAV, ITD Group.
- Михаил Парфенов, AppSec Lead, DPA Analytics.
- Антон Володченко, руководитель разработки продуктов, CodeScoring.
- Александр Лысенко, ведущий эксперт по безопасности разработки и ИИ, К2 Кибербезопасность.
- Сас Арустамян, директор Центра оценки соответствия и тестирования, НПО «Эшелон».
- Александр Гадай, руководитель службы консалтинга, Swordfish Security.
Ведущий и модератор — Виктор Бобыльков, директор по кибербезопасности, MWS Cloud.
Код как новый риск: вызовы 2026 года
Александр Гадай считает, что главный фактор — взрывной рост вайб-кодинга. По его словам, разработчики доверяют сгенерированному коду, даже не читая его. Он приводит пример из практики: «Аналитик увидел в коде закомментированный фрагмент с подписью чат-бота: “выбери здесь реализацию, первую или вторую”. Функция возвращала true и так и осталась нераскомментированной. Если бы этот метод реализовывал функцию безопасности, последствия могли быть катастрофическими».
Александр Гадай, руководитель службы консалтинга, Swordfish Security
Антон Володченко отметил, что SAST традиционно является первым инструментом, который компании стараются внедрить при построении безопасной разработки. Когда речь заходит о РБПО, взгляд в первую очередь обращается именно на статический анализ — код пишется, значит, его нужно проверять сразу.
Но главное — не останавливаться на этом. Нередки случаи, когда SAST внедряли, но результаты сканирования так и оставались неразобранными. Такой подход не имеет отношения к практической безопасности.
Инструмент должен давать реальные результаты, и с этими результатами нужно работать — обрабатывать срабатывания, исправлять найденные уязвимости и подтверждать их устранение. Только тогда продукт становится действительно безопасным.
Антон Володченко, руководитель разработки продуктов, CodeScoring
Александр Лысенко добавил, что природа рисков не меняется со временем — в основе всегда лежат уязвимости и угроза взлома. Однако построить взвешенный риск-ассесмент без процесса управления уязвимостями невозможно. Без такого процесса компания просто не знает, насколько уязвима её экосистема, и управление рисками сводится к примитивной оценке — взломали или нет. Именно DevSecOps позволяет перейти на более продвинутый уровень работы с рисками, обеспечивая прозрачность и возможность принимать обоснованные решения.
В чём опасность вайб-кодинга?
Анна Архипова поделилась кейсом из практики, демонстрирующим, как разработчики могут использовать искусственный интеллект в обход существующих механизмов безопасности. В одном из проектов команда разработчиков передала нейросети результаты сканирования SAST и попросила её модифицировать код так, чтобы результаты анализа улучшились. Нейросеть, не имея задачи сделать код безопаснее, выявила паттерны, по которым работает анализатор, и адаптировала код для их обхода.
В итоге код не стал безопаснее — он просто перестал обнаруживаться классическим SAST, который основан на паттерн-матчинге. Этот случай показывает, что традиционных детерминированных подходов к анализу кода уже недостаточно. Рынку требуются более интеллектуальные решения, способные анализировать не только отдельные паттерны, но и контекст, семантику и сценарии использования кода.
Анна Архипова, ведущий менеджер по развитию бизнеса SASTAV, ITD Group
Михаил Парфенов привёл один из наиболее показательных случаев — атака на пакетный менеджер NPM с использованием техники слоп-сквоттинга. Суть атаки заключается в том, что нейросети из-за галлюцинаций генерируют имена несуществующих пакетов, и эти имена оказываются предсказуемыми. Злоумышленники воспользовались этим: они заранее загрузили вредоносные пакеты с такими именами в репозиторий NPM.
Разработчики, использующие ИИ для написания кода, по рекомендации нейросети добавляли в свои проекты эти несуществовавшие ранее пакеты, которые автоматически загружались при сборке, и на их машинах запускался вредоносный код. За год эти пакеты были скачаны более 90 000 раз, что делает эту атаку одной из самых масштабных в своей категории.
Александр Лысенко предлагает разграничить понятия вайб-кодинга и использования ИИ-агентов в разработке, поскольку между ними есть принципиальная разница. Вайб-кодинг — это подход, при котором разработчик не смотрит на генерируемый код, а проверяет только конечный результат. Такой метод отлично подходит для прототипирования и быстрой проверки гипотез, но для продакшн-разработки он неприемлем.
Сам код, генерируемый современными LLM, представляет собой нечто среднее — по его оценке, это уровень крепкого мидл-разработчика. Поэтому ключевой вопрос заключается не в том, насколько хорош или плох сгенерированный код, а в том, как выстроен процесс вокруг его использования и какими средствами контроля он обложен.
Александр Лысенко, ведущий эксперт по безопасности разработки и ИИ, К2 Кибербезопасность
Алексей Жуков привёл данные исследования компании Veracode, которые иллюстрируют тревожную тенденцию в области безопасности кода, сгенерированного большими языковыми моделями. За последние три года доля уязвимого кода, созданного с помощью LLM, сократилась незначительно — с 55 до 45 %. При этом код, который синтаксически корректен и просто компилируется, уже достигает почти стопроцентного показателя.
Однако ситуация с кодом, свободным от уязвимостей, остаётся крайне неудовлетворительной. Это означает, что нейросети научились писать синтаксически правильный код, но продолжают генерировать значительное количество уязвимостей.
В первом опросе зрители поделились, как у них сейчас организован анализ безопасности исходного кода:
- Применяют все возможные инструменты — 27 %.
- Полноценного процесса анализа кода пока нет — 23 %.
- Применяют SAST, DAST и SCA — 21 %.
- Используют SAST только перед релизом — 12 %.
- Используют SAST на регулярной основе — 11 %.
- Применяют SAST и DAST — 6 %.
Рисунок 7. Как у вас сейчас организован анализ безопасности исходного кода?
SAST как инструмент и его ограничения
Сас Арустамян привёл аналитику срабатываний классического анализатора. Из 100 % срабатываний, которые выдаёт анализатор, в срочном порядке необходимо исправлять лишь около 35 % — это дефекты наивысшего уровня критичности, которые создают непосредственную угрозу безопасности.
Ещё примерно 25 % срабатываний устраняются в плановом порядке, поскольку их критичность не требует немедленного вмешательства. Оставшаяся часть приходится на ложноположительные срабатывания и те дефекты, которые по тем или иным причинам не требуют исправления в текущем цикле разработки.
Сас Арустамян, директор Центра оценки соответствия и тестирования, НПО «Эшелон»
Сас Арустамян подчеркнул, что само по себе внедрение SAST-решения является лишь первым шагом на пути к безопасной разработке. Для серьёзной промышленной разработки все проверки должны быть полностью автоматизированы — невозможно запускать статический анализ вручную при каждом коммите или релизе.
Однако даже автоматизации недостаточно. Разработчик не может эффективно работать со 100 % срабатываний, полученных от анализатора. Ему нужна помощь в триаже — первичной обработке и разметке результатов. Именно эту функцию, по его мнению, должен выполнять Security Champion, который берёт на себя анализ срабатываний, отсеивает ложные и снижает нагрузку на команду разработки, предоставляя им только те дефекты, которые действительно требуют внимания и исправления.
Он также перечислил несколько типов критичных уязвимостей, которые требуют незамедлительного исправления при обнаружении в коде: переполнение буфера, наличие секретов в коде, ошибки работы с памятью, инъекции.
Алексей Жуков уверен, что в процессах разработки должно наступить понимание, что уязвимость — это такой же дефект в коде, как и любая другая ошибка, и её необходимо устранять. Нельзя относиться к уязвимостям как к чему-то абстрактному или находящемуся за пределами зоны ответственности разработчика. Одних инструментов недостаточно — нужны выстроенные процессы. Именно процессы формируют правильное отношение к безопасности на всех этапах разработки и делают её неотъемлемой частью работы каждого участника команды.
Алексей Жуков, лидер продуктовой практики AppSec, Positive Technologies
Как выбирать SAST в 2026 году
Алексей Жуков: «Отталкивайтесь от того, насколько конкретный инструмент пригоден для работы именно в вашей компании. Бесполезен Battle Card, который ориентирован только на количество языков — анализатор знает 34 языка, но в 2026 году это умеет анализировать Fortran. Смотрите, насколько возможности продукта соответствуют вашему стеку технологий».
Анна Архипова: «Важна эффективность продукта, чтобы количество точных срабатываний устраивало. Также важно учитывать, перерастёте ли вы инструмент. Смотрите перспективу, насколько он помогает всем участникам процесса».
Михаил Парфенов: «Обязательно сделайте синтетический тест. Возьмите в рамках вашего стека языки и фреймворки, сделайте примеры SQL-инъекций и XSS с разным синтаксисом, раскиньте по разным файлам и отсканируйте. В идеале любой SAST должен всё найти».
Михаил Парфенов, AppSec Lead, DPA Analytics
Антон Володченко: «Смотрите на регуляторику. Если вам нужно сертифицироваться, лучше выбирать инструменты, одобренные регулятором, иначе будет сложно получить сертификат».
Александр Лысенко: «Отметайте всё, что не подходит с точки зрения функциональности. Не используйте SAST, которые не работают с вашим стеком, библиотеками. Останется 2–3 варианта — дальше уже в рамках пилота выбирайте».
Сас Арустамян: «Если нужна сертификация, стоит выбирать одобренные инструменты. Однако не всегда инструменты, удовлетворяющие регуляторным требованиям, поддерживают ваш стек технологий. Тогда нужен диалог с регулятором».
Александр Гадай: «Нельзя забывать про производительность и масштабируемость. Если релизы раз в месяц — можно взять долгий SAST. Если несколько раз в день — нужен быстрый, который сразу покажет разработчику проблему».
Во втором опросе зрители ответили, какие проверки кода они считают самыми важными (мультивыбор):
- Поиск уязвимостей в собственном коде — 94 %.
- Поиск секретов и чувствительных данных в коде — 87 %.
- Анализ open source-зависимостей — 83 %.
- Анализ ИИ-сгенерированного кода — 53 %.
- Проверка API и серверной логики — 52 %.
- Проверка legacy-кода — 42 %.
- Проверка frontend-приложений — 36 %.
Рисунок 8. Какие проверки кода вы считаете самыми важными?
Искусственный интеллект в поиске и исправлении уязвимостей
Виктор Бобыльков привёл пример, как ИИ меняет подходы к поиску и исправлению уязвимостей. Он рассказал об опыте Т-Банка, где запустили продукт, автоматически прогоняющий код на уязвимости, а LLM сразу же исправляет найденные проблемы в коде, чтобы в pull request он ушёл уже без уязвимостей.
Виктор Бобыльков, директор по кибербезопасности, MWS Cloud
Анна Архипова видит ограничения в полной замене SAST на LLM: для энтерпрайза это колоссальные затраты на токены, локальные модели работают медленно, а контекстное окно ограничено 400 тысячами строк. Поэтому её компания выбрала гибридный подход, сочетающий SAST и ИИ. Анна также обращает внимание на защиту самого ИИ: внедряя его в инструменты безопасности, компания отвечает за его защищённость и развитие.
Александр Лысенко рассказал пример из своей практики: обучили ИИ-агента работать с ASOC-платформой, загоняли его в цикл и дополнительно давали инструментарий по работе с Git и SAST. Это позволило преодолеть проблему контекстного окна — ИИ брал конкретную уязвимость, которую нашёл, дополнительно просматривал пограничные значения. Чем качественнее настроен тулинг и воркфлоу вокруг ИИ, тем лучше будет результат.
Александр Гадай прогнозирует рост количества агентных систем в ближайшие 2–3 года. Возникает задача проверять безопасность самих моделей — уже появляются инструменты для динамического тестирования и защиты агентов в реальном времени.
Алексей Жуков прогнозирует появление асимметричных мер противодействия — механизмов, заставляющих атакующего бесцельно тратить токены и вычислительные ресурсы. У LLM огромное будущее, но нельзя забывать, что это ресурсозатратная технология, и в этом направлении меры митигации рисков будут развиваться.
Третий опрос показал, что, по мнению зрителей, сложнее всего при внедрении анализа кода в CI/CD (мультивыбор):
- Вовлечь разработчиков в разбор результатов — 56 %.
- Разбирать большой поток находок — 56 %.
- Бороться с ложными срабатываниями — 51 %.
- Настроить проверки без торможения релизов — 47 %.
- Работать с legacy-кодом — 32 %.
- Обосновать пользу процесса для бизнеса — 23 %.
- Выбрать подходящие сканеры — 13 %.
Рисунок 9. Что сложнее всего при внедрении анализа кода в CI/CD?
Топ-3 рекомендаций по повышению безопасности разработки
Алексей Жуков: «1. Повышать зрелость и понимание, что за безопасность надо платить, а за отсутствие — расплачиваться. 2. Внедрять даже простые инструменты вроде Semgrep, чтобы начать обрабатывать результаты. 3. Обучать разработчиков, отправлять на конференции, чтобы они понимали, как мыслят и действуют хакеры».
Анна Архипова: «Важно вовлекать разработчиков, чтобы у них был живой интерес писать качественный и безопасный код. Плагины для IDE есть, но ими не пользуются, потому что проверка всё равно автоматически запустится. Нужна внутренняя мотивация».
Михаил Парфенов: «Фронтенд-приложения — важная цель для злоумышленников. Нужно построить модель угроз по Frontend KillChain и провести пилот FAST-анализатора».
Антон Володченко: «Будьте любознательными, читайте расследования атак. А тем, кто считает, что текущего уровня проверок достаточно, советую перепроверить».
Александр Лысенко: «На ближайшие полгода — подтянуть покрытие юнит-тестов и code style на линтерах. Посмотреть, как организован Git Flow и доступы в CI. Подключить базовые сканеры с ASOC-платформой и начать смотреть результаты».
Сас Арустамян: «1. Полный контроль цепочек поставок, композиционный анализ. 2. Shift-Everywhere, на всех этапах. 3. Автоматизация всех проверок — SAST, FAST и других — под чутким вниманием специалистов».
Александр Гадай: «1. Безопасность цепочки поставок. 2. Практика управления секретами. 3. Анализ конфигураций — эта практика быстро внедряется и приносит значительную пользу».
Финальный опрос показал, планируют ли зрители усиливать анализ безопасности исходного кода после эфира:
- Будут усиливать текущий процесс — 37 %.
- Планируют запуск нового проекта — 28 %.
- Текущего уровня проверок достаточно — 22 %.
- Возможно, но пока это не приоритет — 13 %.
Рисунок 10. Планируете ли вы усиливать анализ безопасности исходного кода после эфира?
Выводы
Два эфира AM Live, объединённые темой безопасной разработки, показали, что индустрия находится в точке фундаментальной трансформации. 2026 год стал рубежом, где традиционные подходы к РБПО перестают работать в одиночку, а на смену им приходят комплексные решения, объединяющие процессы, людей и технологии.
Безопасность больше не может быть реактивной. Она должна встраиваться на самых ранних этапах разработки — от моделирования угроз до написания кода. При этом безопасность не должна превращаться в шлагбаум: правильно выстроенные процессы позволяют не тормозить разработку, а делать её более устойчивой к угрозам.
Культура и люди остаются важнее инструментов. SAST, DAST, SCA и FAST — это лишь средства, которые работают только в руках квалифицированных специалистов и при наличии выстроенных процессов. Недостаток кадров остаётся главным ограничением, и здесь на помощь приходит искусственный интеллект, который способен взять на себя триаж, генерацию патчей и анализ больших объёмов кода. Однако ИИ не заменит эксперта — он лишь усиливает его возможности.
Безопасная разработка перестаёт быть уделом узких специалистов и становится общей ответственностью всей команды. Инструменты развиваются, регуляторика становится более понятной, а практики — более зрелыми. Но главным остаётся понимание: за безопасность надо платить, а за её отсутствие — расплачиваться. Выбор за каждой компанией.
Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка ИБ и ИТ. Будьте в курсе трендов и важных событий. Для этого подпишитесь на наш YouTube-канал. До новых встреч!
