TL; DR
Trovare le vulnerabilità dei pacchetti npm è facile. npm audit Lo fa in quattro secondi e ti consegna 400 risultati. La parte difficile sta nelle prossime due domande: quali di queste sono effettivamente raggiungibili nella tua applicazione e quale aggiornamento risolve il problema senza compromettere la build.
- La maggior parte delle cose elencate non ti riguarda. Applicando la raggiungibilità e il contesto di runtime ai risultati "critici", solo una piccola parte rimane critica. L'analisi del grafo delle chiamate è ciò che ti dice quali.
npm audit fix --forcenon è una strategia risolutiva. Risolve gli avvisi saltando le versioni principali, ed è così che un'attività di sicurezza si trasforma in un'interruzione del servizio.- Le dipendenze transitive sono il luogo in cui risiede il volume. Non li hai scelti tu, spesso non puoi potenziarli direttamente e dominano il conteggio dei ritrovamenti.
- Correggi prima dell'unione, non dopo il rilascio. Un gate in CI e un automatizzato pull request costa minuti. Una patch di produzione costa un fine settimana.
Perché il numero di ritrovamenti non è il problema
Ogni progetto Node che supera il primo anno offre la stessa esperienza. Si esegue una scansione, si ottengono centinaia di vulnerabilità nei pacchetti npm e l'elenco è talmente lungo che la reazione razionale è chiudere il terminale.
Quella reazione è corretta, ed è proprio questo l'aspetto scomodo. Quasi tre quarti dei codebase contengono componenti open source ad alto rischio, e la maggior parte di ciò che uno scanner segnala in un dato giorno è effettivamente presente nella struttura delle dipendenze. L'elenco è accurato. Semplicemente, non è una lista di cose da fare.
La differenza tra un elenco accurato e uno utilizzabile sta nel contesto, e tutto si riduce a una manciata di domande.
- Il codice vulnerabile è effettivamente raggiungibile dalla mia applicazione?
- Qualcuno sta sfruttando questa vulnerabilità in modo indiscriminato?
- L'aspetto in questione è rilevante per l'azienda?
Uno scanner che non sa rispondere a queste domande ti consegna un inventario e lo chiama rapporto.
Come verificare la presenza di vulnerabilità nei pacchetti npm
Esistono quattro metodi pratici per verificare la presenza di vulnerabilità nei pacchetti npm, e ognuno di essi risponde a domande diverse.
Inizia con npm audit perché non costa nulla e richiede pochi secondi. Non fermarti lì, perché la risposta che dà è "ecco tutto", e non tutto è un piano.
Una cosa che vale la pena sapere se ci si affida ai feed di avvisi: il GitHub Advisory Database contiene avvisi di malware per l'ecosistema npm, ma Dependabot non genera deliberatamente avvisi per questi, perché un utente a valle di solito non può risolverli con un aggiornamento. Questa è una lacuna strutturale, non un'impostazione che si può attivare. I pacchetti dannosi necessitano di un controllo diverso: il rilevamento alla pubblicazione piuttosto che dopo la divulgazione. Xygeni's Avviso tempestivo di malware analizza i pacchetti appena pubblicati su npm, PyPI, Maven e altri registri nel momento stesso in cui appaiono, utilizzando l'analisi comportamentale e delle anomalie anziché attendere una firma, ed è incluso nel piano Developer gratuito. Ne parliamo in maligno Pacchetti npm.
I filtri che trasformano 400 risultati in una lista ristretta
Questa è la parte che cambia il modo in cui lavora una squadra.
| Filtra | La domanda a cui risponde | Ciò che in genere rimuove |
|---|---|---|
| raggiungibilità | È effettivamente possibile, all'interno della mia applicazione, raggiungere la funzione vulnerabile? | Il taglio più grande. La maggior parte degli avvisi si trova nel codice che l'applicazione non chiama mai. |
| Disponibilità di sfruttamento | Esiste un exploit pubblico funzionante, e viene attualmente sfruttato in circolazione? | Separa il rischio teorico dal rischio sfruttabile. Una scoperta con una vulnerabilità pubblica ha la precedenza, indipendentemente dal suo punteggio di gravità. |
| Probabilità di sfruttamento (EPSS) | Qual è la probabilità che si verifichi uno sfruttamento in natura nei prossimi 30 giorni? | Risultati di elevata gravità che nessuno sta sfruttando, che raramente riguardano il lavoro di questa settimana |
| Contesto aziendale | Il servizio interessato è rilevante ed è esposto a rischi? | Risultati accessibili e sfruttabili in sistemi che non comportano rischi significativi |
| Disponibilità fissa | Esiste una versione che risolva questo problema senza causare malfunzionamenti? | Consente di distinguere ciò che si può chiudere oggi da ciò che richiede una soluzione alternativa. |
- raggiungibilità Questo è il primo e più importante filtro. Una vulnerabilità in un pacchetto da cui dipendi è sfruttabile solo se l'esecuzione può effettivamente raggiungere la funzione vulnerabile. Il tracciamento del grafo delle chiamate risponde a questa domanda a livello di funzione, anziché basarsi sul manifesto, e distingue i componenti che utilizzi effettivamente da quelli semplicemente presenti. L'analisi di raggiungibilità di Xygeni riduce i falsi positivi fino al 70%.
Disponibilità di sfruttamento Il secondo punto è un dato di fatto, non una previsione. Un exploit pubblico funzionante, o uno sfruttamento confermato in natura, cambia la priorità di una vulnerabilità, indipendentemente dal suo punteggio di gravità. Questa distinzione ha smesso di essere una buona prassi ed è diventata un obbligo: in base al Cyber Resilience Act, un produttore che viene a conoscenza di una vulnerabilità attivamente sfruttata nel suo prodotto ha 24 ore di tempo per segnalarla. Un programma che non è in grado di distinguere tra "attivamente sfruttata" e "CVSS elevato" non può rispettare tale termine.
La probabilità di sfruttamento è il terzo fattore, e si tratta della stessa domanda con la previsione reinserita. L'EPSS valuta la probabilità che una vulnerabilità venga sfruttata in natura nei prossimi 30 giorni, il che è una questione ben diversa da quanto grave sarebbe la situazione se ciò accadesse. Un punteggio CVSS elevato con un punteggio EPSS trascurabile raramente è il risultato di un lavoro di questa settimana.
- Contesto aziendale È la terza, ed è quella che nessun feed generico può fornire. Una vulnerabilità accessibile e sfruttabile in un servizio di pagamento online non è la stessa cosa di una vulnerabilità CVE rilevata in uno strumento di segnalazione interno.
Applicati insieme, questi filtri trasformano regolarmente un elenco che nessuno legge in un elenco che qualcuno completa. Il contesto di runtime e di raggiungibilità in genere lascia tale che solo una piccola minoranza di risultati "critici" rimanga tale. Xygeni tratta la raggiungibilità, la disponibilità di exploit, EPSS e il contesto aziendale come fasi configurabili in un imbuto di prioritizzazione, fino a otto, in modo che "raggiungibile e attivamente sfruttato" diventi una coda permanente anziché una query eseguita manualmente.
Correggere le vulnerabilità del pacchetto npm senza interrompere la build.
Trovare le vulnerabilità è la parte più semplice. Il motivo per cui le vulnerabilità dei pacchetti npm rimangono irrisolte per mesi è che correggerle comporta dei rischi, e gli sviluppatori lo sanno.
La domanda fondamentale prima di qualsiasi aggiornamento non è "questo aggiornamento risolve la CVE?", bensì tre: quali vulnerabilità scompaiono con questa versione, quali ne introducono di nuove e il passaggio a questa nuova versione compromette la compatibilità del mio codice?
Xygeni mostra tutti e tre per ogni dipendenza vulnerabile, quindi la scelta è tra opzioni visibili piuttosto che un salto. Quindi Autofix genera il pull request con la versione patchata, la correzione in blocco applica più correzioni in un'unica azione e il Bot Xygeni viene eseguito su richiesta, su pull requests o quotidianamente, in modo che l'arretrato si riduca senza che nessuno lo pianifichi.
Nel caso di dipendenze transitive, dove non è possibile semplicemente aggiornare una versione non scelta, l'output utile è il percorso di aggiornamento più breve nell'albero che risolve l'avviso, non un avviso che segnala una vulnerabilità in un pacchetto situato quattro livelli più in basso.
Prima della spedizione: dove va l'assegno
"Prima della spedizione" è un'affermazione relativa alla programmazione, e si riduce a tre posizionamenti.
- Nell'IDEPertanto, lo sviluppatore individua il problema al momento della scelta della dipendenza, che è il momento più economico per modificarla.
- Sulla pull requestdove un bot commenta indicando cosa è cambiato e apre la correzione, e dove un gate di sicurezza può far fallire una build in caso di vulnerabilità che superano una determinata soglia. Il blocco basato esclusivamente sulla gravità è ciò che spinge i team a disabilitare il gate. Il blocco basato su vulnerabilità raggiungibili e sfruttabili è ciò che li spinge a mantenerlo.
- Continuamente dopo il rilascio, Perché una dipendenza che era integrata al momento dell'unione diventa vulnerabile il giorno in cui viene pubblicato un avviso. Il monitoraggio continuo dei registri è ciò che permette di individuare questo problema, senza che nessuno debba ricordarsi di eseguire una nuova scansione.
E l'output di tutti e tre appartiene a una coda prioritaria insieme al tuo SAST, segretie risultati del contenitore, inclusi quelli acquisiti dagli strumenti che già utilizzi. elenco delle vulnerabilità che risiede nella sua console è una lista che compete per l'attenzione con il lavoro che avrebbe dovuto informare.
Invia la soluzione, non la scoperta.
Uno scanner che ti segnala 400 vulnerabilità nei pacchetti npm non ha fatto il lavoro. Lo ha solo spostato.
Xygeni restringe i risultati delle dipendenze in base alla raggiungibilità, alla probabilità di sfruttamento e al contesto aziendale, mostra cosa corregge ogni aggiornamento e cosa potrebbe rompere e apre il pull request con la versione patchata. Funziona nel tuo pipeline, produce SBOM e l'output VDR in SPDX e CycloneDX, le prove richieste da CRA, NIS2 e DORA, e inserisce i risultati delle dipendenze nella stessa coda prioritaria del resto del rischio, inclusi i risultati degli scanner che non si intendono sostituire.
Inizia gratis e scansionare un repository, oppure vedere come la raggiungibilità modifica l'elenco.
FAQ
Come faccio a verificare la presenza di vulnerabilità nei pacchetti npm?
Correre npm audit Per una visualizzazione immediata, è possibile utilizzare uno strumento con analisi di raggiungibilità per restringere l'elenco ai casi in cui il codice vulnerabile può effettivamente essere richiamato. Database di avvisi come OSV e il GitHub Advisory Database sono utili per verificare un pacchetto e una versione specifici.
Is npm audit fix è sicuro correre?
La versione non forzata è generalmente sicura, poiché rimane entro intervalli compatibili con semver. npm audit fix --force Non è così: si aggiorna tra le versioni principali per risolvere gli avvisi, ed è da lì che provengono le modifiche incompatibili.
Perché ho così tante vulnerabilità nei pacchetti npm?
Perché la maggior parte di esse sono transitive. Si installano alcune dipendenze dirette e se ne ereditano centinaia indirette, ognuna con la propria cronologia di configurazione. Il volume è normale. È la fase di triage che manca.
Che cos'è l'analisi di raggiungibilità?
Determinare se l'esecuzione nella tua applicazione può effettivamente raggiungere la funzione vulnerabile in una dipendenza. È il singolo strumento di riduzione del rumore più importante disponibile nella sicurezza delle dipendenze, perché la maggior parte delle vulnerabilità segnalate si trova in codice che la tua applicazione non chiama mai.
Devo usare CVSS o EPSS per stabilire le priorità?
Entrambi, per scopi diversi. Il CVSS descrive la gravità di una vulnerabilità se sfruttata. L'EPSS stima la probabilità che lo sfruttamento avvenga nei prossimi 30 giorni. La gravità senza la probabilità produce una coda ordinata secondo l'asse sbagliato.
Con quale frequenza dovrei controllare i pacchetti npm per individuare eventuali vulnerabilità?
Continuamente, non a intervalli regolari. Una scansione senza problemi il lunedì non significa nulla il mercoledì se viene emesso un avviso per un pacco già spedito.
