TL;DR: npm forsyningskjedesikkerhet utover sårbarhetsskanneren
npm forsyningskjedesikkerhet er praksisen med å sørge for at hver pakke JavaScript-prosjektene dine installerer er legitim, umodifisert og trygg, ikke bare fri for kjente sårbarheter.
- Gapet: En klassisk npm-sårbarhetsskanner matcher pakker mot CVE-databaser. En ondsinnet pakke har ingen CVE, så den består.
- Beviset: I mars 2026 gjorde en kapret vedlikeholdskonto axios, med over 100 millioner ukentlige nedlastinger, om til en leveringskanal for skadelig programvare i omtrent tre timer.
- Inngangspunktet: De fleste npm-angrep kjører gjennom installasjonsskript, som kjøres i det øyeblikket du skriver
npm install. - Fiksingen: oppdage ondsinnet oppførsel når pakker publiseres, ikke etter at en CVE dukker opp, og gjøre installasjoner mer effektive.
31. mars 2026 kjørte tusenvis av utviklere den vanligste kommandoen i JavaScript: npm installNoen av dem hentet en ny versjon av axios, HTTP-klienten som sitter i en stor andel av verdens webapplikasjoner. Avhengighetsskannerne deres forble grønne. Byggene deres bestod. Og en trojaner for ekstern tilgang landet stille på maskinene deres.
Ingenting i den historien involverte en sårbarhet. Det er nettopp derfor så mange npm-sikkerhetsprogrammer gikk glipp av den.
Hva skjedde med aksios
Angrepet var enkelt og tålmodig. I følge axios-vedlikeholdernes egen post mortem, ble to ondsinnede versjoner, 1.14.1 og 0.30.4, publisert gjennom hovedvedlikeholderens kompromitterte konto. Angriperen rørte ikke en eneste linje med axios-kode. De la til én ny avhengighet, plain-crypto-js, som kjørte en postinstall skript som hentet en nyttelast for andre trinn.
Microsoft Threat Intelligence tilskrev infrastrukturen til Sapphire Sleet, en nordkoreansk statsaktør. De forgiftede versjonene var aktive i omtrent tre timer før npm fjernet dem. For enhver CI pipeline eller bærbar PC som ble installert i løpet av det vinduet, var tre timer nok.
Det var ikke et isolert tilfelle. I september 2025 spredte Shai-Hulud-ormen seg over hundrevis av npm-pakker ved å stjele vedlikeholdstokener og publisere seg selv på nytt. Ulike teknikker, samme lærdom: i npm arves tillit automatisk, og angripere vet det.
Hvorfor npm-sårbarhetsskanneren din ikke sa noe
De fleste team behandler npm-forsyningskjedesikkerhet som et sårbarhetsproblem. De kjører en npm-sårbarhetsskanner, den sammenligner avhengighetstreet deres mot databaser med kjente feil, og de fikser det den rapporterer. Det arbeidet er viktig. Det svarer bare på et annet spørsmål.
| Dimensjon | Sårbar pakke | Ondsinnet pakke |
|---|---|---|
| Hva det er | Legitim kode med en feil | Kode skrevet for å skade deg |
| Har en CVE? | Vanligvis, til slutt | Nesten aldri |
| Når det er farlig | Når feilen er tilgjengelig og utnyttet | I det øyeblikket den installeres |
| Hva fanger den | Oppslag i en sårbarhetsdatabase | Atferdsanalyse av selve pakken |
| Typisk nødvendig responstid | Dager til uker | Minutter til timer |
En sårbarhetsdatabase kan bare beskrive noe noen allerede har analysert og katalogisert. En skadelig pakke publisert for en time siden har ingen oppføring noe sted. Så skanneren returnerer feilfri, og feilfri blir lest som sikker.
Det er kjerneendringen i npm-forsyningskjeden: spørsmålet er ikke lenger «har denne pakken en kjent feil?», men «gjør denne pakken noe den ikke burde?»
Fire måter angripere kan komme seg inn i node_modules på
- Kontoovertakelse. Stjel en vedlikeholders legitimasjon eller token og publiser en forgiftet versjon av en pakke folk allerede stoler på. Dette er axios' håndbok, og den er den vanskeligste å få øye på, fordi pakkenavnet er helt riktig.
- Skrivefeil. Publiser
axoisorreqeustsog vent på en skrivefeil, en kopiering og liming fra en dårlig veiledning, eller en AI-kodingsassistent som foreslår feil navn. - Avhengighetsforvirring. Publiser en offentlig pakke med samme navn som en av dine interne pakker. Hvis registeroppsettet ditt foretrekker den offentlige, installerer du angriperens kode.
- Installer skript. Den røde tråden i nesten alt det ovennevnte. npm lar pakker kjøre
preinstallogpostinstallskript automatisk, slik at skadelig kode kjøres før noen importerer noe. CISAs veiledning om axios-kompromisset anbefaler innstillingignore-scripts=truefor precisav denne grunn.
Hvordan npm-forsyningskjedesikkerhet ser ut i praksis
Du vil ikke stoppe alle angrep med én kontroll. Du kan gjøre deg selv til et mye vanskeligere mål med en håndfull vaner:
- Commit låsefilen din og installer med
npm ci. Bygg bør installere nøyaktig det som ble gjennomgått, aldri det som ble vist i registeret den morgenen. - Deaktiver installasjonsskript som standard. Sett
ignore-scripts=trueog tillate skript bare for pakkene som virkelig trenger dem. - Omfang dine interne pakker Interne navn uten omfang er en åpen invitasjon til forvirring rundt avhengigheter.
- Sjekk opprinnelsen. npm-støtter opprinnelseserklæringer som lenker en publisert pakke til kildekoden og byggingen. En plutselig utgivelse uten dem, fra et prosjekt som vanligvis har dem, er et rødt flagg som er verdt å automatisere.
- Kombiner sårbarhetsskanning med deteksjon av skadelig programvare. Behold npm-sårbarhetsskanneren din for kjente feil, og legg til deteksjon som analyserer hva nye pakker faktisk gjør.
Den femte vanen er den de fleste lag hopper over, og det er den axios-angrepet avslørte.
Fang den skadelige pakken før den får et navn
Xygenis Tidlig varsling om skadelig programvare (MEW) skanner nye pakker i offentlige registre, inkludert npm, så snart de publiseres, og analyserer kodeoppførselen deres i stedet for å vente på en kjent signatur. Når en pakke flagges, varsles berørte brukere via e-post, meldingsplattformer eller nett.hooks, og pakken er satt i karantene, så du kan stoppe det hos deg CI/CD guardrails.
Rundt det, Xygenis open source security fanger opp resten av det de fire angrepsbanene ovenfor er avhengige av: typosquatting, avhengighetsforvirring, mistenkelige installasjonsskript og interne npm-komponenter uten omfang. Den dekker også kjente sårbarheter fra NVD-, OSV- og GitHub-råd, prioritert etter tilgjengelighet, slik at du fikser det som faktisk kan utnyttes, med automatisk pull requests for rettelsene.
MEW er inkludert i den gratis utviklerplanen. Start gratis og skann dine første npm-prosjekter på få minutter.
FAQ
Hva er npm forsyningskjedesikkerhet?
npm-sikkerhet i forsyningskjeden dekker alle risikoer som introduseres gjennom pakkene JavaScript-prosjektene dine er avhengige av: kjente sårbarheter, ondsinnede pakker, kompromitterte vedlikeholderkontoer, typosquatting og avhengighetsforvirring. Det går utover sårbarhetsskanning for å bekrefte at det du installerer er legitimt.
Oppdager en npm-sårbarhetsskanner skadelig programvare?
Vanligvis ikke. En tradisjonell npm-sårbarhetsskanner sjekker pakker mot databaser med kjente sårbarheter. En nylig publisert skadelig pakke har ingen databaseoppføring, så den består med mindre verktøyet også analyserer pakkeoppførsel.
Is npm audit nok?
npm audit er en nyttig gratis basislinje for kjente sårbarheter. Den oppdager ikke nylig publisert skadelig programvare, typosquats eller avhengighetsforvirring, og den forteller deg ikke om en sårbar funksjon faktisk er tilgjengelig fra koden din.
Hvordan vet jeg om en pakke er skadelig?
Varseltegn inkluderer installasjonsskript som laster ned eller kjører ekstern kode, obfuskert kode, nettverkskall som ikke er relatert til pakkens formål, en ny avhengighet som kildedepotet aldri refererer til, og en utgivelse uten proveniensen prosjektet vanligvis publiserer.
