Modo corretto per correggere la potenziale vulnerabilità della sicurezza in una dipendenza definita in package-lock.json


90

Github mi ha fornito questo errore su uno dei miei repository.

We found a potential security vulnerability in one of your dependencies.
A dependency defined in ./package-lock.json has known security vulnerabilities 
and should be updated.

La dipendenza non è definita nel nostro package.jsonfile. A quanto mi risulta non è buona norma eliminare il package-lock.jsonfile e rigenerarlo. Tuttavia, non riesco a vedere nessun altro modo per risolvere questo problema. Se elimino questa vulnerabilità di sicurezza, apparirà di nuovo un paio di giorni dopo. Qualche idea? Grazie!



Risposte:


68

Novità: ora, con npm @ 6 puoi eseguire direttamente

npm audit fix

Vecchia risposta:

Dovresti provare a identificare il nome del pacchetto problematico e quindi eseguire

npm install package-name

in sostituzione del nome del pacchetto, ovviamente.

Questo installerà l'ultima versione del pacchetto e, molto spesso, l'ultima versione ha risolto il problema di sicurezza. Se hai un vincolo sulla versione (ad esempio: 1.2), puoi sempre provare a:

npm install package-name@^1.2

e verrà installata l'ultima versione con patch


1
... e per "identificare il nome del pacchetto problematico" puoi eseguire npm ls vulnerability-name. Questo elenca i dipendenti dalla vulnerabilità, che puoi quindi aggiornare / installare. (come accennato in modo piuttosto poco chiaro nella risposta di @ RileyManda)
Sjeiti

1
npm audit fix risolve in modo pulito questo problema per me ora.
Kaito

9
Si aggiungerà package-namein dependenciessu package.json. Non lo voglio.
slideshowp2

7

Per risolvere questo problema:

Soluzione 1: prima trova la vulnerabilità: usando il tuo terminale: cd nel tuo progetto , quindi esegui "npm ls hoek"

E infine: npm install bcrypt @ latest

Quindi spingere il progetto aggiornato su git. (Cioè eseguire un nuovo commit).

Soluzione 2:

se la prima opzione / soluzione non risolve il problema, cambia la versione manualmente nel tuo package-lock.json. Cambia la tua versione manualmente da 2.16.3 a 4.2.1

"hoek": {
      "version":  "4.2.1",
      "resolved": "https://registry.npmjs.org/hoek/-/hoek-4.2.1.tgz",
      "integrity": "sha1-ILt0A9POo5jpHcRxCo/xuCdKJe0=",
      "dev": true

Quindi aggiorna il tuo progetto su GitHub (commit / push) Assicurati solo che ogni occorrenza di versione hoek nella tua versione package-lock.json sia cambiata in 4.2.1

In alternativa, se riesci a trovare un modo per cambiare la versione di hoek / aggiornare hoek usando npm, renderà le cose molto più semplici. (Qualcosa come: npm update @ hoek..version ) .. o disinstalla la dipendenza specifica quindi reinstallala usando bower o npm.


4

Stavo avendo lo stesso problema con una vulnerabilità di sicurezza lodash, in un progetto che stavo costruendo con il filo. Github li ha contrassegnati come problemi di sicurezza.

Ho provato la risposta da @rileymanda sopra, usando un terminale: cd nel progetto, quindi esegui npm ls lodash .

Questo ha scoperto che nel mio caso l'errore era in script di reazione . Google veloce per problemi con gli script di reazione e lodash ha scoperto che si trattava di un problema noto.

Ho provato varie cose da risolvere tramite il filo, tutte senza successo. npm ls lodashmostrava ancora la versione vulnerabile di lodash in uso.

Dopo aver letto il blog di Matt Turnbull sui miglioramenti a npm, sono passato da filato a npm. (Elimina yarn.lock, elimina ./node_modules. Esegui npm install).npm ls lodashora mostrava le ultime versioni delle dipendenze in uso - evviva! Impegnato in GitHub, ed era ora felice che la vulnerabilità fosse svanita.

Sembra che il filo stia lottando per risolvere tali problemi (o non è destinato a farlo).

Se riscontri questo problema quando costruisci con il filo, prova a tornare [indietro] a npm!


3

A quanto mi risulta, non è buona norma eliminare il file package-lock.json e rigenerarlo.

Tuttavia, questo è ciò che di solito viene fatto in questo caso.
Vedere ad esempio angular / angular-cli issue 8534 , che è stato risolto da PR 8535 .
Questo porta un progetto dipendente frees-io/freestyle-opscenter-webclientad aggiornare il proprio package-lock.json: PR 31 .


La rigenerazione di package-lock.json sembra non risolvere il problema
xianshenglu

@xianshenglu OK, lascio lì la risposta nel caso in cui aiuti gli altri.
VonC

Ricevo l'avviso per un blocco del pacchetto in un vecchio commit. Come diavolo posso aggiustare qualcosa nella storia senza riscriverla?
pishpish

@destoryer che non so: prova a fare una nuova domanda con maggiori dettagli (sistema operativo, versione di npm, ...)
VonC

1
Questo ha risolto il mio problema. Grazie per il consiglio.
Rich


1

vulnerabilità di sicurezza note e dovrebbe essere aggiornato.

Dal 23 maggio 2019, ora hai " Dependabot: correzioni automatiche per la sicurezza "

Grazie all'integrazione di Dependabot, abbiamo rilasciato correzioni automatiche di sicurezza come beta pubblica.

Le correzioni automatiche della sicurezza sono richieste pull generate da GitHub per correggere le vulnerabilità della sicurezza.
Automatizzano una parte noiosa del flusso di lavoro e rendono facile per gli sviluppatori mantenere aggiornate le loro dipendenze.

Per ulteriori informazioni, vedere " Configurazione di correzioni automatiche per la sicurezza "

Nota: le correzioni automatiche per la sicurezza sono disponibili nella versione beta e sono soggette a modifiche.

È possibile abilitare correzioni di sicurezza automatiche per qualsiasi repository che utilizza avvisi di sicurezza e il grafico delle dipendenze.
Abiliteremo automaticamente le correzioni di sicurezza automatiche in ogni repository che utilizza avvisi di sicurezza e il grafico delle dipendenze nei prossimi mesi, a partire da maggio 2019.


Ho avuto risultati contrastanti con quel bot. Preferisco fare manualmente npm audite / o npm audit fix.
Fuhrmanator

@ Fuhrmanator OK. Hai menzionato medium.com/coinmonks/… in un commento precedente?
VonC

0

Questo funziona per me. disinstalla tutte le tue dipendenze e installalo di nuovo

Per esempio

da package.json vedi l'elenco delle tue dipendenze

{
"name": "ebook-saler",
  "version": "1.0.0",
  "description": "App for selling ebooks",
  "main": "app.js",
  "scripts": {
    "start": "node app.js"
  },
  "author": "Md Shayon",
  "license": "ISC",
  "dependencies": {
    "body-parser": "^1.19.0",
    "express": "^4.17.1",
    "express-handlebars": "^3.1.0",
    "hoek": "^6.1.3",
    "stripe": "^7.5.0"
  }
}

Segui il comando per questo

npm uninstall body-parser express express-handlebars hoek stripe
npm install body-parser express express-handlebars hoek stripe
git commit -m "updated"
git push

0
  1. Su GitHub, vai alla pagina principale del repository.
  2. Sotto il nome del tuo repository, fai clic su Sicurezza.
  3. Fai clic sull'avviso che desideri visualizzare.
  4. Esamina i dettagli della vulnerabilità e, se disponibile, la richiesta pull contenente la correzione automatica della sicurezza.
  5. Facoltativamente, se non è già presente una correzione automatica della sicurezza per l'avviso, per creare una richiesta pull per risolvere la vulnerabilità, fare clic su Crea correzione automatica della sicurezza.
  6. Quando sei pronto per aggiornare la tua dipendenza e risolvere la vulnerabilità, unisci la richiesta pull.

Vedi i dettagli


0

prova npm audit fix, risolverà molti avvisi

poi npm i [package.name]@xxx

per esempio:

"dependencies": {
  "lodash": ">=4.17.13"
}

npm i lodash@4.17.13

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.