Шкідливий код підписав Red Hat
Цього тижня код, що краде облікові дані, дістався до розробників під іменем Red Hat. Загроза прийшла не ззовні вашого кола довіри — вона прийшла зсередини. Відсіюванням тут не вибратися. Але ви можете тримати облікові дані поза досяжністю.
Цього тижня код, підписаний Red Hat, намагався викрасти ваші облікові дані.
Зловмисники зламали обліковий запис розробника Red Hat і опублікували модифіковані версії офіційних пакетів Red Hat. Щойно машина встановлювала один із них, прихований код запускався автоматично і хапав усе цінне, що міг знайти — ключі до хмари, токени доступу, облікові записи, будь-що, що відчиняє двері. Потім використовував викрадене, щоб поширюватися далі.
Зверніть увагу на форму цієї атаки. Red Hat не був ціллю — ціллю були ви. Їхнє ім'я, їхній довірений обліковий запис, процес встановлення, який ви використовували тисячу разів не замислюючись: усе це не постраждало. Усе це стало зброєю. Атака не пробралася повз ваше коло довіри. Вона увійшла через головні двері з посвідченням, яке ви самі й видали. Саме тому атаки на ланцюг постачання відрізняються від усього іншого — небезпека тут не в незнайомці, якого можна заблокувати, а у вендорі, якому ви вже вирішили довіряти, що доставляє шкідливе навантаження за вас. І це був саме Red Hat: одна з найзріліших у питаннях безпеки компаній у світі, зі справжнім рев'ю та справжнім бюджетом. Поганий код усе одно вийшов під їхнім ім'ям.
Тож ось висновок, якого не уникнути: якщо Red Hat не може гарантувати, що встановлене з їхніх пакетів чисте, ніхто не може. Ні ваш фреймворк, ні ваш CI-вендор, ні залежність на три рівні нижче, яку ви ніколи не читали. Рано чи пізно ви запустите код, якого не писали і не могли перевірити повністю. Це не збій процесу — це і є суть розробки на чужому програмному забезпеченні.
Продовжуйте сканувати. Продовжуйте фіксувати версії. Продовжуйте перевіряти. Усе це варто робити — тільки не покладайтеся на це, бо цього тижня нічого з цього не допомогло б: шкідливий код прийшов уже попередньо перевіреним. Справжнє питання не в тому, як не впустити поганий код. Воно таке: коли поганий код запускається на вашій машині, чи захищені ваші секрети?
Для майже всіх чесна відповідь — ні. Подивіться, що вихопила ця атака — змінні середовища, токени, що лежали у файлах, а потім вона підійшла до менеджерів секретів у хмарі й попросила їх віддати вміст. Так облікові дані живуть у 2026 році: звалені в одному місці, в межах досяжності будь-чого, що випадково виконується. Одне невдале встановлення забирає не один секрет. Воно забирає всі, а потім поширюється.
Рішення — перестати зберігати облікові дані там, де ваш код може їх схопити. Тримайте їх на відстані витягнутої руки.
У цьому вся ідея роботи Clavitor. Ваші секрети не живуть у вашому середовищі; нічого не чекає у файлі .env, щоб його прочитали. Програма — або AI-агент — ніколи не тримає сам обліковий запис. Вона отримує можливість ним скористатися, підтягуючи його свіжим у ту мить, коли він потрібен — ніколи не зберігаючи, ніколи не кешуючи — з одного з наших 21 розташувань на шести континентах, тож найближча копія завжди за мілісекунди, з доступом лише до того секрета, на який видано дозвіл, і з журналом кожного звернення. Коли шкідливий інсталяційний скрипт мацає в пошуках ключів, він знаходить порожню кімнату.
І ми виходимо з того, що обліковий запис зрештою можуть перехопити, тому те, що несе аген, майже марне у разі викрадення. Він працює лише з тієї машини, для якої був виданий — вкрадіть його й запустіть з власних серверів зловмисника, і йому буде відмовлено. Він обмежений за частотою і перебуває під наглядом: кілька секретів на хвилину, тож він не може висмоктати весь ваш сховище, а щойно простягається далі за свою звичну жменю — спрацьовує тривога і блокування. Уся стратегія хробака — схопити все швидко, використати скрізь — наштовхується на стіну.
Жодних обіцянок імунітету: якщо обліковий запис активно використовується в ту мить, коли запускається шкідливий код, його можуть перехопити — жодна архітектура не переписує фізику. Але в цьому й суть. Атака Red Hat була руйнівною саме тому, що одне встановлення могло спорожнити ціле сховище секретів і перетворити його на зброю. Тримання на відстані плюс обліковий запис, прив'язаний до однієї машини й обмежений до струмка, перетворює «вони забрали все і поширилися» на «вони, можливо, перехопили один ключ на льоту, і він не спрацював ніде більше». Це і є відстань між катастрофою і виноскою.
Шкідливий код підписав Red Hat. Ви цього не перевірите. Припустіть, що код потрапить усередину — і переконайтеся, що коли це станеться, ваші секрети не чекатимуть на нього.
(Публічно відстежується як «Miasma», варіант родини саморозповсюджувальних npm-хробаків Shai-Hulud. Технічні огляди варті вашого часу; цей допис — про ту частину, яка не змінюється від одного до іншого.)
Джерела: