Любой пользователь GitHub мог запустить уязвимый процесс
ИИ-агент, ищущий уязвимости, обнаружил ошибку в публичном репозитории Snowflake, которую не заметил GitHub Copilot. Любой пользователь GitHub мог запустить уязвимый процесс, создав новую заявку с подготовленным заголовком. Эксперт «Группы Астра» Эдуард Тихомиров считает, что этот случай подсветил важную проблему: разработчики начинают слишком сильно доверять ИИ-ассистентам.
Специалисты Wiz обнаружили проблему с помощью автономного инструмента Red Agent, который проверял репозитории Snowflake на GitHub. Ошибка находилась в сценарии GitHub Actions проекта snowflakedb/snowflake-connector-net.
Особое внимание Wiz обратила на роль GitHub Copilot. Итоговая запись об изменении указывает «Copilot Autofix powered by AI» как соавтора, а когда Copilot проверял изменения, он счёл их безопасными и не обнаружил критическую ошибку. При этом Wiz уточняет, что нельзя достоверно утверждать, будто сам уязвимый фрагмент написал искусственный интеллект, сообщает Securitylab.
Дополнительная защита, которая должна была не позволять сценарию запускаться без ограничений, тоже не сработала. Когда пользователь создавал обычную заявку, одно из проверяемых полей всегда оставалось пустым, поэтому условие автоматически выполнялось для любого пользователя GitHub. В результате защитный барьер фактически никого не останавливал.
Компания исправила сценарий в тот же день, вернув прежний безопасный способ обрабатывать данные, а позже заменила ключ Jira. Когда специалисты проверили журналы, выяснилось, что за пять дней, пока уязвимость существовала, посторонние не воспользовались ею.
Эдуард Тихомиров, руководитель разработки GitFlic (входит в «Группу Астра») уверен, что недавний инцидент с компанией Snowflake, когда один ИИ (GitHub Copilot) пропустил критическую уязвимость в коде, а другой (Red Agent) успешно её проэксплуатировал за несколько секунд, — это классический пример того, как уязвимости в CI/CD пайплайнах могут открыть доступ к внутренним корпоративным ресурсам (в данном случае — к Jira).
«Как эксперты отечественной платформы GitFlic, мы внимательно изучили этот кейс. Если разобрать механику атаки, становится очевидно: в инфраструктуре GitFlic подобный взлом был бы невозможен архитектурно. Почему это не сработало бы в GitFlic?
Главная проблема в сценарии Snowflake заключалась в том, что триггер GitHub Actions сработал от действий внешнего пользователя — ему было достаточно просто создать заявку (issue) со спецсимволом в заголовке, чтобы запустить выполнение кода на сервере. В GitFlic реализована принципиально иная модель безопасности: запуск CI строго ограничен только доверенными участниками проекта. Случайный пользователь из интернета не может инициировать пайплайн и заставить сервер выполнять свои команды, какими бы хитрыми ни были заголовки его заявок. Наша ролевая модель изначально отсекает этот вектор атаки.
Этот случай также подсветил важную проблему: разработчики начинают слишком сильно доверять ИИ-ассистентам. Copilot пометил опасный код с явной shell-инъекцией как безопасный. Это доказывает, что нейросети всё ещё не заменяют классические инструменты информационной безопасности.
Чтобы не повторить судьбу Snowflake, компаниям необходимо внедрять эшелонированную защиту (DevSecOps): Обязательное использование SAST и DAST. Статический (SAST) и динамический (DAST) анализ кода должен работать в пайплайне по умолчанию. Классический анализатор почти наверняка подсветил бы прямую передачу переменной в оболочку скрипта без экранирования, даже если ИИ этого не заметил», — говорит эксперт Эдуард Тихомиров.
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
|
Любой пользователь GitHub мог запустить уязвимый процесс
