Журнал "Information Security/ Информационная безопасность" #3, 2026

Первые версии Safeliner работали по простому правилу: ассистент советует, разработчик решает. Такой подход поз- волял быстрее привыкнуть к новому инструменту и не размывал границу ответственности за код. Со временем, когда качество Safeliner в отдельных типовых сценариях стало сопоставимо с работой хорошего экс- перта по безопасности, мы доверили ему часть рутинных решений. Прежде всего – работу с ложноположительными срабатываниями. Теперь Safeliner не только предлагает исправления, но и перепроверяет выво- ды статического анализатора. Если раз- работчик пытается отметить находку как ложноположительную, ассистент может повторно проанализировать код и, если видит реальную уязвимость, не позволит закрыть ее таким образом. То есть ассистент уже принимает отдельные решения самостоятельно, но делает это только там, где риск ошибки хорошо контролируется и его вывод можно проверить. Все, что касается изменений в коде и их последствий, по- прежнему остается ответственностью разработчика. Безопасный отказ вместо красивой галлюцинации Известный риск любого ИИ-помощни- ка – уверенное предложение неправиль- ного решения. В безопасной разработке цена такой ошибки слишком высока. Правдоподобный, но небезопасный патч способен создать новую уязвимость или нарушить работу приложения. Поэтому наша задача не сводится к тому, чтобы сгенерировать исправление. Главное – убедиться, что его вообще можно предлагать разработчику. Для этого Safeliner проверяет каждое решение по нескольким независимым мет- рикам, которые мы собирали на основе собственных исторических находок, лучших мировых практик, открытых и закрытых датасетов и бенчмарков. Дополнительно Safeliner содержит некоторые механики Evals и Guardrails, которые фиксируют, например, не ломают ли предложенные изменения юнит-тесты и сборку программы, не подсвечивает ли статический анализа- тор новые проблемы. Если хотя бы одна из проверок не проходит, ассистент пыта- ется построить другое решение. Если и после нескольких попыток под- ходящий вариант не находится, система честно признает, что не может безопасно решить эту задачу. Для ИИ-ассистента это не недостаток, а необходимое свой- ство. В разработке отказ от генерации иногда оказывается безопаснее, чем убедительный, но неверный ответ. Разработчику нужно не сообщение, а объяснение Отчет статического анализатора редко отвечает на главный вопрос разработчи- ка: зачем вообще это исправлять сейчас? Он сообщает о потенциальной проблеме, приводит описание правила и дает ссылку на документацию. Дальше разбираться приходится самостоятельно. Safeliner действует по-другому. Вместо абстрактного предупреждения разработ- чик получает объяснение, привязанное к коду. Ассистент показывает, как эту уязвимость можно эксплуатировать, чем она опасна в конкретной ситуации, и сразу предлагает вариант исправления. Такой подход меняет отношение к находкам статического анализа. Благо- даря ему усиливается восприятие важ- ности работы над уязвимостью, а также повышается мотивация более осознанно и ответственно подойти к своей работе. По наблюдениям Т-Банка, после внед- рения Safeliner количество исправленных находок выросло в разы по сравнению с классической моделью Shift Left, где команда разработки остается один на один с отчетом сканера. AppSec уже не котролер Долгое время безопасность воспри- нималась разработчиками как внешний контроль. Сканер находил уязвимость, AppSec подтверждал ее, после чего задача возвращалась в разработку. Для команды это выглядело как очередное ограничение, которое мешает быстрее выпустить новую функциональность. В Т-Банке мы считаем, что задача отдела безопасности – не создавая лиш- них барьеров и сложностей, предложить разработчику инструменты и правила, которые позволят ему выполнять работу быстрее и эффективнее. В идеальном мире разработчик вообще не должен замечать эти инструменты. Этого и получилось добиться с Safeliner – разработчик получает возможность разо- браться в проблеме, не переключаясь на поиск документации или консультацию с экспертом. Безопасность начинает эконо- мить время, а не только требовать его. При этом о коде придется думать иначе. Уже сегодня агентные среды вроде Claude Code или Codex позволяют создавать сложные приложения людям, которые не являются профессиональ- ными программистами. Код постепенно становится промежуточным представ- лением, а внимание смещается к конеч- ному результату. Это не означает, что понимание безопасности потеряет цен- ность. Наоборот. Если все больше кода будет писать ИИ, безопасность должна переместиться туда же – внутрь инстру- ментов, которые этот код создают. Safeliner меняет роль и AppSec-коман- ды. К нему постепенно переходят типо- вые задачи безопасности – объяснение уязвимостей, подготовка исправлений, проверка ложноположительных сраба- тываний. Это освобождает время для того, что по-прежнему плохо поддается автоматизации: анализа новых классов атак, исследования архитектурных рис- ков и новых подходов к защите. Поэтому вместо бесконечного поиска и разбора одинаковых находок главной задачей AppSec-специалистов становит- ся преобразование собственной экспер- тизы в автоматизированные механизмы защиты – правила, базы знаний и сце- нарии работы ИИ. Один удачно найден- ный подход смогут использовать уже не один инженер, а тысячи команд. Уязвимости одинаковые, а исправления – нет На первый взгляд кажется, что ИИ- ассистент по безопасной разработке должен одинаково хорошо работать в любой компании. Большинство уязви- мостей давно описаны, существуют отраслевые стандарты и рекомендации по их устранению. На практике все сложнее. Одну и ту же проблему разные организации исправляют по-разному. Причина не в требованиях безопасности, а в особен- ностях архитектуры, внутренних библио- тек, корпоративных стандартов разра- ботки и инженерных практиках. Поэтому универсального рецепта не существует. Хороший ИИ-ассистент должен знать не только общие принципы безопасной раз- работки, но и понимать, как принято писать код именно в этой компании. В Safeliner источником таких знаний служат внутренние регламенты и накоп- ленный опыт предыдущих исправлений. Если корпоративных рекомендаций нет, ассистент опирается на отраслевые стан- дарты, базу успешных решений и знания языковой модели. Сейчас ИИ лучше всего справляется с типовыми задачами: объяснить уязви- мость, предложить локальное исправ- ление, подготовить безопасный патч и проверить его на очевидные ошибки. В заключение Первые ИИ-помощники воспринима- лись как еще одна утилита, к которой разработчик обращается по необходи- мости. Этот подход быстро показал свои ограничения. Чтобы приносить пользу, AppSec должен стать частью привычного процесса разработки, а не существовать отдельно от него. В Т-Банке Safeliner встроен сразу в несколько этапов жизненного цикла кода. Он помогает разработчику прямо в среде разработки, сопровождает проверку merge request и участвует в отложенном анализе больших кодовых баз, где можно запускать более ресурсоемкие сценарии. Тысячи сотрудников банка пользуются инструментом еженедельно. Мы ожидаем, что через несколько лет наши разработчики вообще перестанут открывать отчеты SAST. Вместо этого они будут получать уже готовое объ- яснение, исправление и проверку уязви- мостей в рамках инженерной платфор- мы, а такие инструменты безопасности, как Safeliner, станут полноценной частью среды разработки. l • 79 ИИ-АССИСТЕНТЫ В ИБ www.itsec.ru