Банки получили ИИ-разработчиков. А безопасность?
Банки получили ИИ-разработчиков. А безопасность? Данные AppSec Solutions за май 2026 года вскрывают драматический сдвиг в разработке ПО: • Объем кода под контролем: Вырос до 550 млн строк (+43% прогнозируется по итогам года). • Число уязвимостей: Достигло 3,1 млн находок (+70% за год). • Сроки исправления: Медианный срок латания критических дыр увеличился со 103 до 153 дней. • Исправление на практике: Реально закрывается лишь **от 12% до 50%**уязвимостей, уже переданных в разработку. Главный триггер ИИ-ассистенты и вайбкодинг. Программист больше не пишет каждую строчку вручную. Он выступает оператором LLM, генерируя код килобайтами. Однако, по данным международных отчетов (например, Veracode), ~44% ИИ-генераций содержат уязвимости. Если раньше разработка сдерживалась физической скоростью пальцев инженера, то теперь код пишется в десятки раз быстрее, а проверка безопасности упирается в дефицит кадров. Рынок кадрового голода в ИБ лишь разогревается (рост вакансий +26%), а инженеры просто физически не успевают разбирать завалы. Стек под прицелом: На чем горят разработки? По статистике отчета, универсально "безопасного" стека не существует, но распределение рисков весьма показательно: 1. Python (Лидер по плотности критического риска - 2,11 на 1000 строк): Активно внедряется в финтехе для задач Data Science, скоринга и интеграции ИИ. Высокая плотность связана с фрагментарностью кодовых баз и поверхностным отношением к валидации данных. 2. **Java (Абсолютный лидер по критическим дырам - ~2,4 тыс.):**Стандарт де-факто для банковского бэкенда и АБС (автоматизированных банковских систем). Из-за огромного объема наследуемого кода и тяжелых корпоративных систем Java генерирует основной массив реальных бизнес-рисков. 3. OWASP Top-10: 44% всех атакприходится на Broken Access Control(A01 - контроль доступа). Нейросети отменно верстают интерфейсы и пишут рутинные методы API, но регулярно "забывают" корректно прописать ролевые модели и права доступа (RBAC). Специфика Финтеха: Почему банковскому сектору стоит бояться? Для финтеха и цифрового банкинга эта тенденция носит критический характер по трем причинам: • 38,1% риска сидит в сторонних библиотеках (SCA). Финтех традиционно собирает сервисы из Open Source модулей. Нейросети охотно подтягивают устаревшие или уязвимые зависимости. При этом концентрация критических угроз (High+Critical) в сторонних компонентах выше (28% против 20,6% в собственном коде). • Законы и Банк России. ЦБ РФ постоянно ужесточает требования к технологической независимости и профилям защиты (ГОСТ Р 57580, регуляторика по КИИ). Отставание по срокам закрытия критических уязвимостей (до полугода!) создает прямую угрозу отзыва сертификатов или применения санкций регулятора. • Масштабирование "унаследованного непонимания". Как точно отмечают эксперты, ИИ не изобретает новые уязвимости - он тиражирует типовые ошибки в масштабе. Когда одна и та же LLM генерирует микросервисы для платежного шлюза, кредитного конвейера и ДБО, одна архитектурная ошибка мгновенно размножается на всю экосистему банка. Выход из пике Заливать проблему людьми бесполезно. ИБ-специалистов на рынке нет. Единственный путь, к которому приходит индустрия, - это экосистемная автоматизация DevSecOps: 1. Отсечение шума: От 81% до 88% первичных срабатываний сканеров - ложные (False Positives). Разгребать их вручную - преступная трата ресурсов. 2. **Авторазбор через LLM-агентов:**Автоматические правила и ИИ-помощники уже закрывают более 50-58% первичного разбора, снижая время первичной медианной оценки с 20 дней до нескольких часов. 3. Упряжка для ИИ (Harness): Разработка должна уходить от хаотичного "вайбкодинга" к жестким рамкам. ИИ-ассистент разработчика обязан работать внутри жестко заданных инструкций, а проверки кода (SAST/SCA) должны…