Что, по версии Grafana, произошло#
Grafana Labs заявила, что несанкционированный доступ к ее GitHub-репозиториям, о котором стало известно в начале мая, был связан с атакой на цепочку поставок TanStack. По словам компании, злоумышленники скачали ее кодовую базу и получили доступ к репозиториям с внутренней операционной и деловой информацией.
Граница инцидента, как ее описывает Grafana, тоже важна: компания утверждает, что продакшен-системы клиентов и платформа Grafana Cloud не пострадали. Она также говорит, что скачанный код не меняли, а клиентам и пользователям open source на текущий момент не нужно ничего предпринимать из-за этого инцидента.
Это различие принципиально. Речь все равно идет о серьезной утечке исходного кода и внутренних данных. Но, по версии компании, это не был компромисс продакшен-платформы.
SecurityWeek пишет, что Grafana связала доступ к GitHub-репозиториям с атакой на цепочку поставок TanStack — кампанией, которая затронула заметные проекты NPM и PyPI и распространяла самораспространяющееся вредоносное ПО для кражи информации с компьютеров жертв.
Grafana обнаружила вредоносную активность, связанную с этой атакой, 11 мая и сразу ротировала GitHub workflow tokens. Но это не закрыло окно полностью. Один токен не был отозван.
Именно этот пропущенный токен стал точкой входа.
Позже Grafana пересмотрела инцидент и выяснила, что GitHub workflow, который изначально сочли не затронутым, на самом деле был скомпрометирован. Компания сформулировала это так: “A subsequent review confirmed that a specific GitHub workflow we originally deemed not impacted had, in fact, been compromised.”
16 мая Grafana получила требование выкупа от злоумышленников. Компания заявила, что отказалась платить, начала дополнительные меры по снижению риска, усилила защиту GitHub и уведомила правоохранительные органы.
Какие данные оказались доступны злоумышленникам#
Grafana говорит, что текущий масштаб инцидента ограничен GitHub-репозиториями Grafana Labs. Сюда входят публичный и приватный исходный код, а также внутренние GitHub-репозитории.
Злоумышленники скачали кодовую базу Grafana. Они также получили доступ к репозиториям, где хранилась внутренняя операционная информация и другие деловые сведения.
По словам Grafana, среди раскрытых бизнес-данных были имена контактных лиц и адреса электронной почты, которыми обычно обмениваются в профессиональном взаимодействии. Компания подчеркнула, что эта информация не была взята из продакшен-систем и не обрабатывалась через них или через Grafana Cloud.
Это важная техническая и юридическая граница. Репозитории с исходным кодом часто содержат не только код. Там могут быть история задач, конфигурации workflow, внутренние заметки, логика сборки, черновики документации, операционные ссылки и деловые метаданные. Даже если продакшен-среда не затронута, доступ к репозиториям создает последующие риски.
Украденный код и внутренний контекст могут пригодиться злоумышленникам для разных целей:
- изучить архитектуру и заложенные предположения о безопасности;
- искать секреты или слабые шаблоны workflow;
- готовить более убедительный фишинг или вымогательство;
- находить проблемы, которые еще не стали публичными;
- картировать мейнтейнеров, поставщиков и партнерские связи.
На основе предоставленного источника Grafana не утверждала, что злоумышленники нашли пригодные для эксплуатации уязвимости, украли клиентские данные, изменили код или получили доступ к продакшен-системам. Такие выводы нельзя делать только из факта скачивания репозиториев.
Что, по словам Grafana, не пострадало#
Grafana утверждает, что ее продакшен-системы не были затронуты. То же самое компания говорит о платформе Grafana Cloud.
Компания также заявила, что скачанную кодовую базу не меняли. Для пользователей open source и клиентов это критически важный пункт: изменение кода означало бы другой тип риска для цепочки поставок — возможное внедрение вредоносного кода в релизы, зависимости или пути сборки.
По данным Grafana, клиентам и пользователям open source сейчас не нужно предпринимать никаких действий.
Это не делает инцидент безвредным. Это означает, что известное воздействие, как его описывает Grafana, находится на уровне репозиториев и внутренней информации, а не на уровне продакшен-сервисов.
Для пользователей разница практическая. Если продакшен-системы и релизные артефакты не затронуты, немедленная реакция обычно сводится к мониторингу и вниманию к обновлениям, а не к срочному повторному развертыванию. Если оценка изменится, должна измениться и реакция.
Почему один токен может решить исход инцидента#
Главный урок здесь не в формуле «Grafana взломали». Он уже и практичнее: один неотозванный workflow token может сохранить злоумышленнику доступ после того, как большая зачистка выглядит завершенной.
GitHub workflow tokens и CI/CD-учетные данные находятся рядом с процессом сборки и релиза. Часто у них достаточно прав, чтобы читать репозитории, запускать автоматизацию, получать доступ к артефактам или взаимодействовать с внутренними системами. Их реальная сила зависит от конфигурации, области действия и окружающих контролей.
При инцидентах в цепочке поставок ротация токенов — стандартная мера. Сложнее другое: инвентаризация. Командам нужно понимать, какие workflow существуют, какие токены они используют, к чему эти токены имеют доступ, где хранятся секреты и какие задания могли выполняться в условиях компрометации.
Заявление Grafana показывает типичный сценарий сбоя. После обнаружения вредоносной активности компания ротировала GitHub workflow tokens, но один workflow сначала сочли не затронутым. Позже эта оценка изменилась.
Это неприятная часть реагирования на атаки цепочки поставок: первичное определение масштаба часто оказывается неверным. Не всегда из-за халатности. Просто системы сборки большие, старые workflow продолжают жить, права со временем расползаются, а автоматизация создает скрытые цепочки доверия.
Что командам стоит проверить сейчас#
Организации, которые используют GitHub Actions, реестры пакетов или похожие CI/CD-конвейеры, могут воспринимать этот случай как повод пройтись по чек-листу.
Начните с инвентаризации workflow. Найдите все активные и спящие workflow. Неиспользуемая автоматизация все равно может сохранять права или секреты.
Проверьте область действия токенов. Широкие права по умолчанию удобны ровно до инцидента. По возможности используйте минимально необходимые привилегии. Права на чтение, запись, публикацию пакетов и деплой в окружения не должны объединяться без необходимости.
Ротируйте секреты после подтвержденной или предполагаемой компрометации машины разработчика. Вредоносное ПО в цепочке поставок, которое крадет локальные учетные данные, быстро переводит инцидент с конечной точки на уровень репозиториев.
Проверьте историю запусков workflow. Ищите необычные запуски, неожиданные ветки, новые артефакты, упавшие задания со странными параметрами и изменения в файлах workflow.
Разделяйте утечку исходного кода и компрометацию релизов. Важно и то и другое, но реакции разные. Скачанный код — не то же самое, что измененный код. Измененные пути релиза намного срочнее для downstream-пользователей.
По возможности сохраняйте доказательства до зачистки. Быстрая ротация помогает ограничить ущерб. Но расследованию нужны логи, метаданные запусков, записи доступа и следы артефактов.
Чего не стоит утверждать без оснований#
Исходный материал не доказывает, что Grafana Cloud была взломана. Он не доказывает, что злоумышленники получили доступ к клиентским продакшен-данным. Он не доказывает, что вредоносный код был внедрен в кодовую базу Grafana или релизы. Также в нем нет технических индикаторов, названий пакетов, личности атакующих или полной хронологии за пределами опубликованных дат.
Подтвержденное утверждение все равно серьезное: Grafana связывает доступ к репозиториям с атакой на цепочку поставок TanStack, говорит, что один GitHub workflow token не был отозван, и сообщает, что злоумышленники скачали код и получили доступ к внутренним данным репозиториев перед требованием выкупа.
Этого достаточно, чтобы отнестись к случаю серьезно. Он показывает, как компрометация экосистемы пакетов может превратиться в компрометацию репозиториев через учетные данные разработчиков и workflow. Он также показывает, почему при реагировании на инцидент состояние CI/CD нужно считать частью зоны поражения, а не фоновой инфраструктурой.
Для пользователей Grafana практический вывод сейчас сдержанный: следить за обновлениями, но не считать продакшен скомпрометированным, пока Grafana не сообщит о новых фактах. Для команд безопасности урок прямее. В атаке на цепочку поставок пропущенный токен может оказаться тем инцидентом, который все еще продолжается.