Собирать должно быть нечего

Вчера скомпрометированная версия CLI Bitwarden собрала SSH-ключи, учётные данные AWS, npm-токены, переменные окружения, историю оболочки и Git-секреты с 334 машин разработчиков.

Сегодня это был Bitwarden. В прошлом месяце — Axios. До этого — Checkmarx. Завтра это будет расширение для VS Code, или Acrobat, или формула Homebrew, или образ Docker. Вектор меняется еженедельно. Результат всегда один и тот же.

Вредоносное ПО попадает на машину. Оно читает ~/.ssh/. Оно читает ~/.aws/credentials. Оно читает ~/.npmrc. Оно читает ~/.git-credentials. Оно читает историю оболочки, переменные окружения, хранилища паролей браузера. Упаковывает всё и отправляет на C2-сервер.

И это работает. Каждый раз.

Сбор урожая

Полезная нагрузка Bitwarden — обфусцированный файл размером 10 МБ под названием bw1.js — не пыталась взломать шифрование. Это не требовалось. Вот что было собрано, как задокументировано Socket и Aikido:

• SSH-ключи и отпечатки хостов
• Облачные учётные данные AWS, GCP и Azure
• Токены аутентификации npm
• Учётные данные Git и адреса удалённых репозиториев
• Переменные окружения
• История оболочки
• Аутентификация Claude Code и конфигурации MCP

Затем с помощью украденных npm-токенов были повторно опубликованы другие пакеты, которые поддерживала жертва, — и вредоносное ПО распространилось дальше. Жертвы стали векторами.

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

Это не история про Bitwarden

Шифрование хранилища Bitwarden не было взломано. Их архитектура с нулевым знанием устояла. Вредоносное ПО никогда не касалось хранилища.

И не должно было.

Хранилище защищает то, что находится внутри него. Но SSH-ключи никогда не были в хранилище. Учётные данные AWS никогда не были в хранилище. npm-токены, учётные данные Git, API-ключи в файлах .env — ничто из этого не хранится в менеджерах паролей. Всё это живёт в dotfiles, в открытом виде, на каждой машине разработчика.

Атакующий это понимал. Хранилище — это запертый сейф в доме, где каждый ящик открыт.

Настоящая поверхность атаки

Откройте терминал прямо сейчас. Посмотрите, что есть на вашей машине.

~/.ssh/id_ed25519 — ваш закрытый ключ. Файл в открытом виде.

~/.aws/credentials — ваш доступ в облако. Файл в открытом виде.

~/.npmrc — ваш токен публикации. Файл в открытом виде.

~/.git-credentials — ваш доступ к репозиториям. Файл в открытом виде.

~/.env в десятке каталогов проектов — API-ключи, пароли к базам данных, секреты подписи. Все файлы в открытом виде.

Любой процесс, запущенный от вашего имени, может прочитать всё это. Повышение привилегий не требуется. Уязвимость не нужна. Достаточно cat.

Это стандартная настройка разработчика в 2026 году. Мы кладём пароли в зашифрованное хранилище и оставляем всё остальное открытым.

Неправильный вопрос

После каждой атаки на цепочку поставок отрасль задаёт один и тот же вопрос: как не допустить проникновения вредоносного ПО?

Более надёжная безопасность CI/CD. Подписание кода. Сканирование зависимостей. Песочницы для среды выполнения. Всё это хорошо. Ничего из этого недостаточно. Поверхность атаки слишком широка. Слишком много векторов — менеджеры пакетов, расширения браузеров, плагины IDE, OAuth-приложения, скомпрометированные инструменты сборки. Закрыть каждую точку входа невозможно.

Правильный вопрос: когда вредоносное ПО неизбежно получит выполнение на машине разработчика, что оно там найдёт?

Если ответ — «сотни учётных данных в открытом виде в предсказуемых местах файловой системы», никакое укрепление цепочки поставок не имеет значения. Вы обороняетесь на поле, где ваши ворота открыты.

Собирать должно быть нечего

Решение — не в лучшем обнаружении вредоносного ПО. Решение — не в песочнице для npm install. Решение — не в более быстром времени реагирования на инцидент.

Решение в том, что секреты не должны существовать как файлы на диске.

SSH-ключи, выводимые из аппаратного обеспечения в момент аутентификации, — а не хранимые в ~/.ssh/. Облачные учётные данные, выпускаемые на сессию из аппаратно-привязанной идентичности, — а не записываемые в ~/.aws/. API-токены с ограниченной областью действия, эфемерные и управляемые аппаратно, — а не лежащие в файлах .env.

Когда учётные данные существуют только внутри аппаратного модуля безопасности и во временной памяти процесса во время использования, вредоносному ПО нечего читать. Нет файла для экзистильтрации. Нет dotfile для сбора. Процесс запускается, ничего не находит и идёт дальше.

Это не теория. Аппаратно-привязанные учётные данные существуют уже сегодня. WebAuthn PRF позволяет выводить криптографические ключи из физического аутентификатора — ключи, которые никогда не попадают в файловую систему. Технология уже здесь. Отрасль просто не сделала её значением по умолчанию.

Что делать сейчас

Если Вы пострадали от компрометации CLI Bitwarden:

• Ротируйте все учётные данные на машине — SSH-ключи, облачные токены, npm-токены, API-ключи, всё в dotfiles и переменных окружения
• Проверьте, не были ли повторно опубликованы npm-пакеты, которые Вы поддерживаете
• Проверьте активность GitHub и рабочие процессы CI/CD на предмет несанкционированных изменений

Если Вы не пострадали, действия те же. Посмотрите на свою машину. Посчитайте секреты в открытом виде. Спросите себя, что произойдёт, когда — не «если», а когда — что-то вредоносное запустится от вашего имени.

Ответ должен быть: ничего. Собирать должно быть нечего.