Брз одговор: Нападите врз синџирот на снабдување на Npm функционираат со компромитирање на доверлива сметка на одржувач или CI/CD токен, објавување на злонамерна верзија на пакет на кој програмерите веќе му веруваат и дозволување на скриптите за инсталација на тој пакет или логиката на црвот да го направат останатото. Помеѓу август 2025 и средината на 2026 година, овој модел произведе најголем бран напади на синџирот на снабдување со npm пакети во историјата на регистарот, вклучувајќи го и киднапирањето на креда/дебагирање, Црвот Шаи-Хулуди малициозен софтвер на националната држава скриен во пакет преземен 100 милиони пати неделно. Решението не е скенирање на кодот откако ќе се појави. Тоа е фаќање на малициозни пакети пред да се инсталираат и следење на pipeline за точното однесување што го делат овие напади.
Секоја инсталација е чин на доверба, а напаѓачите го знаат тоа
Програмер работи npm инсталирајЗад таа една команда се наоѓа дрво на зависности со стотици, понекогаш илјадници пакети, од кои повеќето се напишани и одржувани од луѓе што развивачот никогаш нема да ги сретне. Никој не го прегледува тоа дрво ред по ред. Никој нема време за тоа.
Таа доверба е целта. Поевтино е за напаѓачот да провали еден одржувач на npm со 2.6 милијарди неделни преземања отколку да најде нулто-ден во заштитен ѕид од листата Fortune 500. Нападите во синџирот на снабдување на Npm ја искористуваат токму оваа асиметрија, а бранот 2025-2026 покажува колку далеку се проширил тој експлоатација: од изолирани типосквотирање до саморазмножувачки црви кои ги објавуваат своите малициозни пакети побрзо отколку што може да реагира кој било човек.
Што се смета за напад врз синџирот на снабдување на npm
Напад на синџирот на снабдување со npm е секој инцидент каде што напаѓачот вметнува злонамерен код во дистрибуцијата на npm. pipeline наместо во сопствената база на кодови на целта, така што малициозниот софтвер пристигнува маскиран како рутинско ажурирање на зависност. Влезната точка е обично една од трите работи: украдени акредитиви од одржувачот, украдено објавување или CI/CD токен или компромитирана верзија pipeline што е измамено да објави во име на напаѓачот. Бидејќи npm пакетите автоматски ги повлекуваат транзитивните зависности, еден компромитиран пакет може да стигне до апликации кои никогаш не го декларирале како директна зависност.
Временска рамка: најголемите напади врз синџирот на снабдување со npm од 2025-2026 година
Моделот зад секој напад на синџирот на снабдување со npm пакети
Отстранете ги спецификите, и речиси секој инцидент погоре ги следи истите четири чекори:
- Компромитирајте го идентитетот, а не системот. Фиширан одржувач, протечен npm токен, украден GitHub PAT или OIDC токен извлечен од CI/CD меморија на runner. Напаѓачот не го пробива регистарот. Тие позајмуваат нечиј клуч за него.
- Објави под име на кое програмерите веќе му веруваат. Не е потребно пишување на грешки кога вистинското име на пакетот работи. Ова е она што ги прави овие напади толку ефикасни против автоматско ажурирање. pipelines: ажурирањето изгледа сосема легитимно.
- Стартувај пред некој да го прегледа. Злонамерни скрипти за инсталација, замаглени кориснички оптоварувања или код за спиење што се активира само под одредени услови се извршуваат во моментот кога npm инсталирај работи, често на лаптопот на развивачот, долго пред закажаното безбедносно скенирање воопшто да го види.
- Да истрае и, сè повеќе, да се пропагира. Шаи-Хулуд и неговите потомци ги користат акредитивите што ги крадат за автоматски да го објават следниот отровен пакет, претворајќи го еден компромис во верижна реакција низ графиконот на зависности.
Зошто вообичаените одбрани го пропуштаат тоа
Поголемиот дел од алатките на AppSec беа изградени за да анализираат што веќе е во складиштето: познати CVE-и, статички кодови, проблеми со лиценците. Тоа е неопходно, но структурно пристигнува предоцна за оваа класа на напад. Додека скенерот види зависност, скриптата за инсталација можеби веќе е извршена на машината на развивачот. Традиционалниот антивирус и EDR го следат оперативниот систем, а не регистрите на пакетите, па затоа немаат концепт за „ново npm издание“ како единица на ризик. И како што покажуваат инцидентите со TanStack и Red Hat, дури и потврдите за интегритет на градење како SLSA provenance не помагаат кога напаѓачот легитимно го фатил идентитетот што го потпишува: потписот е валиден, пакетот е сè уште злонамерен.
Празнината што ја искористуваат овие напади во синџирот на снабдување со npm се наоѓа конкретно во времето на објавување и инсталација, пред да постои потпис за малициозниот софтвер и пред пакетот да се изврши некаде каде што би барал традиционален скенер.
Како да се запре следниот напад врз синџирот на снабдување на npm
Дел од ова е процесна дисциплина што секој инженерски тим може да ја усвои денес:
- Зависности од пинови и commit заклучени датотеки, па автоматското ажурирање не може тивко да внесе штотуку објавена злонамерна верзија.
- Оневозможи или стави во песочник скрипти по инсталацијата по дифолт; повеќето пакети не треба да извршуваат произволен код за време на инсталацијата.
- Спроведување на хардверски поддржан MFA за сметки за објавување на npm, затворајќи ја точната фишинг патека што ги компромитираше chalk, debug и сметката на Qix.
- Опсег и ротирање CI/CD токени агресивнои третирајте ги OIDC токените во меморијата на извршителот како акредитив што вреди да се заштити, а не како детаљ за имплементација.
- Внимавајте на шемата отклучување-инјектирање-повторно заклучување in CI/CD: правило за заштита на гранка е оневозможено, commit притиснато, правилото повторно овозможено, сè во краток рок. Тоа е периодичен потпис на pipelineкомпромитирање на синџирот на снабдување на ниво на.
Каде што дисциплината на процесот истекува
Дисциплината на процесот ја намалува изложеноста. Не го фаќа малициозниот пакет во моментот кога е објавен и не го фаќа црвот кој веќе се шири низ графиконот побрзо отколку што човекот може да го тријажира. Тоа е слојот за кој е изградена Безбедноста на снабдувачкиот синџир на Xygeni.
Ксигени MEW (Рано предупредување за малициозен софтвер) континуирано анализира нови пакети објавени на npm, PyPI и Maven, откривајќи малициозен софтвер пред да постои потпис, а не потоа, и враќајќи ги потврдените закани назад во Ксигени сопствен мотор за детекција. Зависност на заштитен ѕид скенира npm, PyPI, Maven, NuGet и RubyGems во реално време и блокира малициозни инсталации пред да стигнат до машината на развивачот или до градбата. CI/CD откривање аномалија часовници pipelines за точно моделот на однесување зад инциденти како компромитирањето на TanStack, вклучувајќи ја секвенцата отклучување-инјектирање-повторно заклучување, со целосна ревизорска трага. И бидејќи Xygeni's Тријажа и санација со вештачка интелигенција важат и за наодите од скенери од трети страни, тимовите не мора да ги отстрануваат постојните алатки за да го пополнат овој јаз.
Најчесто поставувани прашања: напади во синџирот на снабдување на npm
Што е напад на синџирот на снабдување со npm?
Тоа е напад каде што малициозниот код стигнува до целната апликација преку доверлива npm зависност, а не преку сопствениот код на целта, обично затоа што напаѓачот ја компромитирал сметката на одржувачот, токен за објавување или... CI/CD pipelineидентитетот на.
Кој беше најголемиот напад врз синџирот на снабдување на npm?
Според радиусот на експлозијата, киднапирањето со chalk/debug од септември 2025 година е меѓу најголемите: 18 пакети со вкупно 2.6 милијарди неделни преземања беа компромитирани преку една фиширана сметка на одржувач. Според техничката новина, Shai-Hulud беше позначајната пресвртница, како прв саморазмножувачки црв во историјата на npm.
Како обично започнува нападот на синџирот на снабдување со npm пакети?
Речиси секогаш со украден идентитет: фиширан одржувач, протечен токен за објавување или украден CI/CD акредитив како што е OIDC токен извлечен од меморијата на тркачот, наместо техничко пробивање во самиот npm.
Може ли антивирусот или EDR да спречат напад врз синџирот на снабдување со npm?
Не е сигурно. EDR го следи оперативниот систем и не ги разбира регистрите на пакети, а антивирусот е базиран на потписи, што не успева против малициозен софтвер објавен пред да постои каков било потпис. Запирањето на оваа класа на напади бара следење на местото на објавување и инсталација, а не само на крајната точка.
Не SLSA provenance или да се изгради атестирање за да се спречи ова?
Тоа докажува дека pipeline самото не било менувано за време на градењето. Тоа не докажува дека идентитетот што го активирал градењето не бил компромитиран, како што покажаа инцидентите со TanStack и Red Hat со валидни потврди прикачени на злонамерните пакети.
Како може тимот да открие малициозен npm пакет пред да биде инсталиран?
Со извршување на континуирана анализа на малициозен софтвер пред потпишување на новообјавени пакети, што е она за што се дизајнирани системот за рано предупредување за малициозен софтвер и заштитен ѕид на зависности, наместо да се потпираат исклучиво на пост-хок скенирање на ранливости на кодот што веќе е во складиштето.
Каде да започне
Нападите врз синџирот на снабдување на Npm не забавуваат, а трендот од Шаи-Хулуд покажува кон поголема автоматизација, а не помала. Тимовите најдобро позиционирани за следната кампања се оние кои престанаа да ја третираат секоја инсталација на npm како рутински настан и почнаа да го следат регистарот, pipeline, а крајната точка како една поврзана површина за напад.
Планот за развивачи на Xygeni вклучува покриеност со MEW и Dependency Firewall за до 25 репозиториуми без трошоци. Тоа е разумно место за да се види што веќе се наоѓа во дрвото на зависности.
