Node.jsの次回セキュリティリリースを前にまず取り組むべきことは、適用が必要になるすべてのアプリケーションを見つけることだ。
Node.jsプロジェクトは、22.x、24.x、26.xの各ブランチ向けに、11月11日（水）またはその直後にセキュリティ更新をリリースする予定だ。11月3日に公開された事前通知では、各ブランチの最高評価として「高」が挙げられている。
セキュリティチームにとって、準備期間は稼働中のランタイムを特定し、更新担当者を割り当て、脆弱性の詳細が公開される前にテストを手配する機会となる。パッチ計画では、各アプリケーションのNode.jsランタイムがどのようにインストールされ、更新されるかを明確にする必要がある。
対象は3つのブランチ
11月11日またはその直後の更新対象として、公式セキュリティ通知は22.x、24.x、26.xを挙げており、各ブランチの最高重大度は「高」としている。
この通知には、CVE識別子、技術的な説明、脆弱性の件数、修正済みパッチのバージョン番号はまだ記載されていない。また、現在悪用されていることを確認する記述もない。
そのため、防御側がアプリケーションの影響範囲について結論づけられることには限りがある。重大度が「高」であることだけでは、問題によってリモートコード実行が可能になるのか、認証が必要なのか、特定の構成に影響するのかは分からない。これらの点には、完全なアドバイザリーが必要だ。
最近のNode2Shellの脆弱性は、こうした条件が重要である理由を示している。影響を受けるかどうかは、攻撃者が制御するBrotli圧縮データをアプリケーションが処理するかに左右された。11月の事前通知から、以前のこの脆弱性との関連は確認できない。
実際にアプリケーションを提供しているランタイムを見つける
まず、各Node.jsデプロイメントを、そのバージョン、アプリケーション所有者、公開状況、更新方法にひも付けたインベントリを作成する。本番サービス、コンテナイメージ、開発環境とCIシステム、外部ベンダーが保守するアプリケーションも含める。
これは、脆弱性管理ライフサイクルにおける評価と優先順位付けの段階に沿ったものだ。修復の順序を決める前に、資産とそのビジネス上の文脈を特定する。
更新が届く前に、チームは次の作業を行うべきだ。
- デプロイ済みのバージョンを記録する。関連するアプリケーションまたはコンテナ環境内で確認すること。開発者のローカル環境のバージョンから、本番環境で稼働しているものを判断することはできない。
- 更新担当者を特定する。ランタイムがOSパッケージ、コンテナイメージ、直接インストール、ベンダー管理製品のいずれから提供されているかを確認する。
- デプロイ経路を準備する。ステージングテスト、必要に応じたコンテナの再ビルド、サービスの再起動、アプリケーション障害の確認を手配する。
- プロバイダーの責任範囲を確認する。マネージドサービスについては、誰がランタイムの修正を適用するのか、いつ利用可能になるのか、顧客側で何を再デプロイする必要があるのかを確認する。
組織が自動化されたパッチ管理サービスを利用している場合は、これらのデプロイメントが対象に含まれているかを確認する。中央のパッチ適用プラットフォームが存在するからといって、すべてのアプリケーションに組み込まれたランタイムが対象になるとは限らない。
サポート対象外のバージョンには移行の判断が必要
Node.jsは、セキュリティリリースが行われた際、サポート終了済みのバージョンも引き続き影響を受けると明確に警告している。次回リリースの一覧に含まれていないことを、安全の証拠とみなしてはならない。
プロジェクトのリリーススケジュールでは、Node.js 20をサポート終了とし、本番アプリケーションにはActive LTSまたはMaintenance LTSのリリースを推奨している。
サポート対象外のインストールを見つけたチームは、サポート対象のアップグレード経路を確立し、アプリケーションの互換性をテストすべきだ。商用サポート契約がある場合は、セキュリティ修正の対象範囲と提供スケジュールをプロバイダーに確認する。
パッチ完了を測定可能にする
リリースが届いたら、公開された脆弱性の条件とインベントリを照合する。開示された攻撃経路、影響範囲、ビジネスへの影響を使ってデプロイの優先順位を決め、そのうえでアプリケーションがサポートする更新プロセスを通じて、該当する修正版をインストールする。
各サービスについて、デプロイ後に稼働しているバージョン、正常なヘルスチェック、残っている例外の証拠を保管する。ビルド定義を更新するだけでは作業の一部にすぎない。置き換えたバージョンが、実際のワークロードを処理するインスタンスに到達したことを確認する。
更新が遅れる場合は、担当者、期限、実際の脆弱性にひも付いた対策を定めるべきだ。技術的な詳細が公開されるまでは、特定のファイアウォールルールや構成変更でこれらの問題に対処できると想定する根拠はない。
11月11日までに目指すべき成果は、責任者が明確になったインベントリと、テスト済みのデプロイプロセスだ。リリース後に必要なのは、影響を受けるサービスが修正版を稼働させていることを示す証拠と、未完了のデプロイを完了まで追跡することだ。
続きを読む：10月にGitLabが公開した2件目の重大なRCEパッチは、最近パッチを適用したシステムであっても、新たなセキュリティアドバイザリーごとに確認する必要がある理由を示している。