Malalim na gabay sa pag-audit ng seguridad ng npm at pag-atake ng supply-chain

Home » Python » Malalim na gabay sa npm security auditing at supply-chain attacks

Kung gagawa ka ng kahit ano gamit ang Node.js o TypeScript ngayon, nakatayo ka sa ibabaw ng isang napakalaking tumpok ng mga npm dependencies na hindi mo isinulat at malamang na hindi mo kailanman mababasa nang buo. Napakadali nito para sa mabilis na pagpapadala ng mga feature, ngunit nagbubukas din ito ng malaking lugar para sa mga banta sa supply-chain, pagnanakaw ng kredensyal, at mga banayad na backdoor na palihim na pumapasok sa iyong mga app o CI/CD pipeline.

Ang modernong npm security ay hindi na tungkol sa "may mga kilalang CVE ba sa aking mga package?" - ito ay tungkol sa pagtatanggol laban sa mga kampanyang phishing na nang-hijack ng mga account ng maintainer, mga worm na awtomatikong nag-publish ng mga nahawaang bersyon, at mga nakakahamak na aklatan na sumusubok na punasan ang isang developer home direktoryo o magnakaw ng mga kredensyal sa ulap. Sa gabay na ito, aalisin namin kung paano pag-audit sa seguridad ng npm gumagana, kung paano patigasin ang iyong mga daloy ng trabaho gamit ang mga tool tulad ng npm audit, Dependabot, SAST/SCA scanner at CI/CD checks, at kung ano ang maaari mong gawin bilang isang developer kapag nag-aalala ka na “ang cool na maliit na library na ito ay maaaring malware”.

Bakit ang npm dependency security ay napakalaking bagay

Sa tuwing tatakbo ka npm install, nag-i-import ka ng third-party na code sa iyong proyekto at epektibo nagtitiwala sa mga may-akda nito na may bahagi ng iyong pag-atake sa ibabaw. Sa Node.js ang trust chain na ito ay maaaring nakakagulat na malalim: ang nag-iisang top-level na dependency ay maaaring kumuha ng daan-daang transitive package na hindi mo direktang pinili.

Ang mga mahina o inabandunang dependency ay maaaring humantong sa mga klasikong isyu sa seguridad tulad ng mga injection attack, denial of service (DoS), privilege escalation o data exfiltration. Kahit ang isang maliit na bug sa isang low-level utility – isang HTTP client, isang color parser, isang YAML loader – ay maaaring magkaroon ng malawak na epekto kapag ito ay nasa ilalim ng mga sikat na framework at tool.

Higit pa sa mga tradisyunal na kahinaan, ang ecosystem ngayon ay kailangang harapin ang tahasang malisyosong pag-uugali: mga paketeng sadyang ginawa upang magnakaw ng mga sikreto , magpasok ng cryptomining code o ikompromiso ang mga CI/CD pipeline. Hindi ito mga teoretikal na panganib; maraming insidente sa totoong buhay ang nagpakita na ang mga umaatake ay humahabol sa mga maintainer account at pagkatapos ay ginagamit ang mga pinagkakatiwalaang pakete bilang armas.

Samakatuwid, ang pagpapanatiling na-audit at napapanahon ng mga dependency ay hindi isang magandang gawain sa kalinisan, kundi isang pangunahing bahagi ng pagpapanatili ng anumang seryosong proyekto ng Node.js o TypeScript. Ang mga regular na security audit, parehong awtomatiko at manu-mano, ang tanging paraan upang mapanatili ang panganib mula sa third-party code sa isang katanggap-tanggap na antas.

Pag-unawa sa npm audit at kung ano talaga ang sinusuri nito

npm audit ay ang built-in na command na nag-scan ng dependency tree ng iyong proyekto laban sa isang database ng mga kilalang kahinaan at gumagawa ng ulat ng seguridad. Kapag pinatakbo mo ito sa ugat ng iyong proyekto, tinitingnan ng npm ang iyong package.json at lock file, bubuo ng buong dependency graph at tumutugma sa bawat bersyon laban sa mga advisory.

Saklaw ng ulat ng pag-audit ang parehong direkta at hindi direktang mga dependency (ang mga pakete na inilista mo mismo at mga dependency ng mga dependency). Para sa bawat isyu, inililista nito ang apektadong pakete, isang buod ng kahinaan, ang kalubhaan nito (mababa, katamtaman, mataas, kritikal) at ang hanay ng bersyon na naglalaman ng pag-aayos.

Mula sa pananaw ng daloy ng trabaho, npm audit maaaring magamit nang interactive ng mga developer at hindi interactive sa mga pipeline ng CI/CD. Sa mga pipeline, maaari mo lang gawin ang build na mabigo lamang kung ang mga kahinaan ay higit sa isang tiyak na threshold ng kalubhaan gamit ang mga flag tulad ng --audit-level.

Ang tool na ito ay kabilang sa mas malawak na pamilya ng Software Composition Analysis (SCA) : nakatuon ito sa mga kilalang problema sa mga open-source na component sa halip na sa mga bug sa sarili mong code. Nangangahulugan ito na napakalakas nito para sa paghuli ng mga luma o mahinang library, ngunit hindi nito mahiwagang natutukoy ang mga bagong-bagong malware na ipinadala kahapon sa ilalim ng pangalan ng package na hindi pa nakikita noon.

Paano magpatakbo ng npm audit at bigyang-kahulugan ang mga resulta

Upang magsagawa ng pangunahing pag-audit sa seguridad, magbukas ng terminal sa ugat ng iyong proyekto (kung saan package.json buhay) at tumakbo npm audit. Pagkatapos ng maikling pagsusuri sa dependency, maglalabas ang npm ng talaan ng mga isyu, na pinagsama-sama ayon sa kalubhaan, kasama ng mga iminungkahing hakbang sa remediation gaya ng pag-upgrade sa isang patched na bersyon.

Karaniwang kasama sa output ng audit ang pangalan ng package, naka-install na bersyon, paglalarawan ng kahinaan, at kalubhaan (mababa, katamtaman, mataas, kritikal) , kasama ang mga path na nagpapakita kung saan sa dependency tree ginagamit ang package, at isang inirerekomendang nakapirming bersyon o saklaw. Ituring ito bilang isang priyoridad na listahan ng mga dapat gawin: magsimula sa kritikal at mataas, pagkatapos ay magpatuloy pababa.

Kung gusto mong i-ingest ang mga resulta sa iba pang mga tool o iimbak ang mga ito para sa ibang pagkakataon, maaari kang humingi ng JSON output sa pamamagitan ng npm audit --json. Iyan ay lalong madaling gamitin kapag nagsama ka sa mga custom na dashboard, ticketing system o security orchestration platform.

Sa CI/CD pipelines, maraming team ang nagko-configure sa pipeline para tumakbo npm audit --json pagkatapos na mai-install ang mga dependency, i-parse ang resulta at mabigo ang build kung mayroong anumang kahinaan sa itaas ng napiling kalubhaan. Gusto ng mga panlabas na katulong audit-ci maaaring i-wrap ang logic na ito para sa iyo at magbigay ng mga maginhawang opsyon para masira ang mga build kapag nalampasan ang mga threshold.

Pag-aayos ng mga kahinaan gamit ang npm audit fix

minsan npm audit mga problema sa pag-flag, ang iyong unang linya ng depensa ay npm audit fix, na sumusubok na awtomatikong mag-upgrade ng mga vulnerable na dependencies sa pinakamalapit na ligtas na bersyon. Sa ilalim ng talukbong ito ay muling nagsusulat package-lock.json (At package.json kung saan naaangkop) para i-bump ang mga package sa loob ng mga katugmang hanay ng bersyon.

Ang awtomatikong remediation na ito ay mahusay na gumagana para sa maraming mababa at katamtamang isyu, at kahit para sa ilang mas mataas na kalubhaan kung saan ang pag-aayos ay isang minor o patch release. Ito ay isang mabilis na panalo na kadalasang nakakaalis ng malaking bahagi ng iyong backlog na may kaunting pagsisikap ng tao.

Hindi lahat ng kahinaan ay maaaring maayos na ligtas sa pamamagitan ng isang awtomatikong pag-upgrade; ang ilan ay nangangailangan ng malalaking pagbabago sa bersyon na maaaring masira ang iyong code o iba pang mga dependency. na kung saan npm audit fix --force pumapasok: pinipilit nito ang mga pag-upgrade kahit na sa mga paglabag sa mga pagbabago, ngunit dapat mong gamitin ito nang maingat at palaging subukang mabuti pagkatapos.

Bago patakbuhin ang opsyong puwersa sa mga seryosong proyekto, matalinong i-commit o i-back up ang iyong lock file at tiyaking mayroon kang mahusay na saklaw ng pagsubok. Ang sapilitang pag-upgrade ay maaaring magpakilala ng mga pagbabago sa gawi o regression na mas mahirap subaybayan kung wala kang baseline na ihahambing.

I-lock ang mga file, npm ci at mga deterministikong pag-install

Ang package-lock.json file (o yarn.lock/pnpm-lock.yaml para sa iba pang mga tagapamahala) ay kritikal para sa seguridad dahil pini-pin nito ang eksaktong mga bersyon ng bawat dependency na ginagamit ng iyong proyekto. Kung wala ito, bawat isa npm install maaaring humila ng bahagyang magkakaibang mga katugmang bersyon, na ginagawang hindi deterministiko ang mga build at mas mahirap i-audit.

Dapat mong iwasan ang pag-edit package-lock.json sa pamamagitan ng kamay at sa halip ay hayaan ang npm na pamahalaan ito kapag nagdagdag ka, nag-alis o nag-update ng mga dependency. Kapag gumagawa ng code, palaging isama ang pareho package.json at ang lock file upang ang lahat – at ang iyong CI/CD – ay mag-install ng parehong mga bersyon.

Sa mga awtomatikong kapaligiran, mas gusto npm ci sa ibabaw npm install dahil sa npm ci ginagamit ang lock file bilang isang mahigpit na kontrata at tumangging tumakbo kung hindi ito tumutugma sa mga ipinahayag na dependencies. Iyon ay nagbubunga ng mas mabilis at ganap na mai-reproducible na mga pag-install, na kung ano mismo ang gusto mo sa CI.

Mula sa pananaw ng seguridad ng supply-chain, ang pagla-lock at muling paggawa ng mga pag-install ay nangangahulugang alam mo kung aling mga bersyon ang ginamit para sa isang partikular na build, na mahalaga kapag kailangan mong imbestigahan kung ang isang nakakahamak na release ay nakuha sa iyong pipeline. Kung kinakailangan, maaari mong i-replay ang mga build sa pamamagitan ng paggamit ng mga makasaysayang lock file upang makita kung ang isang vulnerable o backdoored na bersyon ay nasa play.

Pag-automate ng mga update gamit ang Dependabot, Renovate at npm tooling

Ang manu-manong pagsubaybay sa mga luma o mahinang pakete sa maraming repositoryo ay mabilis na nagiging mahirap pamahalaan, kaya naman napakahalaga ng automation gamit ang mga tool tulad ng Dependabot o Renovate. Sinusubaybayan ng mga serbisyong ito ang iyong mga dependency at binubuksan ang mga pull request kapag may lumitaw na mga bagong bersyon o mga pag-aayos sa seguridad.

Ang Dependabot ng GitHub, halimbawa, ay na-configure sa pamamagitan ng a .github/dependabot.yml file na tumutukoy kung aling mga ecosystem ang panonoorin, dalas ng pag-update at mga target na sangay. Kapag nakakita ito ng mahina o hindi napapanahong npm package, lumilikha ito ng pag-update ng PR package.json at package-lock.json, madalas na may mga link sa mga advisory.

Ipares sa npm audit, makakakuha ka ng magandang feedback loop: kinikilala ng audit ang mga isyu, at ang Dependabot (o Renovate) ay patuloy na nagmumungkahi ng mga pag-upgrade upang ayusin ang mga ito. Ang iyong trabaho ay nagiging pagsusuri at pagsubok sa mga kahilingan sa paghila sa halip na hanapin ang bawat solong bersyon na bump sa pamamagitan ng kamay.

Higit pa sa automation, ang npm mismo ay nagbibigay ng mga command ng helper tulad ng npm outdated upang ilista ang mga pakete na may mas bagong bersyon at npm update upang mag-upgrade sa loob ng pinapayagang mga saklaw ng bersyon. Regular na ginagamit, binabawasan nila ang pagkakataong mahuhuli ka at kailangang tumalon ng ilang pangunahing bersyon nang sabay-sabay.

Nagpapatakbo ng mga pagsusuri sa seguridad sa mga pipeline ng CI/CD

Ang isang secure na pag-setup ng npm ay hindi hihinto sa iyong laptop; ang iyong mga pipeline ng CI/CD ay dapat ding magpatupad ng mga pagsusuri sa seguridad upang maiwasan ang mahina o malisyosong code na makarating sa produksyon. Bawat yugto – source, build, test, deploy – ay dapat may mga nauugnay na kontrol.

Karaniwang tumakbo npm audit awtomatikong sa panahon ng yugto ng pagbuo o bago ang pag-deploy, madalas na may --json flag para sa mas madaling pagsasama sa mga tool sa pagsubaybay. Kung ang pag-scan ay nakakita ng mga kahinaan sa itaas ng iyong limitasyon sa panganib, ang pipeline ay maaaring mabigo at harangan ang paglabas.

Ang mga advanced na tool tulad ng Snyk ay maaaring magsilbing security gatekeeper sa CI/CD sa pamamagitan ng pag-scan ng mga dependency at pagkabigo ng mga build kapag may nakitang mataas o kritikal na isyu. Ang pagsasama ng mga ito sa mga quality analyzer tulad ng SonarQube o SonarCloud ay nagbibigay sa iyo ng mas malawak na larawan ng kalidad ng code, mga panganib sa seguridad, at teknikal na utang.

Sa panahon ng pag-unlad, ang mga static na tool sa pagsusuri tulad ng ESLint na may mga plugin tulad ng eslint-plugin-security at eslint-plugin-node tulungan kang mahuli ang mga hindi secure na pattern nang maaga sa sarili mong code. Nakadagdag iyon sa pag-scan ng dependency, na nakatutok sa mga bahagi ng third-party kaysa sa lohika ng iyong negosyo.

Pinapatigas ang mga pipeline ng CI/CD lampas sa pag-audit ng npm

Makapangyarihan ang mga automated na pag-scan, ngunit kailangan din ng isang secure na pipeline ng matibay na lihim na pamamahala, matatag na kontrol sa pag-access at mahusay na kalinisan ng repositoryo. Ang mga maling na-configure na sikreto o masyadong mapagpahintulot na mga tungkulin ay maaaring gawing ganap na insidente ang isang maliit na paglabag.

Gumamit ng mga nakalaang secret manager tulad ng HashiCorp Vault o AWS Secrets Manager sa halip na mag-embed ng mga token o key sa mga configuration file o environment variable na naka-check sa source control. Binabawasan nito ang posibilidad na ang isang attacker, o kahit isang mausisang contributor, ay makakita ng sensitibong data sa iyong repo.

Ang kontrol sa pag-access na nakabatay sa tungkulin (RBAC) na may prinsipyo ng hindi bababa sa pribilehiyo ay mahalaga para sa GitHub, npm at anumang CI/CD platform na iyong ginagamit. Ang mga developer at account ng serbisyo ay dapat magkaroon lamang ng mga pahintulot na talagang kailangan nila – wala nang iba pa.

Ang mga pre-commit hook at secret‑scanning tool ay maaaring pigilan ang mga API key, token, o password sa pagpasok sa iyong mga repository sa simula pa lang. Kasama ng mga structured na daloy ng trabaho sa GitOps at mga protektadong sangay, nagbibigay ang mga ito ng malinaw na audit trail at binabawasan ang panganib ng hindi pa nasusuri na mga pagbabago na pinagsama.

Ang mga notification mula sa iyong security tooling ay dapat na isama sa mga real-time na channel tulad ng Slack, Microsoft Teams o email, ngunit dapat itong maingat na i-tune upang ang iyong team ay hindi mabigla ng mga low-value na alerto. Ang pagbibigay-priyoridad ayon sa kalubhaan at konteksto ay nagpapanatili ng atensyon sa kung ano ang tunay na mahalaga.

Mga pag-atake sa real‑world npm supply‑chain at kung ano ang itinuturo ng mga ito sa atin

Sa nakalipas na ilang taon, nakakita ang npm ng ilang high-profile na insidente ng supply-chain kung saan tina-target ng mga attacker ang mga maintainer o package kaysa sa mga indibidwal na application. Binibigyang-diin ng mga pag-atakeng ito kung paano maaaring magkagulo ang isang nakompromisong account sa milyun-milyong downstream na pag-install.

Sa isang campaign, ang isang kilalang npm maintainer ay nakatanggap ng maingat na ginawang phishing email mula sa isang domain na mukhang halos hindi makilala sa opisyal na npm site. Ang mensahe ay nagbanta na i-lock ang account maliban kung ang two-factor authentication ay "na-update", na umaakit sa biktima sa isang pekeng login page na nakakuha ng mga kredensyal.

Kapag nakontrol na ng attacker ang npm account ng maintainer, itinulak nila ang mga nakakahamak na bersyon ng 18 napakasikat na package na may bilyun-bilyong lingguhang pag-download. Dahil ang mga package na ito ay malalim na naka-embed sa dependency graph ng JavaScript ecosystem, ang potensyal na blast radius ay napakalaki.

Ang injected code ay kumilos tulad ng isang browser-side interceptor na naglalayon sa cryptocurrency at aktibidad sa Web3: nakakabit ito ng mga browser API tulad ng fetch, XMLHttpRequest at mga interface ng wallet tulad ng window.ethereum o mga Solana wallet API. Nag-scan ito ng mga tugon sa network at mga payload ng transaksyon para sa anumang bagay na mukhang isang crypto address o paglilipat.

Nang makakita ito ng isang transaksyon, pinalitan ng malware ang lehitimong address ng tatanggap ng isang address na kinokontrol ng umaatake, kadalasang pumipili ng magkatulad na mga string upang maiwasan ang hinala. Sa maraming kaso, ang UI ay lumalabas pa rin upang ipakita ang "tama" na address habang ang pinagbabatayan na nilagdaang data ay nabago na upang magpadala ng mga pondo sa umaatake.

Ang malisyosong code ay labis na na-obfuscated, na may mga variable tulad ng _0x... at malalaking naka-encode na string array na na-decode sa runtime, at minsan ay nagbabalik ito ng mga pekeng tugon sa tagumpay upang hindi mapansin ng application ang anumang mali. Ang ilang partikular na app lang ang tunay na pinagsamantalahan – lalo na ang mga nakipag-ugnayan sa mga wallet o serbisyo ng crypto at nag-install ng mga apektadong bersyon sa loob ng makitid na window ng kompromiso.

Patnubay mula sa insidente ng browser-interceptor na iyon

Ang isang malinaw na aral ay ang mga developer ay dapat na maging handa na bumalik nang mabilis sa mga kilalang-mahusay na bersyon sa tuwing ipahayag ang isang kompromiso sa package. Kahit na ang registry ay nag-alis ng mga nakakahamak na bersyon, ang iyong mga lock file at cache ay maaaring sumangguni pa rin sa mga ito hanggang sa tahasan mong i-downgrade o i-upgrade.

Isang masusing inspeksyon ng package.json at package-lock.json (O yarn.lock) ay mahalaga upang ma-verify kung ang iyong proyekto ay nakuha sa mga nakakahamak na bersyon. Dito ginagawang mas mapapamahalaan ng mga deterministikong pag-install at naka-pin na bersyon na mga lock file ang forensic work.

Kung ang iyong aplikasyon ay nakikipag-ugnayan sa mga crypto wallet o Web3 API, dapat mong mahigpit na subaybayan ang mga tala ng transaksyon para sa mga hindi pangkaraniwang destinasyon o hindi inaasahang pag-apruba sa loob ng panahong may mga nakompromisong pakete. Ang maagang pagtuklas ay maaaring limitahan ang pinsalang pinansyal at makatulong na matukoy ang mga apektadong user.

Ang pagpapalakas ng seguridad ng account gamit ang two-factor authentication, sa perpektong paraan sa pamamagitan ng mga hardware key, ay mahalaga para sa npm at GitHub account – lalo na para sa mga maintainer ng mga sikat na package. Kahit na noon, palaging mag-alinlangan sa mga email na humihimok sa iyo na mag-click sa isang link upang "i-update" ang mga kredensyal; sa halip, direktang mag-navigate sa opisyal na site at tingnan kung may mga alerto doon.

Ang mga organisasyong gumagamit ng komersyal na SCA at SBOM tooling ay kadalasang maaaring mag-query ng kanilang mga imbentaryo ayon sa pangalan ng package at bersyon upang mahanap ang lahat ng system at application na nakadepende sa isang nakompromisong library. Ang visibility na iyon ay kapansin-pansing nagpapaikli sa mga oras ng pagtugon kapag nangyari ang mga insidente ng supply-chain.

Ang Shai‑Hulud worm: self-replicating npm malware

Isa pang kapansin-pansing kampanya, na binansagang kampanyang Shai-Hulud , ang nagdala ng mga pag-atake sa supply-chain ng npm sa susunod na antas sa pamamagitan ng pag-uugaling parang isang self-replicating worm sa mga package at developer environment. Ginawa nitong armas ang mga npm post-install script upang magpatakbo ng malisyosong lohika sa sandaling mai-install ang isang nakompromisong bersyon.

Ini-scan ng malware ang kapaligiran para sa mga sensitibong kredensyal kabilang ang .npmrc mga file na may mga npm token, GitHub personal access token, SSH key at cloud provider API key para sa AWS, GCP at Azure. Ang anumang nahanap nito ay na-exfiltrate sa imprastraktura na kinokontrol ng umaatake.

Gamit ang mga ninakaw na npm token, nagpatotoo ang worm bilang mga nakompromisong maintainer, nag-enumerate ng iba pang package na pagmamay-ari nila, nag-inject ng payload nito at pagkatapos ay nag-publish ng mga bagong malisyosong bersyon. Pinahintulutan ito ng automation na mabilis na mag-fan out nang hindi manu-manong hinahawakan ng attacker ang bawat package.

Sa maraming kaso, ang mga ninakaw na lihim ay itinapon sa mga bagong likhang pampublikong GitHub na mga repositoryo sa ilalim ng sariling account ng biktima, na may mga pangalan o paglalarawang tumutukoy kay Shai‑Hulud. Pinalala pa nito ang isyu sa pamamagitan ng paglalantad ng sensitibong data sa sinumang nangyaring natitisod sa mga repo na iyon.

Napansin ng mga mananaliksik sa seguridad ang mga palatandaan (kabilang ang mga kakaibang komento at maging ang mga emoji) na nagmumungkahi na ang mga bahagi ng mga nakakahamak na script ng bash ay nabuo sa tulong ng malalaking modelo ng wika. Isa itong malinaw na halimbawa kung paano maaaring abusuhin ang generative AI para mapabilis ang paggawa ng attack tooling.

Shai‑Hulud 2.0: paunang i-install ang sabotage at mapanirang fallback

Ang isang mas huling wave, na tinawag na Shai‑Hulud 2.0, ay naglipat ng mga taktika upang isagawa sa yugto ng paunang pag-install sa halip na pagkatapos ng pag-install, na lubos na nagpapalawak ng abot nito sa mga developer machine at CI/CD server. Ang mga preinstall na script ay tumatakbo nang mas maaga sa lifecycle at maaaring mag-trigger sa mas maraming system.

Ang isa sa mga pinakanakaaalarma na aspeto ng variant na ito ay isang fallback na mekanismo: kung nabigo ang malware na magnakaw ng mga kapaki-pakinabang na kredensyal o magtatag ng channel ng komunikasyon, sinubukan nito ang mapanirang gawi gaya ng pinupunasan ang biktima home direktoryo. Ginawa ito sa pamamagitan ng pag-overwrit at secure na pagtanggal ng anumang mga file na maaaring isulat na pagmamay-ari ng kasalukuyang user sa ilalim ng direktoryong iyon.

Ang kargamento ay disguised bilang kapaki-pakinabang na Bun installer script tulad ng setup_bun.js at isang napakalaking, mabigat na obfuscated bun_environment.js file na lampas sa 9 MB ang laki. Upang maiwasang maakit ang atensyon, ang pangunahing lohika ay napunta sa isang proseso sa background upang ang orihinal na pag-install ay lumitaw na matapos nang normal.

Ang mga kredensyal at sikreto na nakolekta ng campaign na ito ay muling na-exfiltrate sa GitHub, sa pagkakataong ito sa mga repository na inilarawan bilang "Sha1‑Hulud: The Second Coming", at sinubukan ng malware na magkaroon ng pagpupursige sa pamamagitan ng paggawa ng mga workflow ng GitHub Actions gaya ng discussion.yaml. Ang mga daloy ng trabaho na iyon ay nagrehistro ng mga nahawaang makina bilang self-hosted na mga runner, na nagpapahintulot sa mga umaatake na mag-trigger ng mga arbitrary na utos sa pamamagitan lamang ng pagbubukas ng mga talakayan.

Napakalaki ng kabuuang saklaw, umabot sa libu-libong repositoryo at higit sa 25k malisyosong repo sa daan-daang GitHub account, kabilang ang mga sikat na aklatan tulad ng @ctrl/tinycolor na may milyun-milyong lingguhang pag-download. Dahil kasama sa layunin ang pagnanakaw ng kredensyal para sa mga cloud platform, ang downstream na epekto ay maaaring mula sa pagnanakaw ng data at ransomware hanggang sa cryptomining at malawakang pagkagambala sa serbisyo.

Mga agarang depensibong aksyon laban sa npm supply-chain worm

Kapag nahaharap sa mga kampanyang tulad ng Shai‑Hulud, inirerekomenda ng mga incident responder na agad na i-rotate ang lahat ng developer-level credentials – mga npm token, GitHub PAT, SSH key, at anumang cloud API key na ginagamit sa mga developer machine o build server. Ipagpalagay na maaaring may leak ang anumang bagay na nasa isang nakompromisong workstation.

Ang isang buong pag-audit ng dependency sa lahat ng mga proyekto ay mahalaga, gamit ang mga tool tulad ng npm audit, mga imbentaryo ng SBOM o komersyal na SCA platform upang mahanap ang anumang paggamit ng mga apektadong pangalan at bersyon ng package. I-lock ang mga file (package-lock.json, yarn.lock) magbigay ng ground truth para sa kung ano ang aktwal na naka-install.

Dapat suriin ng mga developer ang kanilang mga GitHub account para sa mga kakaibang pampublikong repositoryo (lalo na pinangalanan sa Shai‑Hulud), mga kahina-hinalang commit o hindi inaasahang pagbabago sa mga workflow ng GitHub Actions na maaaring nagrehistro ng mga hindi awtorisadong runner. Ang anumang mga anomalya ay dapat ituring bilang mga palatandaan ng kompromiso.

Ang pagpapatupad ng multi-factor na pagpapatotoo sa lahat ng developer account – na may mga paraan na lumalaban sa phishing kung posible – ay isa pang hindi mapag-usapan na hakbang. Hindi nito inaalis ang panganib, ngunit pinapataas nito ang antas para sa mga umaatake na sumusubok na abusuhin ang mga kampanyang pagnanakaw ng kredensyal.

Ang mga organisasyong gumagamit ng mga advanced na platform sa pangangaso ng pagbabanta ay maaari ding gumamit ng mga custom na query para maghanap ng mga kilalang indicator gaya ng mga tawag sa partikular na webhook.site Mga URL, pagkakaroon ng mga file tulad ng shai-hulud-workflow.yml o kahina-hinalang malaki bun_environment.js mga file na nakasulat sa mga developer machine. Ang maagang pagtuklas mula sa telemetry ay maaaring makabuluhang bawasan ang oras ng tirahan.

Paano tumutugon ang mga vendor: mga kakayahan sa pagtuklas at pag-iwas

Ang mga security vendor ay nag-a-update ng kanilang mga produkto upang makita at harangan ang npm-focused supply-chain attacks sa endpoint at sa network. Kabilang dito ang mga lagda para sa mga kilalang malisyosong payload at mga modelo ng asal para sa hindi pangkaraniwang proseso o aktibidad ng file sa panahon ng mga pag-install.

Maaaring i-flag ng mga advanced na serbisyo sa pagsusuri ng sandboxing at malware ang mga na-obfuscate na JavaScript payload gaya ng mga ginamit sa mga campaign ng Shai‑Hulud. Kapag nakakita ang mga tool na ito ng mga kahina-hinalang post-install o preinstall na script na sumusubok sa pagtuklas ng kredensyal o pagsira ng file, magtataas sila ng mga alerto o hinaharangan ang pagpapatupad.

Makakatulong ang mga susunod na henerasyong firewall na may advanced na pag-iwas sa pagbabanta at pag-filter ng URL sa pamamagitan ng pagharang ng access sa mga nakakahamak na domain na ginagamit sa phishing o exfiltration – halimbawa, mga pekeng domain ng suporta sa npm o partikular webhook.site mga endpoint na na-hard-code sa malware. Ang pag-uuri sa mga URL na ito bilang nakakahamak ay pumipigil sa payload na matagumpay na magpadala ng ninakaw na data.

Ang mga ahente ng endpoint detection and response (EDR/XDR) ay nag-aambag sa pamamagitan ng pagsubaybay sa gawi ng proseso, pagpapatupad ng script, hindi pangkaraniwang paglikha ng file (tulad ng higanteng bun_environment.js file) at mga kahina-hinalang command line. Maaari nilang ihinto ang parehong mga kilalang hash at dati nang hindi nakikitang mga variant batay sa mga panuntunan sa pag-uugali.

Ang mga platform ng seguridad ng cloud-native na application ay lalong nagdaragdag ng mga feature na nakatuon sa supply-chain tulad ng real-time na visibility ng SBOM, risk scoring para sa open-source na mga bahagi at CI/CD misconfiguration checks (nawawalang lock file, hindi ligtas npm install paggamit, mga dependency na nakabatay sa Git na walang naka-pin na commit na mga hash, mga hindi nagamit na dependency na nagpapalawak sa ibabaw ng pag-atake). Ang mga kontrol na ito ay ginagawang mas mahirap para sa mga nakakahamak o hindi pa natukoy na bersyon ng package na makapasok sa mga production build.

Mga praktikal na gawi para sa mga developer na nag-aalala tungkol sa mga nakakahamak na npm packages

Kung bago ka sa JS/TS at hindi mapalagay sa tuwing nag-i-install ka ng npm package, hindi ka nag-iisa – ngunit may mga konkretong gawi na maaari mong gawin upang mapababa ang panganib nang hindi nagyeyelo sa iyong pagiging produktibo. Isipin ang mga ito bilang isang personal na checklist ng seguridad.

Una, mas gusto ang mga mahusay na naka-establisadong pakete na may maayos na kasaysayan ng pagpapanatili , aktibong tagasubaybay ng isyu at malawak na paggamit, lalo na para sa mga pangunahing imprastraktura tulad ng mga HTTP client, pag-log o crypto. Hindi nito ginagarantiyahan ang kaligtasan, ngunit kadalasan ay nangangahulugan ito ng mas maraming mata sa code at mas mabilis na pagtuklas kung may magkamali.

Para sa maliliit o hindi malinaw na mga pakete (lalo na ang mga halos walang pag-download), suriing mabuti ang mga ito: tingnan ang pahina ng npm, mga link sa repositoryo, huling petsa ng pag-publish, at kung malinaw na nakikilala ang tagapangasiwa. Mag-ingat kung ang npm package ay nagli-link sa isang GitHub repo na hindi talaga naglalaman ng na-publish na code o tumuturo pa rin sa isang hindi nauugnay na upstream.

Kung posible, siyasatin ang na-publish na package tarball, hindi lang ang source repository, dahil ang mga attacker ay maaaring magpadala ng ibang build sa npm kaysa sa kung ano ang lumalabas sa GitHub. Mga tool tulad ng npm pack na sinamahan ng manu-manong pagsusuri (kahit na ang code ay na-transpiled o pinaliit) ay maaaring magpakita ng mga halatang pulang flag tulad ng kakaibang mga script sa pag-install, na-obfuscated na mga blobs o hindi inaasahang mga tawag sa network.

Para sa mga TypeScript library na nagpapadala lamang ng mga kahulugan ng uri at pinaliit na JavaScript, mas mahirap gumawa ng mabilis na manu-manong pag-audit, kaya maaari kang magpasya na gamitin lamang ang mga ito sa likod ng mahigpit na sandboxing o mag-fork at muling buuin mula sa pinagmulan kung magiging kritikal ang mga ito sa iyong stack. Sa ilang kontekstong sensitibo sa seguridad, pinipili talaga ng mga team na i-fork ang mga dependency sa mga pribadong rehistro pagkatapos ng masusing pagsusuri.

Gawing routine ang npm security kaysa fire-drill: run npm audit regular, linisin ang mga hindi nagamit na dependency, panatilihing naka-commit ang iyong mga lock file, at isama ang mga pagsusuri sa SCA/SAST sa iyong CI/CD. Kasama ng matibay na kalinisan ng account at lihim na pamamahala, ang mga kagawiang ito ay hindi gumagawa sa iyo na hindi masusugatan, ngunit sila ay lubhang binabawasan ang mga pagkakataon na ang isang random na pag-install ng npm ay tahimik na makompromiso ang iyong mga system.