Після npm install запустився ШІ-інструмент: чи бачив він секрети?

Збірку полагодили, але з’явився інший ризик

Збірка не проходила, тож хтось повторив npm install на робочому ноутбуці або постійному сервері автоматичної збірки (CI). Залежності встановилися, але журнал чи дерево процесів показали неочікуваний запуск AI CLI — ШІ-інструмента, яким керують командами в терміналі. Тепер команда не знає, чи міг він читати домашній каталог, .env, SSH-ключі або токени реєстру пакетів.

Правильна перша реакція — не паніка й не пошук винного. Потрібно обмежити подальший ризик, зберегти доступні сліди та визначити фактичну межу доступу. Сам запуск AI CLI не доводить ані читання секретів, ані передавання даних назовні.

Як виглядає небезпечний ланцюжок

Йдеться не про вигаданий приклад. 26 серпня 2025 року в npm опублікували шкідливі версії пакета Nx. Атака, відома як s1ngularity, використовувала postinstall — сценарій, який менеджер пакетів автоматично запускає після встановлення.

Шкідливий сценарій шукав уже встановлений AI CLI та запускав його в режимі обходу підтверджень, тобто без звичайного запиту до людини перед дією. Описаний у джерелі код працював на macOS і Linux та завершувався без виконання у Windows. Наведений далі план реагування корисний і для інших подібних випадків, але цю межу конкретної атаки важливо не втрачати.

Описаний джерелом ланцюжок має такий вигляд:

1. Менеджер пакетів запускає сценарій скомпрометованого пакета.
2. Скрипт шукає доступний AI CLI.
3. CLI запускається в контексті того самого користувача або середовища.
4. Інструмент може шукати й описувати файли, доступні цьому контексту, зокрема потенційні секрети.
5. Окремий шкідливий компонент може спробувати передати знайдені дані назовні.

Ефективний доступ не завжди тотожний усім правам користувача. Його також обмежують дозволи файлової системи, захист сховищ облікових даних, монтування, контейнер або віртуальна машина та мережеві правила.

Останні два кроки не слід змішувати. Виявлення назви файлу, читання його вмісту та передавання даних — різні події, для яких потрібні різні докази. Неочікуваний процес підтверджує запуск, але не доводить, що весь описаний ланцюжок відбувся.

Перші дії: обмежити, зберегти, оцінити

Нижче — базовий план реагування, а не готовий висновок про конкретний інцидент. Якщо процес ще працює, дотримуйтеся чинної процедури команди. За можливості ізолюйте підозрілий комп’ютер або сервер збірки від зовнішньої мережі погодженим способом. Не видаляйте дані до збереження потрібних слідів.

Зафіксуйте:

• відомий час і команду встановлення та обліковий запис, який її запустив;
• версії Node.js, npm і підозрілого пакета;
• копію package-lock.json або іншого файла зафіксованих версій і зміну дерева залежностей;
• батьківські й дочірні процеси та аргументи їх запуску;
• журнали npm, оболонки, системи захисту пристроїв (EDR), DNS, проксі та CI;
• зміни файлів і вихідні мережеві з’єднання у відповідний проміжок часу.

Відсутність запису в журналі не завжди означає відсутність дії: потрібні дані могли не збиратися або вже бути недоступними. Позначайте такі місця як невідомі, а не як підтверджено безпечні.

Потім складіть карту фактичного доступу. Перевірте .env, змінні середовища, налаштування хмарних інструментів, SSH-каталог, активний SSH-агент, конфігурацію Git, токени реєстрів пакетів, ключі підпису та секрети CI. SSH-агент — це служба, яка використовує завантажені ключі без зберігання їх відкритого вмісту в кожному процесі.

Не копіюйте секретні значення у квитки чи чати. Для кожного секрету зафіксуйте тип, власника, місце, строк дії, рівень прав і замаскований ідентифікатор. Розділіть результати на три групи:

• читання або передавання підтверджено доказами;
• доступ був технічно можливий, але телеметрії недостатньо;
• доступ був заблокований перевіреним контролем.

Підтверджено прочитані або передані облікові дані потрібно відкликати чи замінити. Така заміна — це ротація секретів. Потенційно доступні секрети оцінюйте за процедурою реагування команди. Пріоритет мають довгострокові облікові дані з широкими правами або доступом до виробничих систем. Заміну виконуйте з відомого чистого середовища, а не з підозрілого комп’ютера.

Дії залежать від місця запуску

Робоча станція

Почніть з прав облікового запису розробника, але врахуйте додатковий захист ОС, шифрування та запити на доступ. Перевірте домашній каталог, активні сесії хмарних CLI, SSH-агент і локальні сховища облікових даних. Не повертайте ноутбук до звичайної роботи, доки не оцінено докази й не виконано потрібне відкликання.

Постійний сервер збірки

Постійний сервер CI зберігає файли та стан між завданнями. Перевірте не лише поточну збірку, а й кеші, робочі каталоги попередніх завдань і налаштування машини. Виведіть підозрілий сервер із пулу до завершення перевірки, якщо це передбачає процедура команди.

Одноразовий сервер збірки

Одноразовий сервер CI створюють для окремого завдання, а потім знищують. Це зменшує залишковий ризик, але не скасовує доступ, який існував під час роботи. Перевірте журнали керування, мережеві записи та облікові дані, видані саме цьому запуску.

Захист має складатися з кількох шарів

Один перемикач або продукт не закриє весь сценарій. Поєднайте такі заходи:

• фіксуйте дозволені версії залежностей і перевіряйте неочікувані зміни package-lock.json чи його аналога;
• перевіряйте походження пакета, якщо реєстр і процес команди надають такі дані;
• обмежуйте автоматичні сценарії пакетів і погоджуйте винятки лише для перевірених залежностей;
• запускайте встановлення та ШІ-інструменти в ізольованому середовищі без доступу до домашнього каталогу розробника;
• використовуйте окремі облікові записи з мінімально потрібними правами;
• видавайте CI короткоживучі токени лише на час конкретного завдання;
• обмежуйте вихідну мережу там, де це сумісно зі збіркою;
• не вважайте запит підтвердження межею безпеки.

Контейнер сам по собі не гарантує ізоляції. Межу визначають змонтовані каталоги, обліковий запис процесу, дозволи та мережеві правила. Проблема також не в самому використанні ШІ: ризик виникає, коли неперевірений код може запустити потужний інструмент із надмірним доступом.

Перевірте захист без справжніх секретів

Створіть окреме невиробниче середовище з порожнім тимчасовим домашнім каталогом і унікальним несправжнім маркером замість токена. Не встановлюйте підозрілий пакет і не копіюйте виробничі конфігурації. Використайте дозволений командою нешкідливий тестовий процес із такими самими запланованими файловими та мережевими обмеженнями.

Якщо потрібно перевірити мережевий контроль, надсилайте тестовий запит лише на контрольовану адресу, якою володіє команда. Не використовуйте довільні зовнішні сервіси.

Успішний результат має показати, що:

• маркер поза дозволеним робочим каталогом недоступний;
• процес не має необмеженого виходу в зовнішню мережу;
• спроби забороненого доступу потрапляють у потрібні журнали.

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

Невдалі підходи

Не видаляйте одразу node_modules, бо це може знищити корисні сліди. Не обмежуйтеся перевстановленням пакета або відкликанням одного очевидного токена. Не вважайте знищення одноразового сервера CI доказом відсутності доступу під час завдання.

Так само не робіть висновок про викрадення лише через запуск AI CLI. Не вважайте контейнер безпечним, не перевіривши підключені каталоги, обліковий запис процесу та мережеві правила. Підтверджені факти, припущення та невідомі обставини мають залишатися окремими категоріями.

Висновок

Ключове запитання — не чи використовував процес ШІ, а які права йому фактично були доступні. Спочатку обмежте подальший ризик і збережіть докази. Потім визначте доступні секрети, відкличте підтверджено або обґрунтовано скомпрометовані облікові дані та приберіть саму можливість доступу за допомогою ізоляції, мінімальних прав і короткоживучих токенів.

Джерела

• Docker: Coding Agent Horror Stories: The 29 Million Secret Problem