Раньше подобные инциденты часто сводили к потере нескольких файлов и неприятному шуму вокруг компании. Теперь Grafana Labs прямо говорит о другом: атакующие добрались до ее GitHub-среды, а не до клиентской инфраструктуры, и унесли не только исходный код, но и часть внутренних репозиториев.

Что случилось

19 мая 2026 года Grafana Labs сообщила, что расследование недавнего инцидента не нашло признаков компрометации производственных систем клиентов или рабочих операций. Масштаб атаки, по словам компании, ограничился GitHub-окружением Grafana Labs.

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

Как это сработало

По версии Grafana Labs, атака пришла через TanStack npm supply chain attack — атаку на цепочку поставок пакетов в npm. Компания обнаружила активность 11 мая 2026 года, быстро начала менять токены GitHub workflow, но один пропущенный токен позволил злоумышленникам получить доступ к репозиториям.

Позже проверка показала, что один из workflow, который сначала сочли незатронутым, тоже оказался скомпрометирован. Это типичный риск для атак на разработческую инфраструктуру: злоумышленнику не нужно ломать сам продукт, если он уже вошел в контур сборки, хранилища кода или автоматизации.

Подобная схема хорошо знакома по другим инцидентам в экосистеме npm; о похожих цепочках поставки мы уже писали в материале Шай-Хулуд вернулся в npm: под ударом разработчики и секреты.

Почему это опасно

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

Это ускоряет следующие атаки. Злоумышленники могут искать слабые места в процессах, подделывать письма от коллег, точнее планировать фишинг и вымогательство. Grafana, к слову, отдельно сообщила, что 16 мая получила требование о выкупе, но платить не стала.

Отказ от выплаты логичен: никто не гарантирует удаление украденного массива данных. Напротив, выкуп нередко становится стартом для новых атак и перепродажи информации.

Как понять, касается ли это вас

Если вы пользуетесь продуктами Grafana, сам по себе этот инцидент не означает, что ваши рабочие данные уже утекли. Но он должен насторожить тех, кто хранит секреты рядом с кодом: токены, настройки CI/CD, внутренние адресные книги, списки подрядчиков, тестовые доступы.

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

Что делать компаниям и пользователям

Grafana Labs уже сообщила, что меняет automation tokens, усиливает мониторинг, проверяет все коммиты на признаки вредоносной активности и укрепляет GitHub security posture. Для обычных компаний вывод простой: репозитории нужно считать не складом кода, а критичной частью инфраструктуры.

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

Для диагностики похожих рисков пригодится и наша памятка Три уязвимости в Windows 11: чем опасны новые дыры для данных: там хорошо видно, как быстро техническая мелочь превращается в проблему для всей инфраструктуры.

Чек-лист

  • Проверьте, где у вас хранятся токены GitHub, npm и CI/CD.
  • Отзовите старые ключи и замените их на новые, если они живут дольше положенного.
  • Ограничьте доступ к внутренним репозиториям по принципу минимальных прав.
  • Включите аудит коммитов и оповещения о необычной активности.
  • Уберите из репозиториев пароли, секреты и служебные заметки.
  • Проверьте, как сотрудники подключаются к рабочим ресурсам из поездок и общих сетей.
  • Проведите короткий инструктаж по фишингу для разработчиков и админов.
  • Пересмотрите план реагирования на утечку: кто отзывает доступы, кто уведомляет команды и кто проверяет логи.
Поделиться: