- La sicurezza di npm ora ruota attorno alla gestione del rischio della supply chain attraverso vasti alberi di dipendenza, non solo alla correzione di singoli CVE.
- Strumenti come npm audit, lock files, Dependabot e controlli CI/CD lavorano insieme per rilevare e correggere pacchetti vulnerabili o obsoleti.
- Attacchi reali come il malware browser-interceptor e il worm Shai-Hulud dimostrano come i pacchetti npm compromessi possano rubare credenziali o sabotare pipeline.
- La combinazione di scansione automatizzata, gestione avanzata di account e segreti e selezione oculata dei pacchetti riduce notevolmente la probabilità di successo degli attacchi basati su npm.
Se oggi realizzi qualcosa con Node.js o TypeScript, ti troverai su un'enorme pila di dipendenze npm che non hai scritto tu e che probabilmente non leggerai mai completamente. Ciò è incredibilmente comodo per distribuire rapidamente le funzionalità, ma apre anche un'enorme superficie di attacco per minacce alla supply chain, furto di credenziali e subdole backdoor che si insinuano nelle tue app o pipeline CI/CD.
La moderna sicurezza npm non riguarda più solo "ci sono CVE noti nei miei pacchetti?" - riguarda difendersi dalle campagne di phishing che dirottano gli account dei manutentori, worm che pubblicano automaticamente versioni infette e librerie dannose che tentano di cancellare i dati di uno sviluppatore home directory o rubare le credenziali cloud. In questa guida spiegheremo come audit di sicurezza npm funziona, come rafforzare i flussi di lavoro con strumenti come npm audit, Dependabot, scanner SAST/SCA e controlli CI/CD, e cosa puoi realisticamente fare come sviluppatore quando temi che "questa piccola libreria interessante possa essere un malware".
Perché la sicurezza delle dipendenze npm è così importante
Ogni volta che corri npm install, stai importando codice di terze parti nel tuo progetto ed effettivamente fidandosi dei suoi autori con parte della tua superficie di attacco. In Node.js questa catena di fiducia può essere sorprendentemente profonda: una singola dipendenza di primo livello può attrarre centinaia di pacchetti transitivi che non hai mai scelto direttamente.
Le dipendenze vulnerabili o abbandonate possono portare a problemi di sicurezza classici come attacchi di iniezione, negazione del servizio (DoS), escalation dei privilegi o esfiltrazione di dati. Anche un piccolo bug in un'utilità di basso livello – un client HTTP, un parser di colori, un caricatore YAML – può avere un impatto significativo quando è presente in framework e strumenti diffusi.
Oltre alle vulnerabilità tradizionali, l'ecosistema deve ora fare i conti con comportamenti decisamente dannosi: pacchetti creati intenzionalmente per rubare segreti, iniettare codice di cryptomining o compromettere pipeline CI/CD. Questi non sono rischi teorici; diversi incidenti reali hanno mostrato che gli aggressori hanno preso di mira gli account dei manutentori e poi hanno utilizzato pacchetti attendibili come armi.
Mantenere le dipendenze controllate e aggiornate Non si tratta quindi di un compito igienico, ma di una parte fondamentale della manutenzione di qualsiasi progetto Node.js o TypeScript serio. Controlli di sicurezza regolari, sia automatici che manuali, sono l'unico modo per mantenere il rischio derivante da codice di terze parti a un livello accettabile.
Comprendere l'audit npm e cosa controlla effettivamente
npm audit è il comando integrato che analizza l'albero delle dipendenze del progetto confrontandolo con un database di vulnerabilità note e produce un report di sicurezza. Quando lo esegui nella radice del progetto, npm esamina il tuo package.json e file di blocco, crea il grafico completo delle dipendenze e confronta ogni versione con gli avvisi.
Il rapporto di revisione copre entrambi dipendenze dirette e indirette (i pacchetti che elenchi tu stesso e le dipendenze delle dipendenze). Per ogni problema, elenca il pacchetto interessato, un riepilogo della vulnerabilità, la sua gravità (bassa, moderata, alta, critica) e l'intervallo di versione che contiene la correzione.
Dal punto di vista del flusso di lavoro, npm audit può essere utilizzato in modo interattivo dagli sviluppatori e in modo non interattivo nelle pipeline CI/CD. Nelle pipeline è anche possibile far fallire la build solo se le vulnerabilità superano una certa soglia di gravità utilizzando flag come --audit-level.
Lo strumento appartiene alla più ampia famiglia di Analisi della composizione del software (SCA): si concentra sui problemi noti dei componenti open source piuttosto che sui bug del codice. Ciò significa che è molto efficace nell'individuare librerie obsolete o vulnerabili, ma non rileva magicamente malware nuovi di zecca distribuiti il giorno prima con un nome di pacchetto mai visto prima.
Come eseguire npm audit e interpretare i risultati
Per eseguire un controllo di sicurezza di base, apri un terminale nella radice del tuo progetto (dove package.json vite) e correre npm auditDopo una breve analisi delle dipendenze, npm produrrà una tabella dei problemi, raggruppati per gravità, insieme ai passaggi di risoluzione suggeriti, come l'aggiornamento a una versione patchata.
L'output di controllo in genere include il nome del pacchetto, la versione installata, la descrizione della vulnerabilità e gravità (bassa, moderata, alta, critica), più i percorsi che indicano in quale punto dell'albero delle dipendenze viene utilizzato il pacchetto, e una versione o un intervallo fisso consigliato. Consideralo come un elenco di cose da fare in ordine di priorità: inizia con critico e alto, poi procedi verso il basso.
Se vuoi importare i risultati in altri strumenti o memorizzarli per dopo, puoi richiedere l'output JSON tramite npm audit --jsonCiò è particolarmente utile quando si integra con dashboard personalizzate, sistemi di ticketing o piattaforme di orchestrazione della sicurezza.
Nelle pipeline CI/CD, molti team configurano la pipeline per l'esecuzione npm audit --json subito dopo l'installazione delle dipendenze, analizza il risultato e fallisce la compilazione se è presente una vulnerabilità superiore a una gravità scelta. Helper esterni come audit-ci può racchiudere questa logica per te e fornire opzioni convenienti per interrompere le build quando vengono superate le soglie.
Correzione delle vulnerabilità con npm audit fix
Quando npm audit segnala problemi, la tua prima linea di difesa è npm audit fix, che cerca di aggiornare automaticamente le dipendenze vulnerabili alle versioni più sicure. Sotto il cofano riscrive package-lock.json (E package.json ove applicabile) per spostare i pacchetti all'interno di intervalli di versione compatibili.
Questa correzione automatica funziona bene per molti problemi di lieve e media entità, e anche per alcuni di maggiore gravità, in cui la correzione è una release minore o una patch. È una soluzione rapida che spesso elimina una grossa fetta del backlog con il minimo sforzo umano.
Non tutte le vulnerabilità possono essere risolte in modo sicuro tramite un aggiornamento automatico; alcune richiedono modifiche importanti alla versione che potrebbero compromettere il codice o altre dipendenze. È qui che npm audit fix --force entra in gioco: impone gli aggiornamenti anche in caso di modifiche sostanziali, ma dovresti usarlo con cautela e testarlo sempre accuratamente in seguito.
Prima di eseguire l'opzione "force" in progetti seri, è consigliabile eseguire il commit o il backup del file di lock e assicurarsi di avere una buona copertura di test. Un aggiornamento forzato può introdurre modifiche comportamentali o regressioni più difficili da individuare se non si dispone di una baseline con cui effettuare un confronto.
File di blocco, npm ci e installazioni deterministiche
. package-lock.json file (o yarn.lock/pnpm-lock.yaml per altri gestori) è fondamentale per la sicurezza perché blocca le versioni esatte di ogni dipendenza utilizzata dal progetto. Senza di essa, ogni npm install potrebbe estrarre versioni compatibili leggermente diverse, rendendo le build non deterministiche e più difficili da verificare.
Dovresti evitare di modificare package-lock.json manualmente e lasciare che sia npm a gestirlo quando si aggiungono, rimuovono o aggiornano le dipendenze. Quando si esegue il commit del codice, includere sempre entrambi package.json e il file di blocco in modo che tutti, incluso il tuo CI/CD, installino le stesse versioni.
In ambienti automatizzati, preferire npm ci ancora npm install perché npm ci Utilizza il file di lock come un contratto rigoroso e si rifiuta di eseguire se non corrisponde alle dipendenze dichiarate. Questo produce installazioni più veloci e completamente riproducibili, che è esattamente ciò che si desidera in CI.
Dal punto di vista della sicurezza della supply chain, bloccare e riprodurre le installazioni significa sapere esattamente quali versioni sono state utilizzate per una determinata build, il che è fondamentale quando si deve verificare se una versione dannosa sia mai stata inserita nella pipeline. Se necessario, è possibile riprodurre le build utilizzando i file di blocco storici per verificare se fosse in gioco una versione vulnerabile o con backdoor.
Automazione degli aggiornamenti con Dependabot, Renovate e strumenti npm
Il monitoraggio manuale di pacchetti obsoleti o vulnerabili su molti repository diventa rapidamente ingestibile, motivo per cui l'automazione tramite strumenti come Dipendentebot o Renovate è davvero prezioso. Questi servizi monitorano le tue dipendenze e aprono richieste pull quando vengono pubblicate nuove versioni o correzioni di sicurezza.
Dependabot di GitHub, ad esempio, è configurato tramite un .github/dependabot.yml file che specifica quali ecosistemi monitorare, la frequenza di aggiornamento e i rami target. Quando rileva un pacchetto npm vulnerabile o obsoleto, crea un aggiornamento PR package.json e al package-lock.json, spesso con link ad avvisi.
Accoppiato con npm audit, si ottiene un piacevole ciclo di feedback: l'audit identifica i problemi e Dependabot (o Renovate) propone continuamente aggiornamenti per risolverli. Il tuo compito diventa quello di rivedere e testare queste pull request, piuttosto che cercare manualmente ogni singolo aggiornamento di versione.
Oltre all'automazione, npm stesso fornisce comandi di supporto come npm outdated per elencare i pacchetti con versioni più recenti e npm update per aggiornare entro gli intervalli di versione consentiti. Usati regolarmente, riducono il rischio di rimanere indietro e di dover passare da una versione all'altra contemporaneamente.
Esecuzione di controlli di sicurezza nelle pipeline CI/CD
Una configurazione NPM sicura non si limita al tuo laptop; anche le tue pipeline CI/CD devono applicare controlli di sicurezza per impedire che codice vulnerabile o dannoso raggiunga la produzione. Ogni fase – origine, build, test, distribuzione – deve prevedere controlli pertinenti.
È comune correre npm audit automaticamente durante la fase di compilazione o di pre-distribuzione, spesso con --json flag per una più facile integrazione con gli strumenti di monitoraggio. Se la scansione rileva vulnerabilità al di sopra della soglia di rischio, la pipeline potrebbe bloccarsi e il rilascio potrebbe essere bloccato.
Strumenti avanzati come Snyk Possono fungere da guardiani della sicurezza in CI/CD analizzando le dipendenze e segnalando errori nelle build quando vengono rilevati problemi gravi o critici. Combinandoli con analizzatori di qualità come SonarQube o SonarCloud, si ottiene un quadro più ampio della qualità del codice, dei rischi per la sicurezza e del debito tecnico.
Durante lo sviluppo, strumenti di analisi statica come ESLint con plugin come eslint-plugin-security e al eslint-plugin-node Aiutarti a individuare pattern non sicuri fin dalle prime fasi del tuo codice. Questo integra la scansione delle dipendenze, che si concentra sui componenti di terze parti anziché sulla logica aziendale.
Rafforzamento delle pipeline CI/CD oltre l'audit npm
Le scansioni automatiche sono potenti, ma una pipeline sicura richiede anche una solida gestione dei segreti, un solido controllo degli accessi e una buona igiene del repository. Segreti configurati in modo errato o ruoli eccessivamente permissivi possono trasformare una violazione di lieve entità in un incidente conclamato.
Utilizzare gestori segreti dedicati come Volta HashiCorp o AWS Secrets Manager invece di incorporare token o chiavi nei file di configurazione o nelle variabili di ambiente archiviate nel controllo del codice sorgente. Questo riduce la possibilità che un aggressore, o anche un collaboratore curioso, si imbatta in dati sensibili nel tuo repository.
Il controllo degli accessi basato sui ruoli (RBAC) con il principio del privilegio minimo è fondamentale per GitHub, npm e qualsiasi piattaforma CI/CD utilizzata. Sviluppatori e account di servizio dovrebbero disporre solo delle autorizzazioni di cui hanno assolutamente bisogno, niente di più.
Gli hook di pre-commit e gli strumenti di scansione dei segreti possono impedire a chiavi API, token o password di accedere ai repository. In combinazione con flussi di lavoro GitOps strutturati e branch protetti, forniscono un audit trail chiaro e riducono il rischio che modifiche non revisionate vengano unite.
Le notifiche provenienti dagli strumenti di sicurezza dovrebbero essere integrate in canali in tempo reale come Slack, Microsoft Teams o e-mail, ma regolate con attenzione in modo che il team non venga sopraffatto da avvisi di scarso valore. Dare priorità in base alla gravità e al contesto mantiene l'attenzione su ciò che conta davvero.
Attacchi alla supply chain npm nel mondo reale e cosa ci insegnano
Negli ultimi anni, npm ha assistito a diversi incidenti di alto profilo nella supply chain, in cui gli aggressori hanno preso di mira manutentori o pacchetti piuttosto che singole applicazioni. Questi attacchi evidenziano come un singolo account compromesso possa avere ripercussioni su milioni di installazioni downstream.
In una campagna, un noto responsabile di NPM ha ricevuto un'e-mail di phishing accuratamente creata da un dominio che sembrava quasi indistinguibile dal sito ufficiale di NPM. Il messaggio minacciava di bloccare l'account a meno che l'autenticazione a due fattori non fosse stata "aggiornata", attirando la vittima su una falsa pagina di accesso che catturava le credenziali.
Una volta preso il controllo dell'account npm del manutentore, l'aggressore ha distribuito versioni dannose di 18 pacchetti estremamente popolari, con miliardi di download settimanali. Poiché questi pacchetti erano profondamente radicati nel grafo delle dipendenze dell'ecosistema JavaScript, il potenziale raggio d'azione era enorme.
Il codice iniettato si è comportato come un intercettore lato browser mirato alle criptovalute e all'attività Web3: ha agganciato le API del browser come fetch, XMLHttpRequest e interfacce di portafoglio come window.ethereum o API del portafoglio Solana. Ha analizzato le risposte di rete e i payload delle transazioni alla ricerca di qualsiasi cosa che assomigliasse a un indirizzo crittografico o a un trasferimento.
Quando individuava una transazione, il malware sostituiva l'indirizzo del destinatario legittimo con uno controllato dall'aggressore, spesso scegliendo stringhe simili per evitare sospetti. In molti casi, l'interfaccia utente sembrava ancora mostrare l'indirizzo "corretto", mentre i dati firmati sottostanti erano già stati modificati per inviare fondi all'aggressore.
Il codice dannoso era pesantemente offuscato, con variabili come _0x... e grandi array di stringhe codificate e decodificate in fase di esecuzione, e a volte restituiva risposte di successo false per impedire all'applicazione di rilevare eventuali problemi. Solo alcune app erano realmente sfruttabili, in particolare quelle che interagivano con wallet o servizi di crittografia e installavano le versioni interessate entro la ristretta finestra di compromissione.
Indicazioni da quell'incidente del browser-intercettore
Una lezione chiara è che gli sviluppatori dovrebbero essere pronti a ripristinare rapidamente le versioni valide ogni volta che viene annunciata la compromissione di un pacchetto. Anche se il registro rimuove le versioni dannose, i file di blocco e le cache potrebbero comunque farvi riferimento finché non si esegue esplicitamente un downgrade o un upgrade.
Un'ispezione approfondita di package.json e al package-lock.json (o yarn.lock) è essenziale per verificare se il progetto abbia mai inserito versioni dannose. È qui che le installazioni deterministiche e i file di blocco con blocco della versione rendono il lavoro forense molto più gestibile.
Se la tua applicazione interagisce con portafogli crittografici o API Web3, dovresti monitorare attentamente i registri delle transazioni per individuare destinazioni anomale o approvazioni inaspettate nell'intervallo di tempo in cui erano presenti pacchetti compromessi. La diagnosi precoce può limitare i danni finanziari e aiutare a identificare gli utenti interessati.
Rafforzare la sicurezza degli account con l'autenticazione a due fattori, idealmente tramite chiavi hardware, è fondamentale per gli account npm e GitHub, soprattutto per i responsabili dei pacchetti più diffusi. Anche in questo caso, diffidate sempre delle email che vi invitano a cliccare su un link per "aggiornare" le credenziali; visitate invece direttamente il sito ufficiale e verificate la presenza di avvisi.
Le organizzazioni che utilizzano strumenti SCA e SBOM commerciali possono spesso interrogare i propri inventari in base al nome e alla versione del pacchetto per individuare tutti i sistemi e le applicazioni che dipendono da una libreria compromessa. Questa visibilità riduce drasticamente i tempi di risposta in caso di incidenti nella supply chain.
Il worm Shai-Hulud: malware npm autoreplicante
Un'altra campagna degna di nota, soprannominata la Campagna Shai-Hulud, ha portato gli attacchi alla supply chain di npm a un livello superiore, comportandosi come un worm autoreplicante su pacchetti e ambienti di sviluppo. Ha trasformato gli script post-installazione di npm in un'arma per eseguire logica dannosa non appena veniva installata una versione compromessa.
Il malware ha scansionato l'ambiente alla ricerca di credenziali sensibili, tra cui .npmrc file con token npm, token di accesso personali GitHub, chiavi SSH e chiavi API del provider cloud per AWS, GCP e Azure. Tutto ciò che trovava veniva esfiltrato alle infrastrutture controllate dall'aggressore.
Utilizzando token npm rubati, il worm si autenticava come manutentore compromesso, enumerava altri pacchetti di loro proprietà, iniettava il suo payload e poi pubblicava nuove versioni dannose. Questa automazione gli consentiva di diffondersi rapidamente senza che l'aggressore toccasse manualmente ogni pacchetto.
In molti casi, i segreti rubati venivano scaricati in repository GitHub pubblici di nuova creazione, sotto l'account della vittima, con nomi o descrizioni che facevano riferimento a Shai-Hulud. Ciò ha aggravato ulteriormente la situazione, esponendo dati sensibili a chiunque si imbattesse in quei repository.
I ricercatori di sicurezza hanno notato segnali rivelatori (tra cui commenti strani e persino emoji) che suggerivano che parti degli script bash dannosi fossero state generate con l'ausilio di modelli linguistici di grandi dimensioni. È un esempio lampante di come l'intelligenza artificiale generativa possa essere sfruttata per accelerare la creazione di strumenti di attacco.
Shai‑Hulud 2.0: sabotaggio preinstallato e fallback distruttivi
Un'ondata successiva, denominata Shai-Hulud 2.0, ha cambiato strategia, prevedendo l'esecuzione durante la fase di pre-installazione anziché post-installazione, espandendo notevolmente la sua portata su macchine di sviluppo e server CI/CD. Gli script di pre-installazione vengono eseguiti ancora prima nel ciclo di vita e possono essere attivati su più sistemi.
Uno degli aspetti più allarmanti di questa variante era un meccanismo di fallback: se il malware non riusciva a rubare credenziali utili o a stabilire un canale di comunicazione, tentava un comportamento distruttivo come pulendo la vittima home elencoCiò è stato possibile sovrascrivendo ed eliminando in modo sicuro tutti i file scrivibili di proprietà dell'utente corrente in quella directory.
Il payload era camuffato da utili script di installazione di Bun come setup_bun.js e un enorme, pesantemente offuscato bun_environment.js file di dimensioni superiori a 9 MB. Per evitare di attirare l'attenzione, la logica principale si è biforcata in un processo in background, in modo che l'installazione originale sembrasse terminare normalmente.
Le credenziali e i segreti raccolti da questa campagna sono stati nuovamente esfiltrati su GitHub, questa volta in repository descritti come "Sha1‑Hulud: The Second Coming", e il malware ha cercato di ottenere persistenza creando flussi di lavoro di GitHub Actions come discussion.yamlTali flussi di lavoro registravano le macchine infette come runner auto-ospitati, consentendo agli aggressori di attivare comandi arbitrari semplicemente aprendo discussioni.
La portata complessiva era enorme, toccando decine di migliaia di repository e più di 25 repository dannosi su centinaia di account GitHub, comprese librerie popolari come @ctrl/tinycolor Con milioni di download settimanali. Poiché l'obiettivo includeva il furto di credenziali per le piattaforme cloud, l'impatto a valle poteva variare dal furto di dati e ransomware al cryptomining e all'interruzione diffusa dei servizi.
Azioni difensive immediate contro i worm della supply chain npm
Quando si affrontano campagne come Shai-Hulud, chi risponde agli incidenti consiglia di ruotare immediatamente tutte le credenziali a livello di sviluppatore: token npm, PAT di GitHub, chiavi SSH e tutte le chiavi API cloud utilizzate sulle macchine degli sviluppatori o sui server di build. Supponiamo che qualsiasi cosa presente su una workstation compromessa potrebbe essere trapelata.
È essenziale un audit completo delle dipendenze in tutti i progetti, utilizzando strumenti come npm audit, inventari SBOM o piattaforme SCA commerciali per individuare qualsiasi utilizzo dei nomi e delle versioni dei pacchetti interessati. File di blocco (package-lock.json, yarn.lock) forniscono la verità di base su ciò che è stato effettivamente installato.
Gli sviluppatori dovrebbero ispezionare i propri account GitHub per individuare repository pubblici insoliti (in particolare quelli che prendono il nome da Shai-Hulud), commit sospetti o modifiche inaspettate ai flussi di lavoro di GitHub Actions che potrebbero aver registrato utenti non autorizzati. Qualsiasi anomalia dovrebbe essere considerata un segnale di compromissione.
L'applicazione dell'autenticazione a più fattori a tutti gli account degli sviluppatori, con metodi anti-phishing ove possibile, è un altro passo imprescindibile. Non elimina i rischi, ma alza il livello di difficoltà per gli aggressori che cercano di abusare delle campagne di furto di credenziali.
Le organizzazioni che utilizzano piattaforme avanzate di ricerca delle minacce possono anche sfruttare query personalizzate per cercare indicatori noti come chiamate a specifici webhook.site URL, presenza di file come shai-hulud-workflow.yml o sospettosamente grande bun_environment.js file scritti su macchine di sviluppo. Il rilevamento tempestivo tramite telemetria può ridurre drasticamente i tempi di permanenza.
Come rispondono i fornitori: capacità di rilevamento e prevenzione
I fornitori di sicurezza hanno aggiornato i loro prodotti per rilevare e bloccare gli attacchi alla supply chain basati su npm, sia a livello di endpoint che di rete. Questo include firme per payload dannosi noti e modelli comportamentali per attività insolite di processi o file durante le installazioni.
Servizi avanzati di sandboxing e analisi del malware possono segnalare payload JavaScript offuscati, come quelli utilizzati nelle campagne Shai-Hulud. Quando questi strumenti rilevano script sospetti post-installazione o pre-installazione che tentano di scoprire credenziali o distruggere file, generano avvisi o bloccano l'esecuzione.
I firewall di nuova generazione con prevenzione avanzata delle minacce e filtraggio degli URL possono aiutare bloccando l'accesso ai domini dannosi utilizzati nel phishing o nell'esfiltrazione, ad esempio falsi domini di supporto npm o specifici webhook.site endpoint codificati nel malware. Classificare questi URL come dannosi impedisce al payload di inviare correttamente i dati rubati.
Gli agenti di rilevamento e risposta degli endpoint (EDR/XDR) contribuiscono monitorando il comportamento dei processi, l'esecuzione degli script, le creazioni di file insoliti (come quelli giganti) bun_environment.js file) e righe di comando sospette. Possono bloccare sia hash noti sia varianti mai viste prima, basandosi su regole comportamentali.
Le piattaforme di sicurezza delle applicazioni cloud-native stanno aggiungendo sempre più funzionalità incentrate sulla supply chain, come la visibilità SBOM in tempo reale, il punteggio di rischio per i componenti open source e i controlli di configurazione errata CI/CD (file di blocco mancanti, non sicuri npm install utilizzo, dipendenze basate su Git senza hash di commit bloccati, dipendenze inutilizzate che espandono la superficie di attacco). Questi controlli rendono più difficile l'inserimento di versioni di pacchetti dannose o non verificate nelle build di produzione.
Abitudini pratiche per gli sviluppatori preoccupati per i pacchetti npm dannosi
Se sei alle prime armi con JS/TS e ti senti a disagio ogni volta che installi un pacchetto npm, non sei il solo: ci sono però delle abitudini concrete che puoi adottare per ridurre i rischi senza compromettere la tua produttività. Considerale come una checklist di sicurezza personale.
Per prima cosa, preferisci pacchetti consolidati con una sana cronologia di manutenzione, un sistema di tracciamento attivo dei problemi e un ampio utilizzo, soprattutto per infrastrutture core come client HTTP, logging o crittografia. Ciò non garantisce la sicurezza, ma di solito significa più controlli sul codice e un rilevamento più rapido in caso di problemi.
Per pacchetti di piccole dimensioni o poco noti (soprattutto quelli con pochissimi download), esaminateli più attentamente: controllate la pagina npm, i link ai repository, l'ultima data di pubblicazione e se il manutentore è chiaramente identificabile. Fate attenzione se il pacchetto npm rimanda a un repository GitHub che in realtà non contiene il codice pubblicato o che comunque punta a un upstream non correlato.
Se possibile, ispeziona il tarball del pacchetto pubblicato, non solo il repository sorgente, perché gli aggressori possono inviare a npm una build diversa da quella che appare su GitHub. Strumenti come npm pack combinato con la revisione manuale (anche se il codice è transpilato o minimizzato) può rivelare evidenti segnali d'allarme come strani script di installazione, blob offuscati o chiamate di rete inaspettate.
Per le librerie TypeScript che forniscono solo definizioni di tipo e JavaScript minimizzato, è più difficile eseguire un rapido audit manuale, quindi potresti decidere di utilizzarle solo dietro un sandbox rigoroso o di effettuare un fork e ricompilare dal codice sorgente se diventano critiche per il tuo stack. In alcuni contesti sensibili alla sicurezza, i team scelgono effettivamente di effettuare il fork delle dipendenze in registri privati dopo un'attenta revisione.
Rendi la sicurezza npm una routine piuttosto che un'esercitazione antincendio: esegui npm audit Elimina regolarmente le dipendenze inutilizzate, mantieni i file di lock impegnati e integra i controlli SCA/SAST nel tuo CI/CD. Combinate con una solida igiene degli account e una gestione dei segreti, queste pratiche non ti rendono invulnerabile, ma riducono drasticamente le possibilità che un'installazione casuale di npm comprometta silenziosamente i tuoi sistemi.
