Троянский конь в вашем package.json: как внешние JS-компоненты превращают веб-приложения в инструмент атаки

Supply chain risk — угроза, о которой знают все, но готовы к ней единицы. Разбираем механизмы атак, громкие инциденты и конкретные шаги защиты для команд разработки.

Введение: почему атаки на цепочку поставок стали главной угрозой для веб-разработки

Представьте: разработчик вводит в терминале npm install, и через секунды на его машину поступает код, который он никогда не читал, от автора, которого он никогда не встречал, из репозитория, который он никогда не проверял. Именно так выглядит большинство современных веб-проектов — собранных из сотен и тысяч внешних зависимостей.

Средний размер веб-приложения в 2024 году составлял около 180 открытых компонентов [3]. Это не баг, это фича: переиспользование кода ускоряет разработку, снижает стоимость и позволяет командам сосредоточиться на бизнес-логике. Но у каждого из этих 180 компонентов есть мейнтейнер, история коммитов, транзитивные зависимости и теоретически — потенциальный злоумышленник в цепочке.

Supply chain attack — атака на цепочку поставок программного обеспечения — это взлом не конечной цели, а промежуточного звена: библиотеки, инструмента сборки, CDN-сервиса или учётной записи разработчика. Вместо того чтобы штурмовать периметр конкретной компании, атакующий компрометирует доверенный компонент и ждёт, пока жертвы сами установят вредоносный код [16]. Эффект мультипликации колоссальный: один взломанный пакет может добраться до миллионов приложений.

По данным Sonatype, число supply chain атак удваивалось год к году в 2024 году [3]. OWASP в редакции своего Top Ten 2025 года включил проблемы цепочки поставок на третью позицию в рейтинге критических рисков безопасности веб-приложений [15]. Эта статья — детальный разбор механизмов угрозы, хронологии крупнейших инцидентов, специфики российского рынка и практических шагов по выстраиванию защиты.

Что такое supply chain attack: анатомия угрозы

Любое современное веб-приложение состоит из трёх условных слоёв: собственного кода, прямых зависимостей и транзитивных зависимостей (зависимостей зависимостей). Именно третий слой представляет наибольшую опасность: разработчик часто вообще не знает о его существовании, а уязвимость в нём может оказаться критической.

Атаки на цепочку поставок можно разделить на несколько принципиально разных типов в зависимости от вектора проникновения.

Вектор 1. Компрометация аккаунта мейнтейнера

Самый распространённый и технически простой способ. Злоумышленник получает доступ к учётной записи автора популярного пакета — чаще всего через фишинг — и публикует новую версию с вредоносным кодом. Именно так произошло в сентябре 2025 года: атакующие зарегистрировали домен npmjs[.]help и отправили фишинговые письма, имитирующие официальную поддержку npm. После захвата аккаунта мейнтейнера qix (Josh Junon) были выпущены заражённые версии 18 широко используемых пакетов — в их числе chalk, debug, ansi-styles и strip-ansi — с совокупными 2,6 млрд загрузок в неделю [18]. Вредоносный код перехватывал Web3-транзакции, подменяя адреса криптокошельков. Заражённые версии были доступны лишь около 2,5 часов до удаления, однако за это время они успели попасть в тысячи сборок [18].

Реакция Kaspersky GReAT была показательной: эксперты указали, что «мейнтейнеры широко используемого open-source неизменно остаются привлекательной целью для атакующих, ведь компрометация одного проекта может поставить под угрозу тысячи других систем» [14]. Этот «эффект домино» — характерная черта supply chain атак.

Вектор 2. Тайпсквоттинг и dependency confusion

Тайпсквоттинг (typosquatting) эксплуатирует человеческую невнимательность: злоумышленник публикует пакет с именем, отличающимся от популярного на один-два символа. Разработчик делает опечатку, получает вредоносный пакет. Исследования показывают, что 71,2% вредоносных пакетов npm используют длинные имена более 10 символов, а 67,3% включают дефисы, имитируя легитимное именование [20].

Dependency confusion — более изощрённая техника. Злоумышленник публикует в публичном реестре пакет с тем же именем, что и внутренний корпоративный пакет компании, но с более высоким номером версии. Если в конфигурации менеджера пакетов публичный реестр имеет приоритет, система автоматически скачает вредоносную версию вместо корпоративной [12].

В 2024 году исследователи зафиксировали новую вариацию — slopsquatting: атаку на галлюцинации ИИ. AI-ассистенты вроде ChatGPT и GitHub Copilot иногда рекомендуют несуществующие пакеты. Злоумышленники отслеживают такие рекомендации, регистрируют соответствующие имена в npm и публикуют под ними вредоносный код [13]. Разработчик, следующий совету ИИ, устанавливает malware.

Вектор 3. Захват домена или CDN

Этот вектор особенно опасен для клиентских веб-приложений, загружающих скрипты из внешних CDN. Если скомпрометирован сам сервис доставки, каждый посетитель сайта получает вредоносный JS прямо в браузере. Инцидент с Polyfill.io в 2024 году — классический пример: новый владелец домена начал встраивать вредоносный JavaScript, и до 110 000 сайтов, включая JSTOR, Intuit и World Economic Forum, незаметно для их владельцев стали распространять вредоносный код своим пользователям [4][5].

По данным Akamai, 50% JavaScript-кода на страницах e-commerce приходит из сторонних источников [11] — это означает, что огромная часть пользовательского интерфейса корпоративных систем фактически не контролируется самой организацией.

Вектор 4. Долгосрочное внедрение через социальную инженерию

Наиболее ресурсоёмкий, но и наиболее незаметный вариант. Атакующий создаёт фиктивную личность, годами вносит полезный код в open-source проект, завоёвывает доверие сообщества — и наконец получает права мейнтейнера. Именно так действовал «Jia Tan» в проекте XZ Utils: персонаж появился в 2021 году, два года добросовестно работал над проектом и лишь потом встроил бэкдор [8]. По оценке SentinelOne, подобная сложность и многолетнее планирование указывают на государственно-спонсируемого актора [8].

Вектор 5. Protestware: саботаж по политическим мотивам

Относительно новая категория, приобретшая политическое измерение. В марте 2022 года автор npm-пакета node-ipc с более чем 1,1 млн загрузок в неделю сознательно встроил в пакет код, стирающий файлы на машинах пользователей из России и Беларуси (CVE-2022-23812, CVSS 9.8) [6][7]. Пакет был транзитивной зависимостью Vue.js CLI и многих других популярных инструментов. В начале лета 2024 года был зафиксирован ещё 28 npm-пакетов с protestware-скриптами, ориентированными на российских пользователей и разработчиков [15].

Protestware ставит вопрос, который в привычном ИБ-дискурсе почти не звучит: вы доверяете мейнтейнеру не только технически, но и этически. Однако инструментов для проверки второго пока не существует.

Хронология громких инцидентов: от SolarWinds до Shai-Hulud

SolarWinds (2020): точка отсчёта

Атака на SolarWinds стала переломным моментом для всей отрасли. Начиная с сентября 2019 года группа, предположительно связанная с российской разведкой (SVR), получила доступ к системам сборки продукта Orion. В марте 2020 года заражённые обновления начали распространяться среди клиентов — около 18 000 организаций автоматически скачали версию с бэкдором SUNBURST [19]. Среди жертв оказались Министерство финансов, Министерство торговли и многие другие ведомства США. Атака оставалась незамеченной более 14 месяцев [19].

Для веб-разработки этот инцидент показал главное: даже подписанное обновление от авторитетного вендора может быть вредоносным, если скомпрометирован процесс сборки.

node-ipc / peacenotwar (2022): удар по российским разработчикам

15 марта 2022 года пользователи Vue.js начали фиксировать удаление файлов на своих машинах. Причина оказалась не в хакерской атаке извне, а в преднамеренном саботаже: мейнтейнер node-ipc добавил код, стирающий содержимое файлов у разработчиков с IP-адресами из России и Беларуси [6]. Инцидент затронул миллионы загрузок и стал первым массовым примером геополитически-мотивированного protestware в npm.

Snyk присвоил уязвимости критический балл 9.8 по CVSS и подчеркнул, что инцидент наглядно показал: транзитивные зависимости в коде могут иметь огромное влияние на безопасность [6].

XZ Utils (2024): почти идеальная атака

29 марта 2024 года инженер Microsoft Андрес Фрейнд обнаружил, что SSH-соединения на его машине потребляют аномально много CPU. Расследование привело к бэкдору в библиотеке XZ Utils версий 5.6.0 и 5.6.1 (CVE-2024-3094, CVSS 10.0) [8][14]. Бэкдор позволял выполнять произвольный код через SSH на скомпрометированных системах.

Масштаб угрозы был огромен: XZ Utils входит в базовые дистрибутивы Linux и используется на миллионах серверов по всему миру. Если бы заражённые версии успели попасть в стабильные релизы Debian и Fedora, удалённый доступ к критической инфраструктуре был бы катастрофическим [8].

Персонаж «Jia Tan» работал над проектом почти два года, внося полезный и качественный код, прежде чем встроить вредоносную нагрузку в «тестовые файлы» сборочного архива — не в публичный репозиторий GitHub [8]. Это разграничение намеренно: сканирование репозитория не выявило бы ничего подозрительного.

Polyfill.io (2024): 100 000 сайтов под ударом через CDN

В феврале 2024 года китайская компания Funnull приобрела домен polyfill.io и аккаунт на GitHub вместе с ним [4]. Polyfill.io — широко используемый сервис для обеспечения совместимости браузеров с современными JavaScript-функциями. После смены владельца сервис начал вместо легитимного кода доставлять вредоносный JavaScript. Код активировался только на мобильных устройствах с определёнными параметрами User-Agent, имитировал домен Google Analytics и перенаправлял пользователей на нежелательные ресурсы [4][5].

По данным Censys, на 2 июля 2024 года 384 773 хоста по всему миру всё ещё встраивали скомпрометированный скрипт [5]. Среди пострадавших ресурсов оказались Hulu, Mercedes-Benz и WarnerBros [5]. Оригинальный создатель Polyfill.io Эндрю Беттс ещё в феврале 2024 года предупредил пользователей не использовать сервис — однако большинство проигнорировало предупреждение.

В 2025 году выяснилось, что Funnull могла быть лишь прикрытием: данные, собранные Hudson Rock через infostealers, указали на возможную причастность северокорейских хакеров [4].

npm Shai-Hulud (2025): атаки, которые не останавливаются

Сентябрь 2025 года ознаменовался масштабной волной атак на npm, которую CISA выделила в экстренное предупреждение [1]. Самораспространяющийся червь Shai-Hulud похищал токены разработчиков и npm, после чего автоматически публиковал заражённые версии пакетов, к которым имел доступ скомпрометированный аккаунт [2]. Свыше 500 пакетов оказались заражены в первой волне [2].

Ноябрьская волна Shai-Hulud 2.0 оказалась ещё агрессивнее: атакующие переключились с post-install на pre-install исполнение, существенно расширив область поражения. Более 25 000 вредоносных репозиториев были созданы на аккаунтах порядка 350 пользователей GitHub [2]. В числе затронутых проектов — Zapier, PostHog, Postman. Версия 2.0 включала разрушительный механизм: если эксфильтрация данных проваливалась, малварь пыталась удалить содержимое домашней директории пользователя [2].

По данным Sonatype, только за четвёртый квартал 2025 года их системы заблокировали 120 612 malware-атак на npm [20].

Масштаб проблемы: цифры и тренды

Данные рисуют однозначную картину эскалации:

1. Число вредоносных пакетов в открытых реестрах выросло с 38 инцидентов в 2018 году до более 2 168 в 2024 году; за 2024 год Snyk выявил более 3 000 вредоносных npm-пакетов [20].
2. По данным Sonatype, с 2019 по 2024 год было идентифицировано 704 102 вредоносных пакета; их число растёт на 156% год к году [3].
3. 80% зависимостей в приложениях остаются необновлёнными более года, несмотря на то что в 95% случаев исправленная версия уже доступна [3].
4. Среднее время исправления критических уязвимостей увеличилось: в 2024 году для ряда проектов оно превысило 470 дней [3].
5. Атаки на цепочку поставок в среднем фиксировались почти 13 раз в месяц в начале 2024 года и выросли до более чем 16 в месяц к октябрю 2024 — маю 2025 года, а в отдельные месяцы достигали 25 [20].
6. Современное коммерческое ПО на 90% состоит из открытого кода [3], что означает: практически любое веб-приложение потенциально уязвимо через dependency цепочку.

По данным российского вендора CodeScoring, за 2025 год было зафиксировано 456 тысяч вредоносных версий пакетов — это десятикратный рост по сравнению с 2024 годом [15].

Российская специфика: особые риски и особые угрозы

Ситуация в России имеет несколько отличительных черт, которые усугубляют общие риски.

Protestware как инструмент давления

Инцидент с node-ipc в 2022 году стал первым, но не последним примером геотаргетированного вредоносного кода в npm. Пакет с более чем миллионом загрузок в неделю был намеренно превращён в инструмент уничтожения данных разработчиков из России и Беларуси [6]. В 2024 году CodeScoring зафиксировал 28 npm-пакетов с protestware-скриптами, ориентированными на российских пользователей [15].

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

Импортозамещение: новые стеки — новые риски

Курс на импортозамещение в России ускорил переход на новые технологические стеки. Как отмечает CISOCLUB, это ускорило использование open-source компонентов в разработке, однако специфические задачи по сертификации требуют анализа уязвимостей в привычных rpm- и deb-пакетах [16]. При этом российские разработчики реже публикуют информацию об уязвимостях в своём ПО, что осложняет построение полноценного CVE-мониторинга [15].

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

Отечественные доверенные репозитории

В ответ на эти вызовы в России появился ряд инициатив. «РТК Феникс» от «Ростелекома» — внутренний репозиторий с проверенными на уязвимости и недекларированные возможности компонентами, автоматически встраивающийся в процесс разработки. По данным SecurityLab, проект содержит десятки тысяч верифицированных пакетов и ориентирован на компании, переходящие на отечественные стеки [17]. SourceCraft от Yandex B2B Tech поддерживает более 30 языков программирования и сканирует код на уязвимости, утечки секретов и риски в цепочках поставок [17].

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

Инструменты защиты: от SBOM до SLSA

Индустрия выработала несколько ключевых инструментов и практик.

SBOM: реестр компонентов

SBOM (Software Bill of Materials) — список всех компонентов, библиотек и зависимостей, входящих в программное обеспечение, с указанием версий, лицензий и источников. OWASP в своём Cheat Sheet по безопасности цепочки поставок указывает, что формирование и потребление SBOM должно быть автоматизировано как часть CI/CD-процесса [10]. SBOM решает фундаментальную проблему: невозможно защитить то, о чём не знаешь.

Ключевой момент: SBOM сам по себе не является инструментом безопасности — это список ингредиентов, а не сертификат качества. Его ценность реализуется только в связке с мониторингом уязвимостей и политиками обновления.

SLSA: уровни безопасности сборки

SLSA (Supply-chain Levels for Software Artifacts, произносится «сальса») — фреймворк OpenSSF, предложенный Google на основе внутренней системы «Binary Authorization for Borg» [9]. Фреймворк определяет четыре уровня безопасности сборочного процесса:

1. Уровень 1: существует provenance — верифицируемые метаданные о том, как и где был собран артефакт.
2. Уровень 2: provenance подписан криптографически сборочной платформой, используется выделенная CI/CD-инфраструктура.
3. Уровень 3: сборки изолированы, невозможно незаметно подменить зависимости или артефакты; злоумышленнику крайне сложно сфальсифицировать provenance.

SLSA решает проблему, которую продемонстрировал инцидент с XZ Utils: бэкдор был встроен не в публичный репозиторий, а в release-архив. Если бы потребители использовали SLSA-совместимую проверку provenance, они могли бы обнаружить расхождение между тем, что указано в метаданных, и тем, что фактически содержит артефакт [9].

По оценке экспертов, достижение SLSA Level 1 занимает 2–4 недели, Level 2 — 4–8 недель, Level 3 — от 3 до 6 месяцев для большинства организаций [47 — данный источник см. в списке].

SCA-инструменты и автоматическое сканирование

Software Composition Analysis (SCA) — инструменты, автоматически анализирующие зависимости на предмет известных уязвимостей. Среди распространённых решений: Snyk, OWASP Dependency-Check, retire.js, Dependabot (встроен в GitHub). Российские эквиваленты включают SKATmen от «Инферит», ориентированный на БДУ ФСТЭК [65 — данный источник см. в списке].

Принципиальное ограничение SCA: инструменты работают с базами данных известных уязвимостей (CVE, NVD, БДУ ФСТЭК) [16]. Они не способны обнаружить вредоносный код в пакете, для которого CVE ещё не создан, — именно так функционировало большинство атак 2024–2025 годов. Для расширенного обнаружения необходимо поведенческое сканирование и анализ сетевой активности зависимостей.

Subresource Integrity и Content Security Policy

Subresource Integrity (SRI) — механизм браузера, позволяющий указать криптографический хеш ожидаемого содержимого внешнего скрипта прямо в теге <script integrity="...">. Если доставленный файл не совпадает с хешем, браузер блокирует его выполнение. Именно SRI мог бы полностью предотвратить ущерб от атаки Polyfill.io для сайтов, его использующих [4].

Content Security Policy (CSP) дополняет SRI: политика позволяет ограничить список доменов, с которых сайт вправе загружать скрипты, стили и другие ресурсы. Совместное использование SRI и строгой CSP создаёт надёжный барьер против CDN-атак клиентского типа [57 — данный источник см. в списке].

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

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

1. Зафиксировать все зависимости в lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) и использовать команду npm ci вместо npm install в CI/CD-пайплайнах. Это исключает автоматическую установку новых версий без явного обновления lockfile.
2. Включить Dependabot или аналогичный инструмент для автоматических pull-request'ов при появлении новых уязвимостей в зависимостях.
3. Добавить проверку Subresource Integrity для всех внешних скриптов, загружаемых из CDN. Любой скрипт, подключаемый через внешний URL без атрибута integrity, является потенциальным вектором атаки.
4. Внедрить Content Security Policy с явным белым списком разрешённых доменов для загрузки скриптов.
5. Настроить аудит зависимостей как обязательный шаг в CI/CD: npm audit или SCA-инструмент уровня Snyk / Dependabot должны блокировать сборку при обнаружении критических уязвимостей.
6. Провести инвентаризацию: знаете ли вы, какие именно сторонние JS-скрипты загружаются на ваши страницы прямо сейчас? Включая те, что подгружаются из скриптов третьих сторон?
7. Ввести политику код-ревью для обновлений зависимостей: автоматически одобренный Dependabot-PR с мажорным обновлением криптографической библиотеки — риск, а не удобство.
8. Формировать SBOM для каждого релиза и хранить его как артефакт сборки — это упрощает реагирование на инциденты типа «у нас установлена уязвимая версия chalk?».
9. Ограничить область действия npm-токенов: разделить токены для публикации и для чтения, включить MFA для аккаунтов мейнтейнеров (особенно для публичных пакетов).
10. Рассмотреть использование частного реестра (Artifactory, Nexus, Verdaccio) с проксированием публичных реестров — это даёт точку контроля над тем, какие версии доступны в вашей организации.

Типичные ошибки и как их не допустить

Разбор реальных инцидентов позволяет выделить паттерны, которые повторяются от атаки к атаке.

Первая и наиболее распространённая ошибка — слепое доверие к популярности пакета. Chalk, debug, ansi-styles — эти библиотеки считались абсолютно безопасными именно потому, что миллиарды разработчиков использовали их без инцидентов. Именно это делает их ценными мишенями для атакующих: высокая популярность означает огромный охват при минимальных усилиях.

Вторая ошибка — игнорирование транзитивных зависимостей. Организации часто проверяют прямые зависимости своего проекта, упуская из вида, что у каждой из них есть свои зависимости — и именно в них чаще всего прячется вредоносный код. Атака через node-ipc пострадала Vue.js, чьи команды вообще не осознавали этой связи.

Третья ошибка — отсутствие мониторинга клиентской стороны. Компании инвестируют в анализ серверных зависимостей, но слабо контролируют, какой JavaScript в итоге исполняется в браузерах их пользователей. По данным Akamai, 50% JavaScript на страницах платёжных систем e-commerce приходит из сторонних источников [11] — это означает серьёзную угрозу с точки зрения требований PCI DSS v4.0.

Четвёртая ошибка — реагирование только на CVE. Большинство supply chain атак 2024–2025 годов не имели CVE в момент активности. Паттерн повторяется: вредоносный код обнаруживается исследователями, публикуется предупреждение, только после этого появляется CVE. К тому моменту код мог быть в вашей сборке уже несколько часов или суток.

Пятая ошибка — отсутствие плана реагирования на инциденты цепочки поставок. Организации, быстрее других отреагировавшие на атаку Shai-Hulud в сентябре 2025 года, имели задокументированный playbook — список шагов: что проверить, как откатить сборку, как ротировать учётные данные. Те, у кого его не было, потратили первые 48 часов на выяснение, что вообще нужно проверять [20].

Что дальше: тренды и прогнозы

Индустрия движется в нескольких направлениях одновременно.

Атаки становятся более автоматизированными и масштабными. Sonatype в отчёте 2026 года отметил, что при объёме 454 648 новых вредоносных пакетов за 2025 год злоумышленники явно используют автоматизацию и, вероятно, AI для генерации вредоносного кода и управления кампаниями [25]. Shai-Hulud 2.0 продемонстрировал самовоспроизводящееся поведение, напоминающее компьютерных червей классической эпохи, только в экосистеме open-source [2].

Регуляторное давление усиливается. В США Исполнительный указ 14028 (EO 14028) требует SBOM для программного обеспечения, поставляемого федеральным агентствам. Европейский Акт о киберустойчивости (Cyber Resilience Act) устанавливает требования к безопасности цепочки поставок для продуктов с цифровыми элементами. В России регуляторная база в этой части менее развита, однако требования ФСТЭК к защищённой разработке косвенно затрагивают эту проблематику.

Возможности защиты тоже растут. Cloudflare Page Shield продемонстрировал, что ML-модели, анализирующие поведение скриптов в реальном времени, способны выявлять компрометацию без знания конкретного CVE [11]. Это важный сдвиг: от реактивного детектирования по базам уязвимостей к проактивному поведенческому анализу.

Концепция «нулевого доверия» распространяется на зависимости. Подход «доверяй, но проверяй» трансформируется в «не доверяй ничему внешнему без криптографического подтверждения происхождения» — именно это и описывает SLSA [9]. Признание SLSA индустриальным стандартом и его постепенная интеграция в основные платформы (GitHub Actions, Google Cloud Build) делает эту модель всё более доступной.

Заключение: выводы и что делать дальше

Атаки на цепочку поставок JS-компонентов — не гипотетическая угроза будущего, а настоящая эпидемия, разворачивающаяся прямо сейчас. Каждый package.json — это карта доверия, и каждая строка в ней подразумевает, что вы доверяете всей цепочке: мейнтейнеру, его учётной записи в npm, домену репозитория, инфраструктуре регистратора. Эта цепочка длиннее, чем кажется, и в любом из её звеньев может произойти компрометация.

Ключевые выводы:

1. Популярность пакета не является гарантией безопасности — скорее, это делает его более привлекательной мишенью.
2. Большинство современных атак не имеют CVE в момент активности, что делает мониторинг только по базам уязвимостей недостаточным.
3. Российские организации подвержены дополнительному специфическому риску: protestware с геотаргетингом и ограничения доступа к западным реестрам.
4. Защита требует системного подхода: lockfiles + SRI + SCA + SBOM + поведенческий мониторинг — ни одного из этих элементов по отдельности недостаточно.
5. Инвентаризация — первый шаг: если у вас нет актуального списка зависимостей и того, откуда они берутся, всё остальное невозможно.

Начать стоит с малого: запустите npm audit или аналогичный инструмент прямо сейчас и посмотрите, что в вашем проекте выходит за пределы допустимого. Проверьте, есть ли на ваших страницах внешние скрипты без SRI. Сформируйте хотя бы базовый SBOM.

Автоматизированный контроль зависимостей: когда ручного аудита недостаточно

Одна из ключевых проблем, на которую указывают все описанные инциденты, — это разрыв между тем, что компания думает о своём ПО-ландшафте, и тем, каков он в реальности. Новый пакет появился вчера. Мейнтейнер обновил внутренний инструмент. DevOps-инженер добавил зависимость в pipeline, не зафиксировав это в документации. ИТ-ландшафт постоянно меняется, а ручные аудиты успевают отразить только прошлое.

Платформа Пятый фактор решает смежную задачу на уровне корпоративных данных: автоматическое обнаружение, инвентаризация и контроль персональных данных в корпоративных системах — БД, хранилищах, почте, CRM, 1С и API. Ключевой принцип работы — privacy-by-design: система работает только с метаданными, структурой и агрегатами, не передавая и не храня сырые данные.

Это принципиально важно в контексте supply chain рисков. Когда новый сервис или интеграция появляются в инфраструктуре — будь то результат подключения нового внешнего компонента или нового подрядчика — Пятый фактор даёт «живую карту» того, где и какие данные есть, кто их владелец и что изменилось. Команды ИБ видят новые риски раньше, чем те превращаются в инцидент. А аудит, который раньше занимал недели ручной работы, становится непрерывным процессом с понятными владельцами и статусами.

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

Источники

[1] CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem — https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem

[2] Palo Alto Unit 42: Shai-Hulud Worm Compromises npm Ecosystem — https://unit42.paloaltonetworks.com/npm-supply-chain-attack/

[3] Sonatype: 10th Annual State of the Software Supply Chain — https://www.sonatype.com/state-of-the-software-supply-chain/introduction

[4] Sonatype: Polyfill.io Supply Chain Attack — https://www.sonatype.com/blog/polyfill.io-supply-chain-attack-hits-100000-websites-all-you-need-to-know

[5] Censys: Polyfill Supply Chain Attack Investigation — https://censys.com/blog/july-2-polyfill-io-supply-chain-attack-digging-into-the-web-of-compromised-domains/

[6] Snyk: peacenotwar / node-ipc vulnerability — https://snyk.io/blog/peacenotwar-malicious-npm-node-ipc-package-vulnerability/

[7] BleepingComputer: node-ipc protestware — https://www.bleepingcomputer.com/news/security/big-sabotage-famous-npm-package-deletes-files-to-protest-ukraine-war/

[8] SentinelOne: XZ Utils backdoor analysis — https://www.sentinelone.com/blog/xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities/

[9] SLSA framework (OpenSSF) — https://slsa.dev/

[10] OWASP: Software Supply Chain Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html

[11] Cloudflare Blog: How Cloudflare's client-side security made the npm supply chain attack a non-event — https://blog.cloudflare.com/how-cloudflares-client-side-security-made-the-npm-supply-chain-attack-a-non/

[12] Sonatype: A History of Software Supply Chain Attacks — https://www.sonatype.com/resources/vulnerability-timeline

[13] Chainguard: The npm registry can't protect you — https://www.chainguard.dev/supply-chain-security-101/the-npm-registry-cant-protect-you-the-new-javascript-supply-chain-attacks

[14] Kaspersky Blog RU: скомпрометированы npm-пакеты — https://www.kaspersky.ru/blog/npm-packages-trojanized/40446/

[15] Хабр / CodeScoring: атаки на цепочку поставки ПО — https://habr.com/ru/companies/codescoring/articles/1011358/

[16] CISOCLUB: Open Source как слабое звено — https://cisoclub.ru/pochemu-open-source-samoe-slaboe-zveno-v-czepochke-postavok-i-kak-snizit-riski

[17] SecurityLab: российские OSS-проекты для ИБ 2026 — https://www.securitylab.ru/analytics/568978.php

[18] SISA Sappers: npm attack advisory (2.6B weekly downloads) — https://www.sisainfosec.com/blogs/npm-supply-chain-attack-hits-packages-with-billions-of-weekly-downloads-advisory-by-sisa-sappers/

[19] GAO (США): SolarWinds cyberattack — https://www.gao.gov/blog/solarwinds-cyberattack-demands-significant-federal-and-private-sector-response-infographic

[20] Cyberdesserts: npm Security Risks 2026 — https://blog.cyberdesserts.com/npm-security-vulnerabilities/