実行すると、npm installと表示されますfound 33 vulnerabilities (2 low, 31 moderate) run `npm audit fix` to fix them, or `npm audit` for details。
しかし、npm audit fix出力up to date in 11s fixed 0 of 33 vulnerabilities in 24653 scanned packages 33 vulnerabilities required manual review and could not be updated
それはreviewユーザーが修正するべきではないことを意味しますか?
実行すると、npm audit次のようなテーブルのリストが表示されます。
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low │ Prototype Pollution │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ lodash │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=4.17.5 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ browser-sync [dev] │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ browser-sync > easy-extender > lodash │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://nodesecurity.io/advisories/577 │
└───────────────┴──────────────────────────────────────────────────────────────┘
この例では、リンクされたページの修復セクションに と記載されていますUpdate to version 4.17.5 or later.。ただし、 には/node_modules/browser-sync/package.json次の行があります:
"devDependencies": {
"lodash-cli": "4.17.5",
}
/node_modules/lodash/lodash.jsonそして、lodash の依存関係はなくなりました。つまり、すでに v4.17.5 になっているはずです。どの行があるかも確認しましたvar VERSION = '4.17.10';。/node_modules/lodash/package.jsonそこには次の行があります:
"_from": "lodash@^4.17.4",
"_id": "[email protected]",
バージョンは「_from」ではなく「_id」に表示されるため、バージョンは正しいものの、監査リストには脆弱性が依然として表示されると考えられます。
私はまだ node.js の初心者なので、これらのメッセージにとても困惑しています。手動で修正したり、何もできないこれらのメッセージを削除したりする方法はありますか?
ベストアンサー1
lodash-cliプロジェクト内での動作devDependenciesには影響しませんが、パッケージが依存関係としてインストールされるときは無視されます。browser-syncdevDependencies
レポートによると、依存関係があるauditとのこと:easy-extenderlodash
browser-sync > easy-extender > lodash
それLodash 3に依存ですが、この問題は Lodash 4 で修正されました。この問題は、 をフォークして更新し、NPM パブリック レジストリのパッケージの代わりにインストールすることで修正できますeasy-extender。ただし、この依存関係に実際の問題はありません。
auditレポートの重要度は手動で評価する必要があります。ネストされた依存関係にセキュリティ リスクがある場合でも、このリスクをもたらす機能が使用されたことを意味するわけではありません。また、たとえ使用されたとしても、その使用方法によって実際のリスクが生じることを意味するわけではありません。
browser-sync開発ツールであり、本番環境では使用されていないため、脆弱性が悪用されるシナリオはそれほど多くありません。プロトタイプ汚染これはまったく脆弱性ではなく、パッケージが適切なプラクティスに従っていないという通知にすぎないため、無視できます。
一般的に、報告された脆弱性を修正する方法は次のとおりです。
- 健全性チェックを行う
- 本当に問題がある場合は、脆弱なパッケージのリポジトリで既存の問題を確認してください。そしてPR について
- 問題がない場合は、問題を報告してください
- リポジトリをフォークするか、既存のPRを使用するgit 依存関係NPMリリースで修正されるまで
- ネストされた依存関係の場合は、複数のネストレベルでこれを行う
ほとんどの場合、健全性チェックを超えて進むことはないと予想されますが、唯一の問題は、「脆弱性」によって監査レポートが乱雑になり、実際の脆弱性が隠されてしまうことです。
patch-packageネストされた依存関係をその場で修正するのに役立ちますが、レポートには影響しません。
Yarn 1と2では、ネストされた依存関係で特定の依存関係バージョンを強制することができます。resolutions分野監査報告書に影響します。これを行うことは可能かもしれませんNPMでネイティブに将来的にはNPMの代替としてサードパーティのnpm-force-resolutions制御性が低いユーティリティでは、現在は解決を強制します特定の依存関係ではなく、すべての依存関係。
依存関係に、動作するように設計されていないネストされた依存関係の使用を強制すると、いつでも壊れる可能性があることに注意してください。これは特に に当てはまりますnpm-force-resolutions。 は鈍いツールであり、一度に多くのネストされた依存関係に影響を与える可能性があります。