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

В небольших командах разработки вопрос безопасности закрывается обуче- нием сотрудников, ручной помощью AppSec и отчетами SAST, пусть они и состоят из общих описаний, ссылок на документацию и рекомендаций, почти не связанных с конкретным проектом. Но на масштабе в более чем 10 тыс. разработчиков ограничиваться этими мерами просто неэффективно. При этом блокировать релизы из-за каждой най- денной уязвимости тоже нельзя. Бизнесу нужна скорость, разработчикам – понят- ные рекомендации, а безопасности – уверенность, что проблема действитель- но устранена. Так постепенно сформировалась зада- ча – научиться быстро превращать результаты работы SAST в готовые исправления. Решением стал Safeliner – первый в России ИИ-ассистент по инфо- безопасности, работающий внутри кор- поративного контура, на внутренних дан- ных и стандартах компании, без внешних API. Его задача – отсекать ложные сра- батывания и предлагать готовый патч. Разработчику остается только подтвер- дить его. И хотя Safeliner лишь часть большой экосистемы ИИ-инструментов для раз- работки, благодаря ему поиск и исправ- ление уязвимостей ускорились в 5 раз, а экономический эффект составляет более миллиарда рублей в год. Важно правильно поставить задачу Вопрос нехватки AppSec-экспертов у нас был решен платформенным под- ходом к безопасности, который позволял одной команде сопровождать тысячи разработчиков. Необходимо было мас- штабировать экспертизу безопасной раз- работки в условиях нехватки времени – пока команда закрывала технический долг, новая функциональность ждала своей очереди. Поэтому задачу мы сформулировали следующим образом: сократить время исправления уязвимости и сделать так, чтобы исправление было быстрым и дешевым. Еще одной проблемой оказался шум статического анализа. Технологии, используемые в SAST, при высоком покрытии и полноте характеризуются большим количеством выдаваемых лож- ноположительных результатов. В резуль- тате значительная часть находок требует дополнительной проверки, а действи- тельно опасные проблемы тонут в общем потоке уведомлений. По оценкам Т-Банка, реальными оказываются лишь 20–30% срабатываний. Safeliner берет эту работу на себя. Он перепроверяет результаты анализа, отсеивает большую часть ложнополо- жительных находок и оставляет разра- ботчику только то, что действительно требует внимания. Поток шума удалось сократить более чем на 80%, а вместе с ним – и время, которое команды тратят на разбор отчетов. Проектируемдоверие разработчика Качество генерации оказалось лишь частью задачи. Не меньше времени ушло на то, чтобы понять, в каком виде разработчики вообще готовы принимать помощь от ИИ. Safeliner мы внедряли постепенно – в качестве помощника, а не как инстру- мент обязательного контроля. Команда экспериментировала с тем, где показы- вать рекомендации – прямо в среде разработки или при проверке merge request, как формулировать подсказки, сколько информации давать за один раз и каким должен быть готовый патч. Каждое изменение проверяли по про- дуктовым метрикам и обратной связи от разработчиков. Некоторым из них мы, например, на несколько месяцев отключали Safeliner, чтобы дождаться более доработанной версии и внедрять уже ее. Довольно быстро мы выяснили, что доверие к продукту строится из мелочей. Например, первый шаг пользователя не должен вызвать ментальную перегрузку, а подсказка должна учитывать контекст конкретного проекта, быть короткой и предлагать исправление, которое можно быстро проверить глазами. Разработчик без труда оценит изменение в две стро- ки, но вряд ли станет внимательно раз- бирать патч на несколько сотен строк. Сильное влияние оказал и язык. После перевода всех подсказок на русский разработчики заметно чаще принимали предложенные исправления. Еще одним результатом работы с обратной связью и проведения тысяч тестов оказалось, что разработчик не способен эффективно обработать десят- ки рекомендаций за один подход. В ходе эксперимента мы выявили, что ком- фортный объем включает одну-две под- сказки. Если рекомендаций становится больше, внимание рассеивается, а асси- стент начинает восприниматься как оче- редной источник шума. Мы также подтвердили собственную гипотезу о том, что исправления кода, с которым разработчик работал совсем недавно, принимаются лучше, так как контекст задачи еще свеж, а значит, гораздо проще оценить предложенное решение и принять его. Если разработчик все же переписы- вает предложенный патч, мы это не счи- таем неудачей. Такие случаи становятся источником новых знаний для ассистен- та. Система запоминает предпочтитель- ный способ исправления и постепенно подстраивает рекомендации под стиль конкретной команды и разработчика. Со временем ИИ начинает предлагать не просто корректные исправления, а те, которые с большей вероятностью примут без дополнительных правок. Самый простой способ оценить качество ИИ-помощника – посмотреть, сколько его исправлений разработчики прини- мают без изменений. В Т-Банке каждую пятую уязвимость закрывают именно так. 78 • СПЕЦПРОЕКТ ИИ-ассистент для безопасной разработки в Т-Банке есколько лет команда безопасной разработки Т-Банка уделяла особое внимание поиску как можно большего числа уязвимо- стей до выхода кода в продакшен. Появились зрелые процес- сы Shift Left, статические анализаторы встроились в CI/CD, а безопасность перестала быть финальной проверкой перед релизом. Мы научились автоматизировать обнаружение уязвимостей, но в определенный момент перестали справлять- ся с их своевременным исправлением. Н Роман Лебедь, Chief Hacking Officer, Т-Банк Фото: Т-Банк