Банки получили ИИ-разработчиков. А безопасность?
Данные 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) должны происходить на этапе каждого коммита (CI/CD), а не перед релизом.
По итогу "Вайбкодинг" победил. Отката к ручному написанию строк не будет. Банкам и финтех-компаниям придется осознать: скорость написания кода больше не является конкурентным преимуществом. Главное - скорость его безопасной валидации.
#IF_ИИ
Данные 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) должны происходить на этапе каждого коммита (CI/CD), а не перед релизом.
По итогу "Вайбкодинг" победил. Отката к ручному написанию строк не будет. Банкам и финтех-компаниям придется осознать: скорость написания кода больше не является конкурентным преимуществом. Главное - скорость его безопасной валидации.
#IF_ИИ