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

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

Поддельные расширения под видом известных брендов

Open VSX — общедоступный маркетплейс расширений для редакторов кода: небольших дополнений, которые разработчики устанавливают для автодополнения, линтинга и интеграции с инструментами, которыми пользуются ежедневно (из него загружают расширения Visual Studio Code и несколько его проектов-двойников с открытым исходным кодом). С 26 июля по 1 августа 2026 года исследователи безопасности из Manifold Security обнаружили в реестре 77 поддельных расширений. Каждое копировало название и пространство имён настоящего доверенного расширения, но было опубликовано из аккаунта, которому оригинал не принадлежал, — классический приём выдачи себя за другого, иногда называемый захватом пространства имён.

Захваченные имена были выбраны не случайно. Они заимствовали идентичность AMD, LEGO Education, Hyperledger, Azure, проектов Salesforce с открытым исходным кодом, одного федерального ведомства США и — с мрачной иронией — самого маркетплейса расширений. Все 77 пакетов связывались с одним доменом, зарегистрированным всего за 11 дней до появления первого поддельного пакета. Это указывает скорее на скоординированную целевую кампанию, чем на случайное копирование.

Большинство поддельных расширений делали нечто незначительное: незаметно отправляли имя хоста на сервер злоумышленника, что само по себе могло быть лишь проверкой того, кто установил приманку. Но исследователи обнаружили, что примерно четверть из 77 — 19 пакетов — шли дальше. Через несколько секунд после активации они собирали имя хоста, имя пользователя операционной системы, сведения о редакторе и идентификатор машины. Затем они читали открытый у разработчика проект: git remote (раскрывающий организацию и хост репозитория), домен из адреса электронной почты коммитов, текущую ветку и последний коммит. Они также извлекали параметры непрерывной интеграции — учётные данные и конфигурацию, позволяющие автоматизированным системам собирать и развёртывать код без необходимости каждый раз вводить пароль вручную.

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

Уязвимость с оценкой 9,8 из 10 в машине, создающей программное обеспечение

Второй инцидент связан с TeamCity — платформой непрерывной интеграции и непрерывной поставки (CI/CD), разработанной JetBrains. Если редактор кода — это место, где разработчики пишут программы, то платформа CI/CD — автоматизированный заводской цех, где этот код компилируется, тестируется и отправляется в промышленную эксплуатацию, часто вообще без единого нажатия человеком кнопки «развернуть». TeamCity — центральная часть этой machinery во множестве компаний.

В локальных версиях TeamCity была раскрыта уязвимость CVE-2026-63077 с оценкой серьёзности 9,8 из возможных 10. Это недостаток десериализации — класс ошибок, при котором программа настолько доверяет входящим данным, что превращает их непосредственно в исполняемый код, не проверив сначала, чем эти данные на самом деле являются. На практике злоумышленник мог отправить запрос на уязвимый сервер TeamCity без входа в систему и выполнить произвольные команды с теми же привилегиями, что и сам сервис TeamCity. JetBrains выпустила исправления (версии 2025.11.7 и 2026.1.3, а также плагин-исправление для старых установок 2017.1+), но с тех пор Агентство США по кибербезопасности и защите инфраструктуры (CISA) предупредило, что злоумышленники активно атакуют не обновлённые системы.

Тот, кто контролирует сервер сборки компании, контролирует то, что эта компания выпускает. Это не гипотеза — это буквальное предназначение инструмента.

Один сценарий, две разные двери

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

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

Почему это ваша проблема, а не только их

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

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

Что действительно помогает

Вы не можете проверить конвейер CI/CD своего банка, да и не должны этого делать. Но несколько привычек действительно снижают подверженность этому виду риска:

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

Если вы работаете с разработчиками или руководите ими, есть две конкретные вещи, которые можно проверить: убедитесь, что любое расширение для редактора кода установлено из настоящего подтверждённого аккаунта издателя, а не просто имеет совпадающее название (Open VSX и похожие маркетплейсы показывают личность издателя — проверьте её, не доверяйте только значку и заголовку); а если ваша организация использует локальный TeamCity, проверьте сегодня, что он работает на версии 2025.11.7, 2026.1.3 или что для него установлен плагин-исправление, а не откладывайте это до следующего окна обслуживания — предупреждение CISA означает, что уязвимость активно эксплуатируется, а не существует лишь теоретически.

Для всех остальных полезно лишь изменить восприятие: когда вы читаете о взломе компании, причиной которого стала «скомпрометированная среда разработчика» или «система сборки», это не малозначительная техническая сноска. Это та же категория событий, что и утечки паролей и фишинговые мошеннические схемы, о которых эта рассылка рассказывает чаще, — просто всё началось на один уровень выше, ещё до того, как продукт вообще дошёл до вас.