脆弱性のニュースで「Node.jsを更新」「Brotliの修正」と言われても、Webサイトの管理画面で何をすればよいのか分からないことがあります。これらは、記事や商品情報を編集する画面の裏側で使われるソフトウェアです。
事業担当者が押さえたいのは、サイトの機能、それを動かす実行環境、その中で使う部品には、それぞれ確認すべき更新があるという点です。仕組みを簡単に知っておくと、開発会社や保守会社への依頼が具体的になります。
Node.jsは、プログラムを動かすための「実行環境」
Node.jsは、JavaScriptで書いたプログラムをブラウザーの外で動かすためのソフトウェアです。Webサーバー上でページを作る処理や、外部サービスとのデータのやり取りなどにも使われます。このように、プログラムを動かす土台を「実行環境」、英語ではランタイムと呼びます。Node.jsの公式解説
ただし、WebページにJavaScriptが使われているだけで、サーバーにもNode.jsがあるとは限りません。ブラウザーのJavaScriptと、サーバーで動くNode.jsは分けて考えます。
また、Node.jsをサイトの制作・ビルド時だけに使い、公開中のページを処理するサーバーには使わない構成もあります。「制作で使っています」という回答を受けたら、利用者のアクセスを処理する本番環境にもあるか、制作時の環境だけかを確認すると整理できます。
ライブラリは、多くのソフトウェアが使う共通部品
ソフトウェアは、すべてを一から作るのではなく、通信、画像の処理、データの圧縮などの機能を部品として利用することがあります。このような再利用できるプログラムのまとまりを「ライブラリ」と呼びます。
あるアプリが別の部品を必要とする関係は「依存関係」と呼ばれます。直接使っている部品が、さらに別の部品を使うこともあるため、事業担当者が製品名を知らなくても、自社システムに含まれている場合があります。Node.js公式も、依存するパッケージの版を管理し、脆弱性の確認を自動化することを推奨しています。Node.jsのセキュリティに関する推奨事項
共通部品に問題が見つかると、複数の製品から同じCVE番号の注意喚起が出ることがあります。CVE番号は脆弱性を区別するための識別番号です。同じ番号でも、製品ごとの使い方や修正方法は同じとは限りません。
Brotliはデータを小さくする方式。圧縮と展開は別の処理
Brotliは、元に戻せる形でデータ量を小さくする圧縮方式です。Webページなどの転送量を減らすために使われます。圧縮したデータを使うときには、受け取る側で元に戻す「展開」が必要です。Brotliの公式説明、HTTPの圧縮方式の説明
例えば、サーバーがページを圧縮してブラウザーに送り、ブラウザーが展開して表示する流れがあります。一方、サーバー上のアプリが外部サービスから圧縮データを受け取り、自分で展開する場合もあります。
そのため、「Brotliの脆弱性」と聞いたら、まず問題が圧縮する処理なのか、展開する処理なのかを確かめます。次に、自社のどの機能が、その処理を使うかを調べてもらいます。方式を使っているという事実と、脆弱性の成立条件に当てはまることは区別が必要です。
「サイトを更新した」と「部品を修正した」は同じとは限らない
保守の対象は、大まかに次のように分かれます。実際の構成では部品が実行環境に内蔵されるなど、重なっている場合もあります。
- サイトやアプリの機能：表示、ログイン、注文、外部サービスとの連携など。
- 実行環境：Node.jsやPHPなど、プログラムを動かすソフトウェア。
- 共通部品：通信、圧縮・展開などの機能を提供するライブラリ。
- OSやコンテナーの土台：アプリを配置し、動かすための基盤。
サイトの内容やアプリのプログラムを更新しても、実行環境やOS側の部品まで置き換わるとは限りません。逆に、サービス提供元がまとめて更新する仕組みなら、利用者が部品を一つずつ入れ替える必要はありません。
例えば2026年のBrotliの脆弱性では、Red HatはNode.jsに内蔵した部品を使う構成と、OS側の部品を使う構成を区別して案内しています。確認したいのは単なる製品名ではなく、その環境で実際に使う部品が修正済みかです。Red Hatの構成別の説明
クラウド任せでよい範囲も、契約と配置方法で変わる
クラウドには、提供会社が実行環境を更新するサービスもあれば、利用者が更新するサーバーもあります。同じ会社のサービスでも、担当範囲は異なります。
コンテナーというアプリと実行環境をまとめた仕組みを使う場合、修正済みの「土台」が提供されても、自社のアプリを作り直して再配置するまで古い部品が残ることがあります。AWS Lambdaでも、管理されたランタイムの更新設定と、コンテナーを作り直して再配置する作業は分かれています。Lambdaのランタイム更新、コンテナーの更新方法
「修正版が出た」「作業用のパソコンを更新した」「本番環境で修正済みの版が動いている」は、それぞれ別の状態です。完了報告では、実際に利用者の処理を受け持つ環境まで反映されたかを確認しましょう。
保守担当者とのやり取りで残しておきたい情報
脆弱性の連絡を受けたら、対象サイトとCVE番号を伝え、次の項目をまとめてもらうと、その後の判断に使えます。
- 対象の環境：本番、開発・検証、定期処理など、どこを調べたか。
- 使っている製品と部品：問題のある機能を使うか、対象外ならその根拠。
- 更新する担当者：開発会社、サーバー会社、自社など、誰が何を行うか。
- 反映の証拠：修正済みの版・パッケージ、提供元の案内、反映日時。
- 作業後の確認：再起動・再配置の有無と、表示や主要機能のテスト結果。
バージョン番号を大きく変えずに修正だけを取り込む提供元もあるため、番号だけで未修正と決めつけないことも大切です。対応するCVEに修正済みであることを、提供元の案内や保守報告で確かめます。
日頃から管理者と更新範囲が分かっていれば、次の脆弱性が出たときも確認先に迷いにくくなります。仕組みをすべて覚えるより、「どこで使い、誰が更新し、どこまで反映したか」を記録できる状態にしておきましょう。
情報確認日：2026年11月7日。製品固有の対応は、その時点の公式案内に従ってください。