Programming Self-Study Notebook

勉強したことを忘れないように! 思い出せるように!!

「npm install」時のセキュリティ警告への対応方法

f:id:overworker:20200927105912p:plain:h150


皆さんはnpm installを実施した際のWARNについてどのように対応していますか?
私はよくわからないから放置していたのですが、中には脆弱性に関する警告が含まれていることがあるようです。

そんな時は、使用しているnode_modulesの脆弱性について調べるコマンド(npm audit)を活用して、脆弱性を塞いでいきましょう。



ココでは解決までの流れをまとめます。

Step1:発見(npm installを実施)

例)しばらく放置していた環境にnpm installを実施してみた時の画像です。

f:id:overworker:20200927224033p:plain:h200
found 4548 vulnerabilities (4547 low, 1 high)
run `npm audit fix` to fix them, or `npm audit` for details

上記の警告は脆弱性が疑われるライブラリバージョンを使っていること」に対するものです。
ココでは1件のhighレベルの脆弱性と4547件のlowレベルの脆弱性が検出されています。

Step2:状況確認(npm auditを実施)

f:id:overworker:20201018225848p:plain:w500

Step3:対応①(npm audit fixを実施)

  • npm audit fixpackage.jsonに記載された範囲でnpmモジュールのバージョンアップを実施します。まずはpackage.jsonの内容を変更しない範囲で対応してみましょう。

Step3-1:自動アップデートをキック(npm audit fixを実行)

  • package.jsonで許容された範囲でモジュールのバージョンアップが実施されます。
f:id:overworker:20201018232436p:plain:w500

Step3-2:結果の確認(npm auditを実施)

  • ココですべて問題が解消されていれば対応終了です。

Step4:対応②(手動で修正)

  • npm audit fixでバージョンアップができなかったモジュールは、package.jsonで許可された範囲外のアップデートが必要な場合です。
  • ラフな表現をすると、
    • npm audit的には、「モジュールAについて脆弱性がふさがれたVer2.0.3(例)以降を使用してほしいんだけど、package.jsonで、Ver1.**.**からVer2.**.**への自動アップデートは禁止されているから勝手にアップデートしないよ~!」って状態です。
  • package.json自体はプログラム作成者が責任を持ってい管理するべきものであるので、バージョン更新の影響の範囲を判断したうえで、内容を編集しても構いません。

なぜ自動アップデートが禁止されるのか

  • それは、主に以下の場合が多いようです
    • ほとんどのNPMモジュールがセマンティック・バージョニング(Semantic Versioning)というバージョン管理を採用している。
    • セマンティック・バージョニングには「互換性のないAPIを変更した場合のメジャーバージョンを更新する」というルールがある。 ※ 参考文献:Semantic Versioning 2.0.0

つまり「モジュールをアップデートすることにより、それまでの使い方が出来なくなる可能性があるので、アップデートする前に影響がないことを確認してください。」という状態です。

個人的な対応方法

私は個々のモジュールについて、使用方法を細かく把握しているわけではないので、「試しにメジャーアップデートしてから、アップデートしたモジュールに関連していそうな機能を触ってみて、問題なさそうならそのまま」といった流れを踏んでいます。(元のpackage-lock.jsonをバックアップしておけば元の環境に戻せます。)

Step4-1:インストールルールの更新(package.jsonを修正)

npm auditの結果に対象モジュールと、推奨最低バージョンの記述があるはずです。
その内容をもとにpackage.jsonの内容を変更してみましょう。

package.jsonの記述方法

主にバージョン管理に関係するチルダ表記キャレット表記について説明します。
(その他の、細かい解説は「公式リファレンス:semver | npm Docs」を参照してください。)

チルダ表記 ~

Tilde Ranges ~1.2.3 ~1.2 ~1
Allows patch-level changes if a minor version is specified on the comparator. Allows minor-level changes if not.

~1.2.3 := >=1.2.3 <1.(2+1).0 := >=1.2.3 <1.3.0
~1.2 := >=1.2.0 <1.(2+1).0 := >=1.2.0 <1.3.0 (Same as 1.2.x)
~1 := >=1.0.0 <(1+1).0.0 := >=1.0.0 <2.0.0 (Same as 1.x)
~0.2.3 := >=0.2.3 <0.(2+1).0 := >=0.2.3 <0.3.0
~0.2 := >=0.2.0 <0.(2+1).0 := >=0.2.0 <0.3.0 (Same as 0.2.x)
~0 := >=0.0.0 <(0+1).0.0 := >=0.0.0 <1.0.0 (Same as 0.x)
Google翻訳+個人的な補完

チルダの範囲 ~1.2.3 ~1.2 ~1 コンパレータでマイナーバージョンが指定されている場合、パッチレベルの変更を許可します。そうでない場合は、マイナーレベルの変更を許可します。

~1.2.3:= >=1.2.3 <1.(2+1).0:=>=1.2.3 <1.3.0 ~1.2:= >=1.2.0 <1.(2+1).0:= >=1.2.0 <1.3.0(と同じ1.2.x) ~1:= >=1.0.0 <(1+1).0.0:= >=1.0.0 <2.0.0(と同じ1.x) ~0.2.3:= >=0.2.3 <0.(2+1).0:=>=0.2.3 <0.3.0 ~0.2:= >=0.2.0 <0.(2+1).0:= >=0.2.0 <0.3.0(と同じ0.2.x) ~0:= >=0.0.0 <(0+1).0.0:= >=0.0.0 <1.0.0(と同じ0.x)

キャレット表記 ^

Allows changes that do not modify the left-most non-zero digit in the [major, minor, patch] tuple. In other words, this allows patch and minor updates for versions 1.0.0 and above, patch updates for versions 0.X >=0.1.0, and no updates for versions 0.0.X.

Many authors treat a 0.x version as if the x were the major "breaking-change" indicator.

Caret ranges are ideal when an author may make breaking changes between 0.2.4 and 0.3.0 releases, which is a common practice. However, it presumes that there will not be breaking changes between 0.2.4 and 0.2.5. It allows for changes that are presumed to be additive (but non-breaking), according to commonly observed practices.

^1.2.3 := >=1.2.3 <2.0.0
^0.2.3 := >=0.2.3 <0.3.0
^0.0.3 := >=0.0.3 <0.0.4
Google翻訳+個人的な補完

キャレット範囲 ^1.2.3 ^0.2.5 ^0.0.4 [major, minor, patch]タプルの左端のゼロ以外の数字を変更しない変更を許可します 。言い換えれば、これはバージョン1.0.0に対するパッチやマイナーアップデート可能にし、上記の、バージョンのパッチアップデート0.X >=0.1.0、および0.0.Xの更新を可能にします。

多くの作者は、0.xバージョンのxを主要な「重大な変更」の指標であるかのように扱います。

キャレット範囲は、作成者がリリース間0.2.40.3.0重大な変更を加える可能性がある場合に理想的です。 これは一般的な方法です。 しかし、それは0.2.40.2.5の間に破壊的な変更が含まれないことを前提としています。

よく見られる慣例に従い、付加的な(ただし、破損しない)変更であるとみなされ変更が許容されます。

^1.2.3 := >=1.2.3 <2.0.0 ^0.2.3 := >=0.2.3 <0.3.0 ^0.0.3 := >=0.0.3 <0.0.4

Step4-2:インストール済み情報の削除(package-lock.jsonnode_modulesディレクトリを削除)

  • package-lock.jsonは環境を再現するためのファイルです。
    • 環境を復元する可能性がある場合はバックアップを別ディレクトリで管理してください。
    • いらない人は削除してOKです。

Step4-3:インストール(npm installを実施)

Step5:確認(npm auditを実施)

f:id:overworker:20201018234201p:plain:w500

以上で対応完了です。