Две-три недели активного пентеста в году оставляют банку примерно 345 дней, когда его реальная внешняя поверхность атаки уже изменилась, а проверка осталась в прошлом. Для тех, кто отвечает за безопасность, разработку и интеграции, это плохая новость: непрерывное тестирование из опции для параноиков быстро превращается в базовую гигиену.
Именно на этот разрыв указывает BleepingComputer в спонсорском материале Sprocket Security. Повод выбран не теоретический: в апреле одна уязвимость в VPN привела к утечкам данных более чем у 70 финансовых организаций, работавших на инфраструктуре Marquis Software. Патч существовал, формальные проверки у пострадавших банков, вероятно, тоже были. Но ни то ни другое не помешало проблеме распространиться по портфелю.
Логика здесь неприятно простая. Классический ежегодный внешний пентест длится около двух-трех недель. Все остальное время компания живет в режиме предположения, что ее контур не меняется критично. В банковской реальности это почти фантастика. За год появляются новые облачные нагрузки, выкатываются релизы цифровых сервисов, подключаются финтех-партнеры по API, запускаются сторонние кабинеты на поддоменах банка, а после сделок M&A инфраструктура вообще собирается из разнородных фрагментов. В результате документ о прохождении теста описывает не текущее состояние, а аккуратно оформленную фотографию из прошлого.
На этом фоне особенно показательно выглядят цифры из отчетов, на которые ссылается материал. По данным Mandiant M-Trends 2026, медианное время присутствия злоумышленника в инфраструктуре в 2025 году составило 14 дней, причем после нескольких лет снижения метрика снова пошла вверх. Для шпионских кампаний средний показатель был еще хуже: 122 дня. А CrowdStrike в Global Threat Report 2026 поставила финансовый сектор на четвертое место по интенсивности интерактивных вторжений. Иными словами, атакующие давно не подстраиваются под ваш график аудитов. Если защита все еще живет в модели «проверились раз в год и закрыли вопрос», это удобно только для отчетности.
Отдельный неприятный момент в том, что регуляторы, по сути, уже давно намекают на ту же самую проблему. В материале перечислены PCI DSS, FFIEC и NYDFS. Ни один из этих режимов не говорит, что ежегодной проверки достаточно при любых обстоятельствах. PCI DSS 4.0 прямо требует внешнее тестирование после существенных изменений инфраструктуры или приложений. FFIEC рассматривает пентест как часть постоянного управления уязвимостями, а не как редкий ритуал с финальным PDF. NYDFS в секции 500.05 сохраняет ежегодное тестирование, но параллельно требует непрерывный мониторинг, причем эти обязательства были усилены поправками 2023 года к 23 NYCRR 500. Проще говоря, минимальная регуляторная планка писалась под мир, где серьезные изменения случались заметно реже, чем сейчас.
Самый сильный фрагмент текста, впрочем, не про нормативку, а про практику. Sprocket Security описывает кейс регионального банка, у которого на собственном поддомене работал клиентский портал оформления ипотеки от стороннего поставщика. Исследователи нашли API-эндпоинт, отдававший записи организаций по tenant ID без аутентификации и без сессии. Политика CORS позволяла вызвать этот запрос с любого стороннего сайта прямо из браузера посетителя. Сам tenant ID не нужно было подбирать вслепую: он присутствовал в публичных файлах самого портала. Дальше начиналась та часть, которую сканер обычно не делает за вас: последовательное перебирание tenant ID показывало записи следующего банка на общей платформе, а затем и других организаций, использующих тот же сервис, включая внутренний tenant самого вендора.
Сами данные тоже были не из серии «ну, утекла какая-то техническая ерунда». По описанию в материале, ответы API содержали имена сотрудников, корпоративные email, прямые телефоны, должности и внутренний код, который использовался платформой для привязки заявок заемщиков к конкретным специалистам. Этот код открывал еще один сценарий: имея валидное значение, можно было отправить заявку от имени указанного кредитного сотрудника, и система принимала ее как легитимный вход в конвейер оформления займа. С точки зрения банка это почти идеальный шторм: уязвимость внес не он, а поставщик платформы, но видимый снаружи адрес был банковский. Если бы дальше начались мошеннические заявки, фишинг или регуляторные претензии, в первой строке инцидента стояло бы имя банка, а не поставщика.
Почему такой кейс легко проскочит мимо ежегодного теста? В материале названы три причины, и все они выглядят правдоподобно. Во-первых, актив мог попасть во внешний периметр уже после фиксации скоупа пентеста. Во-вторых, поддомены со сторонними порталами часто оказываются в серой зоне ответственности: код не ваш, релизы не ваши, значит, многие команды автоматически считают, что и тестировать должен вендор. Нападающим, конечно, на эти организационные договоренности все равно. Если узел доступен из интернета под доменом банка, он входит в реальный периметр атаки. В-третьих, проблема требовала ручной логики, а не только автоматизированного сканирования. Сканер может заметить открытый эндпоинт, либеральный CORS и отсутствие аутентификации, но он не всегда пройдет путь до межтенантной выгрузки данных и подделки бизнес-операции.
Для русскоязычной IT-аудитории здесь важен не только банковский сюжет. Та же схема работает в любой компании, где IT-контур собирается из SaaS, подрядчиков, white-label-сервисов и быстрых интеграций. Продуктовые команды выкатывают фичи быстрее, DevOps пересобирают инфраструктуру, бизнес подключает нового партнера, а безопасность часто живет в квартальной или годовой ритмике. В итоге вопрос уже не в том, проходили ли вы пентест в этом году. Вопрос в том, проверил ли кто-то то, что реально изменилось за последние две недели.
Именно поэтому непрерывное тестирование обсуждают уже не как более дорогую версию привычного пентеста, а как попытку сократить структурный разрыв между скоростью изменений и скоростью проверки. Для банков, финтеха и крупных платформ это, похоже, становится не модным словом из презентации вендора, а рабочей моделью. Чем больше внешних зависимостей и чем быстрее меняется инфраструктура, тем хуже работает старая идея о том, что один аккуратный аудит способен честно описывать риск еще много месяцев спустя.