Questo è il terzo episodio di a serie di articoli sul tipo più diffuso di attacchi alla catena di fornitura del software: quelli che abusano di un registro pubblico di open-source componenti software. Dopo aver analizzato nella puntata precedente”Anatomia dei pacchetti dannosi: quali sono le tendenze?" come i malintenzionati inseriscono comportamenti dannosi in componenti pubblicati nuovi o esistenti, siamo pronti a indossare le nostre giacche antincendio ed esaminare come possiamo bloccare con successo il software dannoso distribuito in questo modo o, in alternativa, affrontare un incidente informatico potenzialmente grave perché abbiamo preso l'approccio sbagliato.
La maggior parte dei professionisti attenti alla sicurezza hanno idee su come gestire questa minaccia. Abbiamo sentito responsabili della sicurezza dire senza esitazione che SCA gli strumenti ti dicono già quando una versione del pacchetto è un malware. O che dipendono da componenti software noti e altamente recensiti, dove qualsiasi malware verrebbe prontamente rilevato e rimosso. Utilizzano versioni minori/patch aperte per ottenere automaticamente correzioni di vulnerabilità, e questo è il modo corretto e consigliato per ridurre il rischio sulle dipendenze open source, seguendo il "rattoppare presto, rattoppare spesso"Principio.
In questo episodio esamineremo il motivo per cui queste idee sono sbagliate e il modo in cui tali idee sbagliate contribuiscono alla popolarità di questo meccanismo di attacco e al rischio enorme che le organizzazioni stanno affrontando. Concluderemo con ciò che funziona e quali sono gli sforzi e le risorse coinvolte.
Idee sbagliate comuni
Durante il nostro viaggio con la sicurezza del software, abbiamo visto l'evoluzione delle tecniche di attacco e un'ampia gamma di idee da parte di persone attente alla sicurezza. Le organizzazioni spesso fraintendono ciò che funziona contro questa minaccia, quindi per prima cosa esamineremo ciò che non funziona, condensato nel seguente elenco, non esaustivo, di idee sbagliate.
Idea sbagliata n. 1: SCA gli strumenti segnalano già componenti dannosi
Infatti! Ma dopo il fatto… Quando probabilmente è troppo tardi se l'elemento è stato utilizzato in una build di software e i malintenzionati hanno già messo piede in uno sviluppatore o CI/CD host. I segreti potrebbero essere stati esfiltrati, potrebbe essere stato scaricato e installato altro malware, e forse l'avversario si è spostato lateralmente e ha già ottenuto l'accesso altrove.
Analisi della composizione del software (SCA) sono stati progettati per identificare potenziali vulnerabilità note. Gli strumenti moderni svolgono un ottimo lavoro aumentando il rapporto segnale-rumore, determinando se la vulnerabilità è effettivamente raggiungibile o sfruttabile. Ma sono inutili contro nuovi malware. Pensa a un componente dannoso come a una vulnerabilità zero-day: solo quando viene rilevato il suo comportamento dannoso, il componente viene segnalato al registro di holding, che dopo una revisione da parte di un team di sicurezza viene confermato come dannoso e rimosso dal registro [1].
A quel punto, il mondo (compreso SCAs) sa che installare o usare il componente (o alcune versioni di un componente esistente) non è una buona cosa. Ma questo è quando il componente non è disponibile dal registroSapere di avere vulnerabilità in componenti di terze parti, o anche componenti che sono stati classificati come dannosi dal registro è positivo, ma sfortunatamente SCA oppure gli strumenti di audit comuni non sono utili in questo contesto. A meno che il SCA/lo strumento di audit può realmente sapere in anticipo che un componente è dannoso prima che venga utilizzato nella tua organizzazione.
Ricorda, qualsiasi soluzione contro componenti open source dannosi deve rilevarli al volo, tra il momento in cui il componente viene pubblicato nel registro e il momento in cui il componente (versione) viene utilizzato per la prima volta nell'organizzazione. E questo include componenti transitivi.
Idea sbagliata n. 2: il controllo degli script di installazione in fase di creazione impedisce comportamenti dannosi da parte dei componenti open source
Vari gestori di pacchetti offrono la possibilità di eseguire script (inclusi nel componente tarball [2]), per motivi legittimi, come la compilazione di elementi richiesti su piattaforme diverse, la generazione di codice o l'esecuzione di test, e dovremmo tutti sapere che possono essere abusati da malintenzionati se nel file tar sono inclusi script dannosi o se l'aggressore può effettuare un attacco dannoso script eseguito invece di quello corretto.
Sapendo questo, possiamo configurare il gestore pacchetti per ignorare gli script. Ad esempio, con NPM il –Ignore-scripts flag (o una proprietà di configurazione nel file .npmrc file) salta gli script durante l'installazione. Ciò potrebbe produrre alcuni problemi perché l'esecuzione di script è comune in molti ecosistemi: alcuni gestori di pacchetti non consentono nemmeno la disabilitazione dell'esecuzione degli script (suggerimento: prompt "Quali gestori di pacchetti non consentono di disabilitare l'esecuzione degli script di installazione?" nella tua IA preferita). Ma questo non protegge in generale (dobbiamo imporre che la configurazione di disabilitazione del salto sia ovunque).
E quando il comportamento dannoso non è localizzato negli script di installazione ma nel software da eseguire in fase di runtime, questa opzione da sola non ci protegge.
Idea sbagliata n. 3: il blocco della versione impedisce l'installazione di componenti dannosi
Esiste un compromesso tra l'applicazione anticipata e frequente delle patch versioni aperte (permettendo al gestore pacchetti di installare automaticamente nuovi aggiornamenti quando disponibili per correzioni di sicurezza) e blocco della versione (avendo tutte le dipendenze dirette e transitive per un software in versione fissa). I principi di sicurezza sono ostinati e talvolta contraddittori, come accade con “patch early, patch even” e “L'aggiornamento non dovrebbe essere preso alla leggera”. Alcuni gestori di pacchetti effettuano aggiornamenti automatici con intervalli di server nel modo consigliato. Ottimo se vuoi ricevere anche gli aggiornamenti dannosi! Sì, i componenti devono essere aggiornati per ricevere soluzioni di sicurezza che risolvano le vulnerabilità il prima possibile, ma… non lasciare mai che il gestore dei pacchetti lo faccia automaticamente.
Idea sbagliata n. 4: l'utilizzo di componenti attendibili è sicuro. Qualsiasi versione dannosa verrà immediatamente trovata, divulgata e rimossa.
Perché un componente è attendibile? Forse perché è molto popolare, con molti occhi puntati alla ricerca di vulnerabilità, un gran numero di collaboratori per la manutenzione, con più responsabili della manutenzione del core che esaminano diligentemente tutti pull requests. La realtà è molto diversa. Alcuni componenti essenziali sono gestiti da un singolo sviluppatore non retribuito. I framework ampiamente utilizzati hanno alcuni contributori abituali, con un numero in rapida diminuzione di commits per manutentore (i progetti popolari hanno una lunga coda di contributori che eseguono alcuni drive-by commit e non tornare mai più). E abbondano i progetti popolari con un unico manutentore.
Immagina di dire "Oh, stiamo utilizzando immagini Spring Boot / Angular / React / PyTorch / Docker di base ufficiali, quindi il rischio di cui parli è piuttosto basso." Forse è vero, noi fornitori di sicurezza allarmiamo continuamente e interferiamo con i team di sviluppo per mitigare un rischio discutibile non ha senso. Potresti essere tentato di saltare al paragrafo sull'accettazione del rischio (nella sezione successiva) e tutto è fatto. Sfortunatamente, i componenti più popolari sono obiettivi di cattivi attori e, ad esempio, di quelli popolari La libreria PyTorch è stata attaccata in passato.
“Prontamente ritrovato, divulgato e rimosso”. Sono necessari giorni prima che un nuovo componente dannoso venga rimosso dal registro pubblico. I registri sono cauti nel rimuovere una versione del componente, per il bene. In base alla nostra esperienza, una volta segnalato da parte nostra, il tempo medio impiegato dal registro per rimuovere la versione interessata è di 39 ore, più di un giorno e mezzo. Sono presenti componenti dannosi che si trovano una settimana dopo la nostra segnalazione iniziale nel registro prima della rimozione. E in alcuni casi, il componente viene rimosso solo dopo che una vittima o una società di risposta agli incidenti segnalano un incidente che coinvolge il componente.
Cosa NON funziona contro i componenti dannosi
Qualsiasi approccio non specifico fallirà miseramente. Questa è una certezza, non stai fornendo contromisure efficaci per il rischio associato a questa minaccia.
Classici SCA strumenti ti informano sui malware noti ma hanno una finestra di esposizione ampia. A meno che non eseguano in modo proattivo il rilevamento del malware con il blocco forzato dei componenti dannosi, non funzionano contro questa minaccia.
La disabilitazione degli script di installazione potrebbe essere d'aiuto, ma deve essere applicata ovunque sia necessario installare un componente. Lo stesso vale per il blocco della versione, poiché le versioni non possono essere bloccate per sempre da uno stato iniziale sicuro.
Supporre che i componenti più diffusi ricevano abbastanza attenzione da non poter essere sottoposti a comportamenti involontari in un attacco alla catena di fornitura senza un rilevamento quasi istantaneo per prevenire eventuali danni è ingenuo e rischioso. Non vuoi vivere al limite, vero?
Se ti fermi a questo punto, allora accettazione del rischio è l'unica cosa che puoi fare: questa è una decisione che deve essere documentato nel tuo modello di minaccia/valutazione del rischio, inclusa la motivazione per accettare il rischio e le sue potenziali implicazioni. Aumenta la consapevolezza comunicandolo alla direzione e ad altre parti interessate. Alcuni contingenza potrebbe essere pianificato quando un componente dannoso viene installato o incluso nel software, ma questo è difficile perché gli aggressori hanno molti percorsi da seguire. I dettagli di un attacco alla catena di fornitura basato sull'uso di un componente dannoso cambieranno drasticamente la divulgazione pubblica dell'incidente, che probabilmente è obbligatoria secondo il quadro normativo della tua organizzazione. Puoi anche rivolgerti controlli compensativi or rischio di trasferimento ad esempio con l'assicurazione.
Tuttavia, esistono controlli che affrontano la minaccia e dovrebbero essere presi in considerazione se non si è soddisfatti dell’accettazione del rischio. Per favore continua a leggere.
Cosa funziona contro gli attacchi che utilizzano componenti dannosi
Gestione della versione solida
Il blocco della versione con bump di versione controllati e informati è la strada da percorrere, per bilanciare la necessità di rimuovere le vulnerabilità senza ricevere malware. Ma ricorda l'equivoco n. 3: il solo blocco della versione non è sufficiente per bloccare il codice dannoso proveniente dalle nuove versioni, perché in futuro sarà necessario aggiornare le versioni in qualsiasi dipendenza diretta o indiretta. In quel momento hai bisogno di prove sufficientemente forti che tutte le versioni modificate non contengano malware.
Allerta precoce
Un approccio al problema dei componenti dannosi è un sistema di allarme rapido (qui denominato come Avviso tempestivo di malware o MEW), in cui le nuove versioni pubblicate (per componenti nuovi o esistenti) vengono analizzate da un motore di rilevamento, che quando vengono trovate prove sufficienti può classificare la nuova versione come potenzialmente dannosa.
L'automazione è essenziale in questo caso, poiché è impossibile rivedere manualmente tutti i nuovi componenti all'attuale ritmo di pubblicazione. Quindi il motore di rilevamento deve combinare una varietà di tecniche, magari includendo analisi statiche, dinamiche e di capacità, reputazione dell'utente e prove provenienti da discrepanze tra i metadati del componente e il contenuto del tarball, o tra il tarball e il repository di origine in cui il componente presumibilmente viene da.
C'è un zona oscura tra il momento della pubblicazione e il momento in cui il motore analizza il contenuto del componente, ma non deve superare alcuni minuti. Lo schema può essere modificato, ad esempio aspettando che i nuovi componenti vengano analizzati prima di consentirne l'installazione e l'utilizzo nella build del software pipelines, o analizzarli su richiesta quando necessario. Un componente in una determinata versione è immutabile [3], quindi deve essere analizzato una sola volta.
L'automazione completa non è possibile ed è necessaria una revisione della sicurezza per componenti potenzialmente dannosi. Attenzione ai sostenitori della panacea digitale: L'intelligenza artificiale e l'apprendimento automatico non sono sufficientemente sviluppati per avere l'ultima parola quando si tratta di confermare se un componente sospetto contiene malware. Certo, l'apprendimento automatico gioca un ruolo chiave nel motore di rilevamento nel classificare il componente di input dalle prove grezze acquisite, ma una volta che il componente viene "messo in quarantena" l'ultima parola spetta alla revisione manuale da parte di un team di sicurezza con esperienza in componenti dannosi. Ciò conferma qualsiasi potenziale malware o lo riclassifica come sicuro. E il periodo di tempo è compreso nell'intervallo di ore.
Il registro segnala la versione/componente dannoso; il registro effettua quindi la propria revisione di conferma e procede alla divulgazione al pubblico e alla cancellazione dal registro. Alcuni registri mantengono un pacchetto di sicurezza. L'intervallo di tempo qui corrisponde ai giorni o alle settimane trascorsi dalla pubblicazione, ovvero il 'tempo di permanenza' o 'finestra di esposizione' per la maggior parte dei componenti dannosi.
È possibile sapere se la versione di un componente è dannosa?
Quindi, per avvisare tempestivamente, dobbiamo dare una risposta soddisfacente a questa domanda: come posso sapere se una libreria o un pacchetto è (non) dannoso? Come raccogliere prove sufficienti di comportamenti dannosi? Possibile, ma difficile, poiché gli avversari usano molta ingegnosità per evitare di essere scoperti. Esistono diversi approcci, ognuno con pro e contro.
Analisi statica può esaminare tutti i percorsi di esecuzione, verificare la presenza di tecniche utilizzate dagli aggressori senza eseguire il componente ed eseguire attività di preelaborazione come deoffuscamento o decifrazione. Poiché gli aggressori cercano di nascondere le loro malefatte, i tentativi di offuscamento sono in effetti la prova della presenza di malware (ma tieni presente che i componenti legittimi offuscano il codice per preservare la proprietà intellettuale, contraddicendo “open source”). Solo una minoranza di attacchi altamente sofisticati con offuscamento forte necessita di sandboxing, ma un offuscamento così forte è un segno rivelatore di malizia. Si noti che gli attacchi convenzionali SAST Gli strumenti sono stati progettati per vulnerabilità involontarie, non per scopi malevoli come le backdoor.
Analisi dinamica esegue il componente ed esamina la risposta strumentando il runtime, in genere fornendo un ambiente sandbox. I comportamenti dannosi attivati in determinate condizioni potrebbero non essere rilevati: tieni presente che il malware può utilizzare tecniche di evasione come Virtualizzazione/evasione sandbox da attivare solo quando non è sotto controllo e anche un segnale rivelatore di attività dannosa per qualsiasi motore di analisi statica.
Analisi delle capacità considera cosa fa il componente: dove si connette, a quali file accede, quali comandi o programmi vengono eseguiti, l'I/O del terminale o del dispositivo eseguito o quali chiamate di sistema vengono invocate. Questa impronta digitale del comportamento potrebbe essere confrontata (per un componente esistente) tra versioni diverse, quindi quando viene rilevato un comportamento imprevisto, tale prova potrebbe sollevare il sospetto di potenziali attività dannose inserite nella nuova versione. Questo approccio segue le fasi di triage seguite dagli analisti della sicurezza quando si trovano di fronte a potenziali malware: un'ispezione mediante stringhe o strumenti simili. Questo approccio rileva comportamenti dannosi indipendentemente dalle condizioni di attivazione e funziona quando non è disponibile alcun codice sorgente.
Analisi del contesto raccoglie informazioni su come il componente è stato pubblicato e da chi. Le campagne dei malintenzionati spesso utilizzano nuovi account utente non soggetti ad alcun rigido processo di verifica. Il monitoraggio dell'attività passata può fornire informazioni sull'utente sottostante, soprattutto per anomalie che potrebbero suggerire una potenziale compromissione. La reputazione è così difficile da guadagnare e così facile da perdere! Un utilizzatore senza attività passate è neutrale, ma il karma perseguita chi è malevolo. Gli hacktivisti o gli utenti normali a cui sono state rubate le credenziali di pubblicazione dovrebbero essere monitorati attentamente.
Un'altra informazione contestuale è qualsiasi discrepanza tra il repository sorgente presumibilmente utilizzato per creare il componente tarball e il contenuto del tarball stesso. E anche seguendo buone pratiche, come creare tag o versioni nel repository dei sorgenti che corrispondano alle versioni del componente pubblicate nel registro pubblico. Quando il repository di origine in un particolare commit è contrassegnato con release, e poi all'improvviso una versione non riesce a seguirlo, questo da solo è una prova evidente che il componente potrebbe essere contaminato: il malintenzionato potrebbe aver compromesso l'account utilizzato per pubblicare il componente, ma non ha autorizzazioni di scrittura nel codice sorgente deposito). Molti attacchi vengono regolarmente rilevati utilizzando queste regole: ad esempio, the Attacco al registro potrebbero essere facilmente rilevati lungo queste linee. L'analisi del contesto, quindi, individua tali anomalie nel processo editoriale.
Firewall delle dipendenze
Un approccio diverso consiste nell'avere una whitelist completa di componenti per tutti i grafici delle dipendenze utilizzati nel software, quindi in qualsiasi build pipeline eseguito nella tua organizzazione è possibile installare e utilizzare solo le versioni dei componenti approvate. IL "firewall" viene applicato utilizzando un registro interno in cui vengono serviti i tarball per le versioni dei componenti consentiti (memorizzati nella cache o tramite proxy). Tieni presente che qualsiasi whitelist non funzionerà a meno che tu non disponga della tecnologia per classificare qualsiasi nuova versione come ragionevolmente sicura in modo che possa essere aggiunta alla whitelist.
Tieni presente che l'avviso precoce (rilevamento rapido il più presto possibile dopo la pubblicazione della nuova versione) deve essere combinato con un modo per utilizzare tali informazioni in modo proattivo per bloccare il componente che influenza la build pipelines o le macchine degli sviluppatori [4]. Lo chiamiamo “firewalling delle dipendenze”: un meccanismo di quarantena per proteggere le build automatizzate da pacchetti dannosi. I pacchetti interni e i registri delle immagini sono utili per isolare le organizzazioni dal male esterno, ma sono necessarie prove sufficientemente forti per rendere efficace la quarantena.
Sandboxing in fase di esecuzione
Un approccio alternativo per il rilevamento in fase di pubblicazione consiste nell'analizzare il comportamento in fase di esecuzione. L'idea è quella di catturare il comportamento previsto dal software e rilevare (o bloccare) eventuali anomalie riscontrate. Questa linea di azione ha il problema di dover strumentare il runtime per il monitoraggio o il blocco, ed è un'idea promettente che verrà aggiunta all'arsenale di meccanismi di protezione contro il componente dannoso.
Definizione di una strategia globale
La strategia consigliata deve combinare diverse tecniche nel processo di sviluppo del software, assumendo il controllo degli aggiornamenti di versione per bloccare i componenti dannosi in entrata. Dobbiamo consentire il blocco della versione per evitare l'infezione automatica con l'aggiornamento delle versioni per ottenere correzioni per le vulnerabilità che contano; una valutazione rapida ed efficiente delle dipendenze dirette e indirette durante gli aggiornamenti delle versioni per avere prove sufficienti che non siano infestate da malware. Le build di software che dipendono da componenti dannosi noti devono essere bloccate. E tutto deve essere applicato.
Utilizzare il blocco della versione, quando possibile, poiché rende le build più riproducibili. Bloccaggio della versione con bump della versione controllati e approvati manualmentee assistito dalla tecnologia helper, dovrebbe valutare se l'aggiornamento introduce malware o danneggia il software e conciliare l'aggiornamento per correggere le vulnerabilità con l'evitare l'infezione da malware. Gli strumenti possono aiutare in questo caso, (1) dando la priorità a quali vulnerabilità contano davvero (raggiungibili e sfruttabili, con un alto rischio di essere presi di mira da aggressori), (2) selezionando le versioni di destinazione che sono compatibili con gli utilizzi correnti dei componenti e non interrompono il software, (3) scegliendo versioni di destinazione che non contengano comportamenti dannosi e (4) rendendo l'aggiornamento della versione per le dipendenze dirette e indirette un gioco da ragazzi, suggerendo modifiche nei file manifest che potrebbero essere approvate rapidamente. Il passaggio (3) richiede informazioni specifiche sui componenti dannosi il più vicino possibile al momento della loro pubblicazione.
Questo processo di aggiornamento delle dipendenze deve essere forzata and verificato in tutti i luoghi. Il processo deve essere documentato e tutte le parti coinvolte devono essere formate, poiché spesso lo sviluppo e la compilazione/distribuzione del software vengono esternalizzati. CI/CD pipelines dovrebbero essere modificati di conseguenza, in modo che l'automazione non consenta a una dipendenza indiretta dannosa di scivolare nella build: guardrails bloccare la build se ci sono prove sufficienti di potenziale malware in una dipendenza è la strada consigliata da percorrere.
Se la tua organizzazione dispone di un registro interno che funge da proxy di sicurezza per conservare le versioni dei componenti consentiti, devi ottenere informazioni sui componenti dannosi (oltre ad altri criteri) per esaminare un componente richiesto prima di aggiungerlo all'elenco consentito.
Utilizzare software open source in tutta sicurezza non è facile e il fattore malware deve essere tenuto pienamente in considerazione, con uno sforzo simile profuso nella gestione delle vulnerabilità.
Un'ultima nota: Provenienza della fonte, sotto forma di attestazioni software, generate al momento della creazione del componente, è un altro elemento chiave nel tentativo di tracciare l'artefatto (tarball del componente) con i sorgenti e il processo di creazione che lo ha prodotto. Tieni presente che questo collegamento tra l'istantanea di origine + l'ambiente di compilazione e l'artefatto software associato (firmato dal sistema di compilazione attendibile) non impedisce di per sé che il componente non contenga comportamenti dannosi, ma rende più difficile per i malintenzionati iniettare malware . E rendere la convalida della provenienza un requisito comune per il consumo di componenti open source richiederà molto tempo, e solo poco tempo recentemente aggiunto a NPM. Rendere i sistemi di creazione e distribuzione affidabili a prova di manomissione o consentire il rilevamento di eventuali manomissioni nella build è una storia diversa, che esula dall'ambito di questo post.
Ulteriori letture
Il prossimo episodio Pacchetti dannosi open source: l'approccio Xygeni presenterà la strategia che seguiamo a Xygeni per il nostro Avviso tempestivo di malware (MEW). Le nuove versioni dei pacchetti nel pacchetto pubblico e nei registri delle immagini vengono scansionate e le prove vengono ottenute utilizzando una combinazione di analisi statica, dinamica, funzionalità e contestuale. Le prove, combinate con la reputazione degli utenti e la cronologia dei cambiamenti nei repository del codice sorgente, consentono una classificazione completamente automatizzata di un componente in categorie ad alto rischio e probabilmente dannose. Il sistema impara dalle prove passate raccolte dai pacchetti per ridurre al minimo i falsi positivi.
Le organizzazioni iscritte ricevono una notifica di avviso per i componenti che utilizzano, direttamente o indirettamente, quando viene classificata una versione dannosa. Quindi viene effettuata un'analisi manuale dai nostri analisti, che conferma o rifiuta la classificazione. Per il malware confermato, viene inviata una notifica al registro pubblico in modo che possa eseguire la propria analisi e in genere rimuovere la versione dannosa o intraprendere azioni aggiuntive, come il blocco o la rimozione dell'account utente in questione.
Spiegheremo come stiamo aiutando NPM, PyPI, GitHub e altre infrastrutture chiave nell'ecosistema open source a ridurre il tempo di permanenza in cui un nuovo componente dannoso pubblicato rimane attivo finché non viene confermato malware e rimosso dal registro. E come le organizzazioni possono trarre vantaggio dal sistema MEW per avere una protezione molto migliore contro gli attacchi alla catena di fornitura del software che coinvolgono componenti open source.
- [1] In ogni caso, gli utenti del componente devono verificare se il tarball del componente è memorizzato nella cache o registrato da qualche parte, ad esempio in un registro interno, in modo che la malattia venga debellata.
- [2] Il componente confezionato include un manifest che ne dichiara i contenuti e i metadati, il codice sorgente o compilato, gli script di installazione e gli elementi aggiuntivi come le suite di test, secondo un formato di confezionamento e tipicamente in forma compressa. Questo è chiamato “component tarball”.
- [3] Anche se l'autore malintenzionato può modificare un componente pubblicato a causa di una violazione del registro stesso, un semplice digest crittografico può rilevare qualsiasi modifica nel tarball dopo aver eseguito l'analisi.
- [4] Ricorda che alcuni componenti dannosi vengono eseguiti al momento dell'installazione, quindi possono influenzare i nodi degli sviluppatori che eseguono involontariamente "npm install X" con X un componente dannoso.
