Właściwy sposób na naprawienie potencjalnej luki w zabezpieczeniach w zależności zdefiniowanej w pliku package-lock.json

Github podał mi ten błąd w jednym z moich repozytoriów.

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.

Zależność nie jest zdefiniowana w naszym package.jsonpliku. W moim rozumieniu usuwanie package-lock.jsonpliku i jego ponowne generowanie nie jest dobrą praktyką . Nie widzę jednak innego sposobu rozwiązania tego problemu. Jeśli odrzucę tę lukę w zabezpieczeniach, pojawi się ona ponownie kilka dni później. Jakieś pomysły? Dzięki!

Nowość: teraz z npm @ 6 możesz bezpośrednio biec

npm audit fix

Stara odpowiedź:

Powinieneś spróbować zidentyfikować nazwę pakietu powodującego problem, a następnie uruchomić

npm install package-name

oczywiście zastępując nazwę pakietu.

Spowoduje to zainstalowanie najnowszej wersji pakietu i bardzo często najnowsza wersja rozwiązuje problem bezpieczeństwa. Jeśli masz ograniczenie dotyczące wersji (np .: 1.2), zawsze możesz spróbować:

npm install package-name@^1.2

i zostanie zainstalowana najnowsza poprawiona wersja

Aby rozwiązać ten problem:

Rozwiązanie 1: Najpierw znajdź lukę: użyj terminalu: cd do swojego projektu , a następnie uruchom "npm ls hoek"

I na koniec: npm install bcrypt @ latest

Następnie wypchnij zaktualizowany projekt do git (tj. Wykonaj nowe zatwierdzenie).

Rozwiązanie 2:

jeśli pierwsza opcja / rozwiązanie nie rozwiązuje problemu, zmień wersję ręcznie w pliku package-lock.json. Zmień ręcznie wersję z 2.16.3 na 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

Następnie zaktualizuj swój projekt na GitHub (zatwierdzenie / wypychanie) Po prostu upewnij się, że każde wystąpienie wersji hoek w Twojej wersji package-lock.json zostało zmienione na 4.2.1

Alternatywnie, jeśli możesz znaleźć sposób na zmianę wersji hoek / aktualizację hoek za pomocą npm, znacznie uprości to. ( Npm update @ hoek..version ) .. lub odinstaluj określoną zależność, a następnie zainstaluj ją ponownie za pomocą bower lub npm.

Miałem ten sam problem z luką w zabezpieczeniach typu lodash w projekcie, który budowałem z przędzy. Github oznaczył je jako zagrożenie bezpieczeństwa.

Spróbowałem odpowiedzi z @rileymanda powyżej, używając terminala: cd do projektu, a następnie uruchom npm ls lodash.

To ujawniło, że w moim przypadku błąd był w skryptach reagowania . Szybka wyszukiwarka Google w przypadku problemów ze skryptami reagowania i zgłaszania problemów ujawniła, że ​​jest to znany problem.

Próbowałem różnych rzeczy naprawić za pomocą przędzy - wszystko bez powodzenia. npm ls lodashnadal pokazywał podatną wersję lodash w użyciu.

Po przeczytaniu bloga Matta Turnbulla o ulepszeniach npm przełączyłem się z powrotem z przędzy na npm. (Usuń yarn.lock, usuń ./node_modules. Uruchom npm install). npm ls lodashteraz pokazał najnowsze używane wersje zależności - hurra! Zaangażował się w github i był teraz szczęśliwy, że luka zniknęła.

Wygląda na to, że przędza ma problemy z rozwiązywaniem takich problemów (lub nie jest to zamierzone).

Jeśli napotykasz ten problem podczas budowania z włóczki, spróbuj przełączyć [z powrotem] na npm!

W moim rozumieniu usuwanie pliku package-lock.json i jego ponowne generowanie nie jest dobrą praktyką.

Jednak tak się zwykle dzieje w tym przypadku.
Patrz na przykład kwestia kątowa / kątowa-CLI 8534 , którą rozwiązuje PR 8535 .
Że prowadzi zależny projekt podobny frees-io/freestyle-opscenter-webclientdo aktualizacji swojego package-lock.json: PR 31 .

Najprostszym / najłatwiejszym sposobem rozwiązania tego problemu jest:

1. npm install <dep>
2. npm uninstall <dep>
3. npm update
4. npm install

Od: https://github.com/Microsoft/vscode/issues/48783#issuecomment-384873041

znane luki w zabezpieczeniach i należy je zaktualizować.

Od 23 maja 2019 roku masz teraz „ Dependabot: automatyczne poprawki zabezpieczeń ”

Dzięki integracji Dependabot udostępniliśmy automatyczne poprawki bezpieczeństwa jako publiczną wersję beta.

Zautomatyzowane poprawki zabezpieczeń to żądania ściągnięcia generowane przez GitHub w celu naprawienia luk w zabezpieczeniach.
Automatyzują żmudną część przepływu pracy i ułatwiają programistom aktualizowanie ich zależności.

Więcej informacji można znaleźć w sekcji „ Konfigurowanie automatycznych poprawek zabezpieczeń ”

Uwaga: automatyczne poprawki zabezpieczeń są dostępne w wersji beta i mogą ulec zmianie.

Można włączyć automatyczne poprawki zabezpieczeń dla dowolnego repozytorium, które korzysta z alertów zabezpieczeń i wykresu zależności.
Automatycznie włączymy automatyczne poprawki zabezpieczeń w każdym repozytorium korzystającym z alertów zabezpieczeń i wykresu zależności w ciągu najbliższych kilku miesięcy, począwszy od maja 2019 r.

To działa dla mnie. odinstaluj wszystkie zależności i zainstaluj je ponownie

Na przykład

z package.json zobacz listę swoich zależności

{
"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"
  }
}

Postępuj zgodnie z poleceniem

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

1. W GitHub przejdź do strony głównej repozytorium.
2. Pod nazwą repozytorium kliknij opcję Bezpieczeństwo.
3. Kliknij alert, który chcesz wyświetlić.
4. Przejrzyj szczegóły luki i, jeśli jest dostępne, żądanie ściągnięcia zawierające automatyczną poprawkę zabezpieczeń.
5. Opcjonalnie, jeśli nie ma jeszcze automatycznej poprawki zabezpieczeń dla alertu, aby utworzyć żądanie ściągnięcia w celu usunięcia luki, kliknij opcję Utwórz automatyczną poprawkę zabezpieczeń.
6. Gdy będziesz gotowy, aby zaktualizować swoją zależność i rozwiązać lukę, scal żądanie ściągnięcia.

Patrz szczegóły

spróbuj npm audit fix, to rozwiąże wiele ostrzeżeń

następnie npm i [package.name]@xxx

na przykład:

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

npm i lodash@4.17.13