Правильний спосіб виправити потенційну вразливість системи безпеки у залежності, визначеній у package-lock.json

Github дав мені цю помилку в одному з моїх сховищ.

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.

Залежність у нашому package.jsonфайлі не визначена . Наскільки я розумію, видаляти package-lock.jsonфайл та регенерувати його не є доброю практикою . Однак я не бачу жодного іншого способу вирішити цю проблему. Якщо я усуну цю вразливість системи безпеки, вона з’явиться знову через пару днів. Будь-які ідеї? Дякую!

Нове: тепер за допомогою npm @ 6 ви можете безпосередньо запускати

npm audit fix

Стара відповідь:

Спробуйте визначити назву проблемного пакета, а потім запустити

npm install package-name

замінюючи ім'я пакета, очевидно.

Це встановить останню версію пакету, і дуже часто остання версія вирішує проблему безпеки. Якщо у вас є обмеження на версію (наприклад: 1.2), ви завжди можете спробувати:

npm install package-name@^1.2

і буде встановлена ​​остання виправлена ​​версія

Щоб вирішити цю проблему:

Рішення1: Спочатку знайдіть уразливість: Використовуючи термінал: cd у своєму проекті , потім запустіть "npm ls hoek"

І нарешті: npm встановіть bcrypt @ latest

Потім відсуньте оновлений проект до git. (Тобто виконайте новий коміт).

Рішення 2:

якщо перший варіант / рішення не вирішить проблему. Змініть версію вручну у файлі package-lock.json. Змініть версію вручну з 2.16.3 на 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

Потім оновіть свій проект на GitHub (коміт / push) Просто переконайтеся, що кожне входження версії hoek у вашій версії package-lock.json змінено на 4.2.1

Як варіант, якщо ви можете знайти спосіб змінити версію hoek / оновити hoek за допомогою npm, спростить ситуацію (щось на зразок: npm update @ hoek..version ) .. або видаліть конкретну залежність, а потім переінсталюйте її за допомогою bower або нм.

У мене була та ж проблема з уразливістю системи безпеки lodash у проекті, який я будував з пряжі. Github позначив це як проблеми безпеки.

Я спробував відповідь від @rileymanda вище, використовуючи термінал: cd у проект, а потім запустити npm ls lodash.

Це виявило, що в моєму випадку помилка була в реакційних сценаріях . Швидкий Google щодо проблем із сценаріями реагування та лодашем виявив, що це відома проблема.

Я пробував різні речі, щоб виправити за допомогою пряжі - все без успіху. npm ls lodashяк і раніше показував уразливу версію лодаша, що використовується.

Прочитавши блог Метта Тернбулла про вдосконалення npm, я перейшов з пряжі назад на npm. (Видалити yarn.lock, видалити ./node_modules. Виконати npm install). npm ls lodashтепер показав останні версії залежностей, які використовуються - ура! Прихильний до github, і тепер він був щасливий, що вразливість зникла.

Схоже, пряжа, можливо, намагається зняти такі проблеми (або не призначена для цього).

Якщо у вас виникає ця проблема при побудові з пряжі, спробуйте переключити [назад] на npm!

На моє розуміння, не є доброю практикою видаляти файл package-lock.json і регенерувати його.

Тим не менше, саме так зазвичай роблять у цьому випадку.
Див. Наприклад angular / angular-cli випуск 8534 , який вирішено PR 8535 .
Це призводить залежний проект , як frees-io/freestyle-opscenter-webclientдля поновлення його package-lock.json: PR 31 .

Найпростіший / найпростіший спосіб виправити це:

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

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

відомі вразливості безпеки, і їх слід оновити.

З 23 травня 2019 р. У вас тепер є " Dependabot: автоматичні виправлення безпеки "

Завдяки інтеграції Dependabot ми випустили автоматичні виправлення безпеки як загальнодоступну бета-версію.

Автоматизовані виправлення безпеки - це запити на виклик, створені GitHub, для виправлення вразливостей системи безпеки.
Вони автоматизують нудну частину робочого процесу та полегшують розробникам постійно оновлювати свої залежності.

Докладніше див. У розділі " Налаштування автоматичних виправлень безпеки "

Примітка: Автоматичні виправлення безпеки доступні в бета-версії та можуть бути змінені.

Ви можете ввімкнути автоматичні виправлення безпеки для будь-якого сховища, яке використовує попередження безпеки та графік залежностей.
Ми автоматично ввімкнемо автоматичні виправлення безпеки в кожному сховищі, яке використовує попередження безпеки та графік залежностей, протягом наступних кількох місяців, починаючи з травня 2019 року.

Це працює для мене. видаліть усі залежності та встановіть їх знову

Наприклад

з package.json див. список ваших залежностей

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

Виконайте для цього команду

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. На GitHub перейдіть на головну сторінку сховища.
2. Під іменем вашого сховища натисніть кнопку Безпека.
3. Клацніть сповіщення, яке ви хочете переглянути.
4. Перегляньте деталі вразливості та, якщо є, запит на витяг, що містить автоматичне виправлення безпеки.
5. Якщо не існує автоматичного виправлення безпеки для попередження, для створення запиту на вилучення для усунення вразливості натисніть Створити автоматичне виправлення безпеки.
6. Коли ви будете готові оновити свою залежність і вирішити уразливість, об’єднайте запит на витяг.

Дивіться деталі

спробуйте npm audit fix, це вирішить багато попереджень

тоді npm i [package.name]@xxx

наприклад:

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

npm i lodash@4.17.13