xAI випустила вихідний код свого інструменту Grok Build 15 липня 2026 року, лише через два дні після того, як дослідники довели, що програмне забезпечення непомітно завантажувало цілі git-репозиторії, домашні каталоги та секретні файли до Google Cloud Storage.
Інцидент, що спровокував реліз
13 липня дослідник із безпеки показав, що Grok Build ігнорував заявлені засоби контролю конфіденційності. Коли користувач перемикав тумблер «зупинити завантаження» (stop uploads), інструмент продовжував передавати дані в хмарне сховище. Під час завантаження витягувалися всі файли в робочій директорії, а в одному з випадків було викрадено весь домашній каталог, що призвело до витоку SSH-ключів та баз паролів.
xAI приховала серверний прапорець (flag) за чекбоксом користувача. Через два дні компанія оголосила, що Grok Build стає програмним забезпеченням із відкритим вихідним кодом під ліцензією Apache 2.0, представивши цей крок як спосіб розширити доступ для розробників.
Що все ще містить репозиторій
Швидкий огляд нового репозиторію показує, що процедура викрадення даних (exfiltration routine) все ще на місці. Вона знаходиться всередині умови, яка перевіряє прихований прапорець — він все ще присутній, просто вимкнений. Код також містить блоки, скопійовані з OpenAI та OpenCode без зазначення авторства, і вбудовані інструкції для суб-агентів щодо приховування своєї присутності — цей метод ускладнює криміналістичний аналіз.
Чому наявність залишків коду є важливою
Розробники, які зараз впроваджують Grok Build, змушені довіряти xAI, сподіваючись, що єдиний прапорець залишатиметься в правильному стані з кожним патчем. Ця довіра є крихкою з трьох причин:
- Прихований шлях керування – Прапорець знаходиться на стороні сервера і невидимий для кінцевих користувачів. Неправильне налаштування або зловмисні дії інсайдера можуть змінити його без будь-якого аудиторського сліду.
- Повторне використання коду без зазначення авторства – Невизначене походження ліцензії може наражати користувачів на юридичні ризики, якщо запозичений код має несумісні умови.
- Інструкції з обфускації – Вбудовані механізми приховування ускладнюють інструментам безпеки виявлення шкідливої активності, яку може спровокувати інструмент.
Статус open-source не означає автоматичного перегляду спільнотою. Репозиторій xAI не приймає зовнішні pull requests, тому кодова база розвиватиметься в замкненому циклі, попри те, що вона є публічно доступною для читання.
Як Grok Build виглядає на фоні альтернатив
| Інструмент | Ліцензія | Внесок спільноти | Залежність від постачальника |
|---|---|---|---|
| Grok Build | Apache 2.0 | Ні (xAI блокує PR) | Низька (підтримує кілька моделей) |
| Codex CLI | Apache 2.0 | Ні (прив'язаний до OpenAI) | Висока (тільки OpenAI) |
| OpenCode | MIT | Так (приймає роботу спільноти) | Низька (багато постачальників) |
| Claude Code | Proprietary | Ні | Висока (тільки Claude) |
Єдина очевидна перевага Grok Build — це можливість вказувати на локальні моделі або інших постачальників, що зменшує залежність від одного провайдера. Усі інші аспекти — відкритість ліцензії, модель внесків та походження коду — є або на рівні, або гіршими за існуючі варіанти.
Що розробникам варто зробити прямо зараз
- Провести аудит шляху завантаження – Перевірте мережевий код репозиторію та переконайтеся, що не залишилося жодних вихідних з'єднань з невідомими кінцевими точками.
- Оновити секрети – Перегенеруйте всі SSH-ключі, API-токени або сховища паролів, які знаходилися поруч із Grok Build до 13 липня.
- Запускати в ізоляції – Розгортайте інструмент у пісочниці (sandbox) або контейнері, який не має доступу до привілейованих файлів або облікових даних.
- Моніторити стан прапорця – Якщо ви хостите власну інстанцію, перевіряйте, чи залишається прихований прапорець вимкненим після кожного оновлення.
Ці кроки не усувають ризик майбутніх змін з боку xAI, але вони знижують імовірність того, що існуюча логіка викрадення даних знову з'явиться непомітно.
Підсумок
Переведення Grok Build у формат open-source після скандалу з викраденням даних не усуває основну вразливість. Репозиторій усе ще містить приховану процедуру завантаження, а єдиним засобом захисту є прапорець, який контролюється компанією. Доки код не буде очищено від цієї логіки або поки стан прапорця не стане доступним для аудиту, розробникам слід ставитися до Grok Build як до компонента високого ризику та обмежувати його використання середовищами, що не містять конфіденційних даних.