npm auditについて
npm auditコマンドは、インストールされているnpmパッケージの脆弱性を確認することができるコマンドです。
npm auditを使った脆弱性の確認方法
npm auditについて、
実際に使ってみた結果を参考に解説します。
npm auditコマンドの結果の例
# npm audit report
bootstrap 4.0.0 - 4.6.2
Severity: moderate
Bootstrap Cross-Site Scripting (XSS) vulnerability - https://github.com/advisories/GHSA-vc8w-jr9v-vj7f
fix available via `npm audit fix --force`
Will install bootstrap@5.3.3, which is a breaking change
node_modules/bootstrap
socket.io-parser 4.0.4 - 4.2.2
Severity: high
Insufficient validation when decoding a Socket.IO packet - https://github.com/advisories/GHSA-cqmj-92xf-r6r9
fix available via `npm audit fix`
node_modules/socket.io-parser
～省略～
7 vulnerabilities (1 low, 1 moderate, 5 high)上記のように結果が表示されます。
上記では脆弱性が、lowレベル1件、moderateレベルが1件、highレベルが5件あるとの結果が出ています。
脆弱性のレベル
脆弱性のレベルとしては、以下の通りになります。
また、この脆弱性はだれが監査しているのかというと、パッケージの開発者や、Github、コミュニティなどが監査してるそうです。
参考：https://docs.npmjs.com/about-audit-reports
| レベル | 内容 |
|---|---|
| Critical | すぐに対処すべき |
| High | できるだけ早く対処すべき |
| Moderate | 時間があるときに対処すべき |
| Low | 対処はご自由に |
脆弱性の内容
脆弱性の内容は、npm auditの結果に、githubのurlがあり、そこで確認できます。
また、今回の例だと、脆弱性が特定バージョンの範囲で存在してることが明記されているので、
バージョンを更新するとかで対応できます。
依存しているパッケージの確認
開発者がインストールしたパッケージが、また別のパッケージをインストールしていて、依存しているものがあります。
依存しているパッケージも、脆弱性として表示されますが、親のパッケージが何かまでは表示されないことがあります。
その場合は、npm lsコマンドを使って確認できます。
>npm ls socket.io-parser
└─┬ karma@6.3.0
└─┬ socket.io@3.1.2
└── socket.io-parser@4.0.5この結果より、脆弱性があったsoket.io-parserパッケージは、karmaが依存しているパッケージであることがわかります。
脆弱性の修正方法
脆弱性の修正方法としては、手動で修正するか、コマンドで自動で修正するかの2パターンになります。
手動で修正
手動で修正する場合は、npm uninstallとnpm installコマンドで、パッケージの新しいバージョンをインストールすることで、解決していきます。
>npm uninstall bootstrap
>npm install bootstrapnpm auditで脆弱性のあったbootstrapでは、上記のコマンドで、新しいものを再インストールすることで、脆弱性は解決しました。
ですが、メジャーバージョンのバージョンアップがあったりすると、既存の実装コードで不具合が発生する可能性があるため、新しいバージョンに適した書き方に直す必要が出てきます。
自動で修正
自動で修正する方法として、npm audit fixコマンドで対応できます。
ただ、全てのパッケージを自動で修正できるかというと、そうではありません。
npm auditコマンドで、「fix available via npm audit fix」という表示がされているものに対して、
自動で修正されます。
※–forceオプションを付けて強制的に修正することも可能ですが、互換性が合わなくなる可能性があります。
npm audit fixでは、基本的にはパッケージや、それに依存しているパッケージに対して、マイナーバージョンを上げて、脆弱性を解決していく動きがあります。この辺りは、package.jsonやpackage-lock.jsonでバージョンの修正が書き換わるので、そこの差分を確認してみてください。
マイナーバージョンは、破壊的な修正は入ってないため、既存のコード実装してる箇所にも影響はほとんど出ないかと思われます。
自動と手動のどちらがいいか
使ってみた感じだと、自動は依存しているパッケージのマイナーバージョンは上げてくれるけど、親のパッケージのマイナーバージョンを上げれば解決できるのに、といったことがあったので、
自動で効率良く対応してから、手動で修正した方が良いところを手動で修正するといったやり方がいいのかと思いました。
