En skrivefeil i package.json lar en lik pakke kompromittere Pipeline

En feil på ett tegn som sendte skadelig programvare

Det startet med en skrivefeil. Et sted i den massive strømningen av funksjonsutgivelser og PR-sammenslåinger skrev noen @utils_core istedenfor @utils-core inn pakke.jsonDen ene tegnfeilen ga ikke noen feil. I stedet trakk den stille inn en ondsinnet liknende pakke i løpet av det neste CI/CD kjøre, og utnytte tillit i festede versjoner og automatisering. Velkommen til typosquatting-verdenen i åpen kildekode.

Typosquatting: Angrepsvektoren som trives på menneskelige feil

Typosquatting er akkurat hva det høres ut som: ondsinnede aktører registrerer pakker med navn som er nesten identiske med legitime. I fartsfylte miljøer fungerer dette fordi utviklere stoler på at deres pakke.json og package-lock.json gjenspeiler hva de forventer. Én karakter forskjellig? Det kan like gjerne være usynlig i en PR-forskjell.

NPM har en historie med å bli utnyttet gjennom typosquatting. Pakker som kryssmiljø istedenfor kryssmiljø or hendelsesstrøm Bakdører har allerede vist hvor effektive disse kopiene kan være. Disse falske pakkene består ofte anmeldelser rett og slett fordi de ser riktige ut og ikke gir umiddelbare kjøretidsfeil.

Vanlige feller inkluderer:

Bindestrek vs. understrek: lodash-kjerne vs lodash_core
Flertall: anmode vs forespørsler
Erstatte tegn: uttrykkelig istedenfor ekspress

Der package-lock.json blir en blindsone

Utvikleren retter skrivefeilen sin. Det tror de i hvert fall. Men nå, package-lock.json har allerede låst inne angriperens pakke. Og det er her den virkelige risikoen skjuler seg.

I motsetning til pakke.json, som redigeres manuelt og får mer gransking, package-lock.json er automatisk generert av NPMSom et resultat blir det ofte behandlet som en formalitet, hoppet over eller bare oversett. pull request anmeldelser. Det er ikke uvanlig at lag merker det som «for støyende» eller stoler implisitt på det uten å se nærmere på det.

Angripere vet dette. De er avhengige av det. En gang en ondsinnet pakke er referert til, takket være en skrivefeil i pakke.json, pakkelås.json registrerer den løste versjonen. Selv om skrivefeilen korrigeres senere, kan den ondsinnede oppføringen vedvare med mindre låsefilen eksplisitt genereres på nytt.

For å gjøre vondt verre, kan versjonslåsing, som skal sikre konsistens, slå tilbake. Angripere kan versjonere den falske pakken sin identisk med den legitime. Hvis CI/CD Hvis systemet stoler blindt på festede versjoner, vil det ikke oppdage at det installerer en pakke med et kjent fungerende versjonsnummer, men fra en annen, ondsinnet kilde.

Denne stille utholdenheten er det som gjør package-lock.json så farlig. Det sikrer deterministiske bygg, ja, men det garanterer også at en dårlig pakke blir værende med mindre den oppdages og renses ut manuelt.

CI/CD: Der skadevaren treffer – package.json

I et typisk CI/CD pipeline, trenger ikke den skadelige pakken å vente til kjøretid. Den blir løst og utløst mye tidligere i flyten:

Avhengighetsoppløsning
Ocuco pipeline henter de nøyaktige avhengighetsversjonene fra package-lock.json, som nå inkluderer typosquatted-pakken på grunn av skrivefeilen i pakke.json.

Installasjonsfasen
Under npm ci installeres alle avhengigheter, inkludert den skadelige. Ingen advarsler, ingen spørsmål, bare stille installasjon.

Utførelse av skript etter installasjon
Lookalike-pakken inneholder et etterinstallasjonsskript som kjører automatisk når installasjonen er fullført. Det er her kompromitteringen skjer.

Eksempel på pseudokode:

				
					if (installation_phase_active) {
runHiddenPayload()
}

Pseudokodebeskrivelse:
Hvis kroken for etterinstallasjonslivssyklusen er til stede i løpet av installasjonsfasen, utløser den falske pakken sin skjulte logikk – ofte før bygg eller tester i det hele tatt kjører. Dette kan innebære å foreta eksterne forespørsler, injisere bakdører eller andre uautoriserte handlinger.

⚠️ Advarsel: Denne pseudokoden er kun for demonstrasjonsformål og må ikke brukes i virkelige miljøer.

Ingen varsler utløses. Ingenting feiler. Miljøet er allerede kompromittert, før din pipeline når til og med teststadiet.

Finn forskjellen før det er for sent

En vanlig feil: å anta pakke.json forteller hele historien. Det gjør den ikke. Den virkelige kraften ligger i kombinasjonen av pakke.json + pakkelås.json.

Her er hva du skal se etter:

Har package-lock.json inkludere uventede pakker?
Er noen avhengigheter hentet fra ukjente registre, eller har de rare omfang?
Er versjonsnumrene for spesifikke eller feiljusterte?

Bruk CLI-verktøy som:

npm revisjon å flagge kjente problemer
npm ls for å se hele avhengighetstreet
diff å sammenligne versjoner mellom pakke.json og package-lock.json

Herd din PipelineForsvar som fungerer

For å forsvare seg mot typosquatting:

Håndhev omfangsbegrensninger i pakke.json.
Legg til forhåndssammenslåing hooks å linte og validere avhengigheter.
Bruk npm ci for å unngå utilsiktet versjonsforskyvning.
Skann regelmessig package-lock.json for anomalier.

Og aller viktigst: behandle ubekreftede oppføringer i package-lock.json som potensielle risikoer. Hver commit bør behandles som et kontrollpunkt i forsyningskjeden.

Automatisert deteksjon: Hvordan verktøy som Xygeni hjelper

Selv om det ikke er en mirakelkur, er automatiserte verktøy som Xygeni spiller en kritisk rolle i å redusere den menneskelige feilfaktoren som typosquatting trives med. Xygeni integreres direkte i DevOps-arbeidsflyten din, og legger til et lag med sanntidsbeskyttelse mot avhengighetskapring før den i det hele tatt når kjøring.

Slik hjelper Xygeni:

Gjenkjenning av mistenkelig pakkenavn:
Bruker smarte heuristikker for å oppdage typosquatting-mønstre i pakke.json, og ser etter mindre variasjoner i kjente pakkenavn (som understrekninger, transposisjoner eller bokstavbytter).
Ukjent hash-verifisering:
Sammenligner hashen til hver avhengighet i package-lock.json mot en database med kjente, fungerende artefakter fra pålitelige registre. Selv om et pakkenavn og en versjon ser bra ut, utløser en hash-avvik et rødt flagg.
Blokkering før byggingen:
Avskjærer og blokkerer installasjon av ubekreftede eller mistenkelige pakker før de når installasjons- eller etterinstallasjonsfasene i CI/CD pipeline.
Analyse av avhengighetsgraf:
Inspiserer kontinuerlig hele avhengighetstreet for indirekte typosquatting-forsøk eller ondsinnede transitive avhengigheter.
Varsler og rapportering:
Gir detaljerte, handlingsrettede varsler som viser hva som ble flagget, hvorfor og hvor det kom fra i avhengighetskjeden.

Etter hvert som pakkeøkosystemer blir mer komplekse, blir verktøy som Xygeni viktige. Manuell gjennomgang skaleres ikke med avhengighetsspredning eller rask iterasjon. Xygeni griper inn for å automatisere de kritiske kontrollene i moderne tid. pipelines behov, og lukke gapet mellom tillit og verifisering.

Én karakter. Reelle konsekvenser.

Dette var ikke eksotisk zero-dayDet var en skrivefeil. Ett feilplassert tegn i pakke.json, stille forsterket av package-lock.json, og skadelig programvare ble sendt automatisk under en rutinemessig CI/CD løpe.

Det er den virkelige faren med typosquatting: det trenger ikke kompleksitet. Det utnytter fart, tillit og automatisering. Dette kompromisset kunne vært forhindret med de riktige kontrollene på plass:

Automatisert skanning for å fange opp mistenkelige pakkenavn og versjoner før installasjon.
Låsefilrevisjon for å oppdage ureviderte eller uventede oppføringer i package-lock.json.
Navneverifiseringsheuristikker å flagge nesten-treff med pålitelige pakker.

Ett tegn var alt som skulle til. De riktige kontrollene ville ha stoppet det før det berørte deg pipelineTillit er ikke nok. I moderne DevSecOps verifiserer du alt, eller risikerer alt.