Атака на цепочку поставки через Steam, или как вредоносный код спрятали в легитимных обновлениях

В США задержали 21-летнего Зайра Уилкинса, которого обвиняют в причастности к схеме распространения игр с вредоносным кодом через Steam. По версии следствия, встроенное в игры вредоносное ПО собирало учетные данные и другую информацию с компьютеров пользователей.

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

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

Особенно показателен случай Lampy. Вредоносный код содержала обновленная версия игры, выпущенная в январе 2026 года. Пользователю не требовалось переходить на поддельный сайт или устанавливать программу из неизвестного источника – исполняемый файл доставлялся через привычный механизм обновлений.

Судя по опубликованным материалам, злоумышленники не взламывали сам Steam. Они встроились в штатный процесс поставки и использовали доверие к площадке, учетной записи издателя и обновлениям. Этот случай хорошо дополняет привычное представление об атаках на цепочку поставки. Точкой входа может стать не только скомпрометированная зависимость или система сборки, но и канал, через который готовый продукт доходит до пользователя.

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

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

PyPI готовится закреплять префиксы имен пакетов за организациями

29 июня 2026 года был принят PEP 752. Он описывает механизм, с помощью которого пакетные репозитории смогут закреплять префиксы имен за определенными организациями. Например, новые пакеты с префиксом google-cloud- смогут публиковать только организации, получившие соответствующее право.

Сейчас пространство имен PyPI остается плоским. Если название свободно, пользователь может зарегистрировать пакет, который выглядит частью известного проекта, например, google-cloud-something, opentelemetry-something или apache-airflow-providers-something. Знакомый префикс повышает доверие к названию, хотя реального отношения к организации у пакета может не быть.

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

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

Принятый PEP пока описывает стандарт, а не уже работающую функцию PyPI. Правила подачи и рассмотрения заявок вынесены в PEP 755, который остается черновиком. Срок запуска механизма также пока не объявлен.

PEP 752 переносит часть проверки на самый ранний этап, когда в репозитории только появляется новое имя. Для семейств пакетов вроде google-cloud-* или apache-airflow-providers-* это позволяет остановить постороннего издателя до того, как правдоподобно названная подделка станет доступна пользователям.

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

Когда механизм заработает, новые метаданные можно будет использовать не только на страницах PyPI. Менеджеры пакетов и корпоративные прокси смогут пропускать пакеты с защищенным префиксом, только если издатель имеет на него право. Это точечная защита от одного семейства атак на имена; остальные сценарии неймсквоттинга мы разбирали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

npm 12 больше не запускает скрипты установки зависимостей без разрешения

npm 12 больше не запускает скрипты установки зависимостей автоматически и требует отдельно разрешать установку из внешних источников и Git. Одновременно npm начинает ограничивать токены с обходом двухфакторной аутентификации. В посте разбираем, что это меняет для безопасности установки пакетов и что стоит проверить перед обновлением. 

8 июля 2026 года GitHub выпустил npm 12 и пометил его тегом latest. Вместе с новой версией изменился базовый сценарий установки – раньше скрипт зависимости мог выполниться автоматически, теперь проект должен заранее разрешить его через allowScripts.

Ограничение распространяется на preinstall, install, postinstall и неявные сборки через node-gyp. Если такой скрипт действительно нужен, его можно добавить в список разрешенных; для разбора уже существующего проекта npm предлагает команду npm approve-scripts --allow-scripts-pending, которая показывает зависимости без явно заданного решения и помогает сохранить настройки в package.json.

Тот же принцип теперь применяется к зависимостям из Git и удаленным архивам. Без --allow-git npm откажется устанавливать Git-зависимости, а для архивов по внешним URL понадобится --allow-remote. В июньском анонсе npm 12 GitHub отдельно отмечал, что Git-зависимости создавали обходной путь для выполнения кода даже при использовании --ignore-scripts.

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

Почему это важно

Новые настройки заметно сужают возможности для атак через установочные скрипты. Это хорошо видно на примере Shai-Hulud и Shai-Hulud 2.0. В первой вредоносные версии пакетов в основном запускали код через postinstall, а во второй для этого использовался preinstall. Однако важно понимать, что вредоносный пакет по-прежнему может попасть в реестр и дерево зависимостей, а нежелательный код выполнится позднее, когда его импортирует приложение или система сборки. npm 12 закрывает не весь путь заражения, а именно автоматическое выполнение кода непосредственно во время установки. Более широкий разбор атак через пакеты и другие звенья цепочки поставки есть в нашей статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Перед переходом на новую версию командам стоит проверить:

• какие зависимости действительно используют установочные скрипты

• откуда в проектах появляются Git-зависимости и удаленные архивы

• есть ли в CI долгоживущие токены публикации с лишними правами

Подписывайтесь на Codescoring в Telegram, VK, YouTube и Макс.