Исследователи ZeroPath проверили 20 AppSec-сканеров и нашли серьезные проблемы у пяти из них: от утечек облачных ключей и токенов GitHub до доступа к рабочей базе данных одного из вендоров. Для команд, которые строят DevSecOps вокруг автоматических проверок, вывод неприятный: инструмент, который должен снижать риск атак на цепочку поставок, сам может стать удобной точкой входа.
Об этом 29 июля написал со ссылкой на исследование ZeroPath. Речь не о привычном сценарии, когда злоумышленники взламывают инфраструктуру вендора и подсовывают зараженный релиз. По словам исследователей, иногда достаточно отправить сервису специально подготовленный репозиторий и дождаться, пока сканер сам выполнит вредоносную логику или прочитает лишние данные.
Что именно нашли исследователи
Свои результаты команда ZeroPath представит на Black Hat USA 2026 в Лас-Вегасе. По данным компании, исследователи изучили 20 неназванных поставщиков средств безопасности и добились заметного эффекта в пяти случаях. За одну из находок им, как утверждает ZeroPath, выплатили максимальное вознаграждение по bug bounty.
Сооснователь и CTO ZeroPath Рафаэль Каргер говорит, что в отдельных сценариях команда получала доступ к чувствительным секретам: облачным учетным данным, токенам Docker, персональным токенам GitHub и, в одном случае, к рабочей базе данных поставщика. Если такая поверхность доступна через сервис, который регулярно сканирует клиентский код, проблема выходит далеко за пределы локального бага у конкретного вендора.
Почему сканер вообще исполняет чужой код
Здесь и кроется самая неприятная часть истории. Многие инженеры воспринимают анализ репозитория как почти безобидную процедуру чтения файлов. На практике AppSec-сканеры нередко идут дальше: разбирают зависимости, обрабатывают конфигурации, подгружают правила и в некоторых сценариях фактически исполняют недоверенное содержимое.
ZeroPath приводит простой пример: если инструмент умеет проверять облачные конфигурации и принимать пользовательские правила, атакующий может подложить не правило, а программу. Дальше все упирается в изоляцию. Если песочница настроена плохо или ее нет вовсе, сканер сам запускает код, который должен был проверить.
Откуда взялась идея для исследования
Поводом стал не внешний аудит, а странный след в инфраструктуре самой ZeroPath. В конце 2025 года команда заметила неудачный скан, который пытался прочитать файл за пределами текущего репозитория. По словам Каргера, такой запрос потенциально мог открыть доступ к чувствительным данным, включая учетные данные внутренних сенсоров.
Разбор артефактов навел исследователей на мысль, что кто-то системно прощупывал поверхность их хостируемого продукта: проверял работу с произвольными файлами, зависимостями и секретами. Иными словами, злоумышленники уже смотрят на AppSec-сканеры не как на защиту, а как на еще один исполняемый узел в чужой CI/CD-цепочке.
Почему это важно рынку
Этот сценарий опасен тем, что он дешевле классической supply chain-атаки на вендора. Не нужно перехватывать его CI, подменять официальный билд или пробиваться в релизный процесс. Иногда достаточно зарегистрироваться в сервисе, запустить сканирование и подсунуть системе репозиторий-приманку.
Для российских и СНГ-команд вывод практический: SaaS-сканеры стоит проверять так же жестко, как любой другой инструмент сборки. Нужны прямые вопросы про песочницы, изоляцию клиентов, обработку пользовательских правил, работу с зависимостями и хранение секретов. Логотипы крупных клиентов и громкий раунд инвестиций тут не спасают: если сканер видит ваш код, артефакты сборки и внутренние политики, он уже часть доверенной цепочки.
На Black Hat исследователи собираются открыть исходный код инструмента Build Canaries и опубликовать таксономию поверхностей исполнения при обработке репозиториев. Если материалы окажутся полезными, рынок AppSec, похоже, начнет чуть меньше говорить о покрытии кода и чуть больше — о том, что именно сканер делает с недоверенным содержимым.