29 октября из Binance, крупнейшей криптобиржи мира, вывели около $6,3 млрд. По первой версии самой биржи, всё началось со скомпрометированного ноутбука DevOps-инженера.

Через ноутбук атакующий добрался до service container и оттуда отправил транзакции на вывод. Ключи от кошельков не утекли: транзакции подписала сама система биржи, потому что запрос пришёл изнутри.

Криптовалюта здесь вторична. Мне интереснее другое: задачи по безопасности у нас месяцами лежат в бэклоге, а ноутбук инженера с доступом в прод остаётся самым удобным входом в компанию.

Почему это касается не только бирж

Цепочка «ноутбук инженера → контейнер в проде → действие, которое не откатить» есть почти в любой компании. Где-то это вывод денег, а где-то удаление базы, выгрузка клиентских данных или выпуск сертификата.

На ноутбуке DevOps обычно лежит kubeconfig от боевых кластеров, ключи облака, SSH-ключи и токены CI. Часто всё это статическое и живёт месяцами.

Когда инженер со своей машины ходит в прод, в логах это выглядит как обычная работа. Когда с той же машины ходит атакующий, в логах всё выглядит точно так же.

Binance не первый

Историй, где входом стала машина или креды инженера, за последние годы набралось достаточно. Три самых показательных:

Ни в одном из этих случаев не ломали периметр в классическом смысле. Атакующие заходили через инженера с доступами или через секрет, который лежал не там. А скрипт с паролем или токен в переменных CI — это как раз наша зона ответственности.

ИБ и DevOps: почему безопасность откладывают

У DevOps-команды метрики понятные: скорость релизов, аптайм, время восстановления. Задачи по безопасности в них не попадают. Пока ничего не случилось, ротация токенов или переход на короткоживущие креды выглядят как работа без результата. И месяцами лежат в бэклоге под задачами «бизнес ждёт».

ИБ при этом часто приходит в конце. Проект готов, и сверху ложится список требований. Для DevOps это блокер перед релизом, для ИБ — попытка протащить небезопасное решение. ИБ не всегда понимает, как устроены кластер и пайплайн, DevOps редко думает категориями модели угроз. В итоге каждая сторона считает, что за безопасность инфраструктуры отвечает другая.

По-моему, работает другой порядок. ИБ подключается на этапе проектирования и объясняет, какую угрозу закрывает каждое требование. DevOps считает доступы, секреты и права в кластере своей зоной ответственности. А время на безопасность закладывается в план заранее, отдельной строкой.

Если ждать свободного окна, его не будет.

ИИ: те же ошибки, только быстрее

С приходом ИИ появились новые способы слить секреты, и оба примера ниже про инженеров.

В 2023 году инженеры полупроводникового подразделения Samsung загрузили в ChatGPT исходный код и протоколы совещаний, решая рабочие задачи. После этого компания запретила генеративный ИИ на рабочих устройствах и во внутренней сети.

В августе 2025 года случилась атака s1ngularity. В npm опубликовали заражённые версии системы сборки Nx. Postinstall-скрипт искал на машине локальные AI-агенты (Claude Code, Gemini CLI, Amazon Q) и запускал их с флагами --dangerously-skip-permissions, --yolo и --trust-all-tools, то есть без подтверждений. Агент по промпту сам искал .env, SSH-ключи, токены GitHub и npm, а найденное уходило в публичные репозитории. Wiz насчитал там больше 1000 валидных токенов GitHub. Часть запусков произошла прямо в CI.

И ещё одна сторона. ИИ ускорил поиск уязвимостей. В октябре неопубликованная модель Claude написала эксплойт к уязвимости ядра Linux CVE-2026-98432, от первой утечки памяти до root прошло около 53 минут. Критические дыры в PHP PHP2Shell нашли с помощью GPT-5.6 Sol и Gemini, а Amazon видел попытки эксплуатации за четыре дня до публичного раскрытия. Время от дыры до рабочего эксплойта сокращается, и патчи раз в квартал уже не спасают.

Отказываться от ИИ из-за этого я не предлагаю. Но правила в команде нужны:

• В чат не уходит то, что нельзя показать постороннему: kubeconfig, .env, дампы базы. Логи перед отправкой чистятся от токенов и паролей.

• Инструменты согласованы с ИБ, и понятно, куда уходят данные.

• AI-агент с отключёнными подтверждениями работает в отдельном контейнере или виртуалке. На машине с продовыми кредами такого агента быть не должно.

• Сгенерированные манифесты, скрипты и пайплайны проходят ревью как чужой код. Особое внимание — секретам в открытом виде, privileged: true и слишком широким RBAC-ролям.

• Файлы инструкций для агентов в репозитории тоже код. В апреле 2026 года LayerX показала, что правкой CLAUDE.md можно убедить агента выполнить вредоносный код, поэтому такие правки тоже идут через ревью.

С чего начать, если времени мало

1. Найти статические креды к проду: токены в kubeconfig, ключи облака на ноутбуках, пароли в скриптах и репозиториях. Заменить на короткоживущие через SSO или OIDC.

2. Пересмотреть, у кого есть доступ в прод и exec в поды критичных сервисов. Оставить минимум.

3. Заложить в каждый спринт фиксированное время на задачи безопасности.

4. Договориться с ИБ о регулярной короткой встрече и о том, что новые проекты они видят на этапе дизайна.

5. Записать правила работы с ИИ: что можно отправлять, какие инструменты разрешены, где запускать агентов.

6. Тестовые задания от незнакомых работодателей и чужие репозитории запускать только в одноразовой виртуалке.

Источники

• Binance — Security Incident, Recovery Update #2 (X)

• The Hacker News — Binance Suffers Security Breach Affecting $6.3 Billion in Assets

• CircleCI — Incident report for January 4, 2023 security incident

• SecurityWeek — CircleCI Hacked via Malware on Employee Laptop

• GitGuardian — Uber breach 2022

• ZeroFox — Flash brief: Uber breach

• Wikipedia — 2022 LastPass data breach

• Asia News Network — Samsung bans AI chatbots after leak

• CyberInsider — Supply chain attack hits Nx npm package

• AI Incident Database — Malicious Nx npm packages weaponize AI coding agents

• BleepingComputer — Critical Linux kernel flaw allows remote root attacks on MPTCP servers

• Cyber Magazine — Critical PHP2Shell bugs

• Expert Insights — Researchers trick Claude Code into running offensive cyberattacks