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

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

Что известно об атаке на Trellix

Компания сообщила об инциденте в заявлении от 1 мая. По словам Trellix, специалисты выявили несанкционированный доступ к части репозитория исходного кода и привлекли внешних экспертов по цифровой криминалистике.

Trellix также уведомила правоохранительные органы. Компания отдельно подчеркнула: на текущем этапе расследования она не нашла признаков того, что злоумышленники повлияли на выпуск или распространение исходного кода. Доказательств использования кода в атаках Trellix тоже не обнаружила.

Позже RansomHouse опубликовала на своём сайте утечек небольшой набор изображений. На них, по данным BleepingComputer, видны признаки доступа к системе управления аппаратными решениями Trellix. Издание не смогло подтвердить подлинность этих материалов.

После публикации заявления RansomHouse Trellix сообщила BleepingComputer, что знает о претензиях группировки и проверяет их. Новых технических деталей компания пока не раскрыла.

Почему репозиторий исходного кода — чувствительная цель

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

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

Самый тревожный сценарий — вмешательство в сборку или распространение продукта, когда вредоносные изменения попадают к клиентам под видом легитимного обновления. Trellix заявляет, что признаков такого сценария не нашла. Это важная деталь, но расследование ещё идёт.

Похожий риск возникает и у компаний, которые не пишут защитное ПО, но активно используют open source и внешние пакеты. Мы уже разбирали, как фальшивый репозиторий OpenAI на Hugging Face раздавал стилер: в таких атаках доверие к названию и площадке работает против пользователя.

Что утверждает RansomHouse

По версии RansomHouse, проникновение произошло 17 апреля и закончилось шифрованием данных. Независимого подтверждения этому нет. Trellix публично не подтвердила шифрование и не раскрыла, какие именно системы затронула атака.

RansomHouse работает с 2022 года как группа вымогателей, которая давит на жертв публикацией или продажей украденных данных. Со временем, по данным исследователей, она добавила в арсенал более сложные инструменты шифрования, включая утилиты для массового развёртывания на корпоративной инфраструктуре.

Один из заметных эпизодов, связанных с RansomHouse, — атака на японскую e-commerce-компанию Askul Corporation. Группировка заявляла о краже 740 тыс. клиентских записей и других чувствительных материалов.

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

Чем это важно для клиентов и партнёров

Trellix сообщала, что в 2025 году у неё было более 53 тыс. клиентов в 185 странах и 3,5 тыс. сотрудников. Среди клиентов — крупные международные компании, включая организации из списка Fortune 100.

Для таких заказчиков главный вопрос звучит просто: мог ли инцидент затронуть обновления, интеграции, ключи доступа, телеметрию или служебные каналы связи. Пока Trellix говорит, что не видит признаков влияния на выпуск и распространение кода. Клиентам всё равно стоит внимательно следить за бюллетенями поставщика и внутренними журналами безопасности.

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

Компании уже сталкиваются с похожими задачами при срочных обновлениях инфраструктуры. Например, после выхода патчей для панелей управления администраторам приходится быстро проверять версии и доступ извне — об этом мы писали в материале cPanel и WHM закрыли три уязвимости: кому нужно обновиться.

Как снизить риск похожих инцидентов

Инцидент Trellix показывает, что репозитории и системы сборки требуют того же уровня защиты, что платёжные контуры или базы клиентов. Особенно если код связан с продуктами безопасности.

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

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

Отдельная линия защиты — обучение сотрудников. Фишинг (от англ. phishing — выуживание) остаётся одним из частых способов получить первый доступ к корпоративной среде, а атаки становятся точнее за счёт автоматизации и ИИ. Технические барьеры нужны, но один неверный вход под рабочей учётной записью всё ещё может стоить компании расследования на месяцы.

Практический вывод: что проверить прямо сейчас

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