ライブラリ・フレームワークの脆弱性管理

概要

新しいWebサービスを発注する際は、公開後に使い続ける部品を誰が把握し、問題が見つかったときに誰が更新するかも決めておきます。ライブラリはプログラムが使う部品、フレームワークは開発の土台です。利用すると開発を進めやすくなる一方、それらの変更やサポート終了にも対応が必要になります。OWASP A03

OWASP（オワスプ）は、ソフトウェアの安全性を高めるための資料やツールを無料公開する非営利団体です。
OWASPの紹介

この記事では、発注担当者が確認したい納品物と対応分担、開発担当者が更新の優先順位を判断する材料を整理します。

国立環境研究所のProself事例では、研究所はメーカーが当時確認できていなかった脆弱性を悪用されたと説明しました。2023年11月7日の修正版は、不正アクセス期間を同年9月15〜28日とし、10月5日の痕跡発見とサーバー停止を記載しています。研究所の発表

これは製品の脆弱性の事例です。特定のライブラリが原因だった、更新を怠った、と読み替えません。修正版がまだない状況も含め、利用中のソフトウェアに問題が見つかった場合の対応を考える参考にします。

「脆弱性のお知らせを受け取る」だけでは、対応は終わりません。自社で使っているか、どの環境にあるか、問題の機能が外部から使えるかが分からなければ、停止や更新の判断が遅れます。直接追加した部品のさらに先にある間接依存も確認対象です。OWASP A03

また、通知の深刻度だけでは自社の優先順位は決まりません。本番への影響、攻撃の成立条件、暫定措置の可否を確かめ、判断と期限を記録する必要があります。SSDF v1.1のRV.2も、リスクを評価して対応を計画する考え方です。NIST SSDF

以下は標準の考え方を開発の発注・運用に具体化した設計案です。

本番で動くライブラリだけでなく、フレームワーク、実行環境、ビルド用ツールも把握します。名称、実際の版、使うシステム、取得元、サポート期限、更新担当を残します。SBOMはソフトウェアの構成表で、一覧作成を助けますが、作った時点から更新されなければ現状を表しません。OWASP A03

ロックファイルで解決した版を記録し、配布した成果物と結び付けます。発注担当者は「一覧があるか」に加え、「どの公開版の一覧か」を確認してください。契約終了後に誰が通知を受け、調査と更新を依頼できるかも受け渡し時に決めます。NIST SSDF PW.4

担当者は通知ごとに、対象の版、攻撃の成立条件、外部公開の有無、扱う情報、修正版を確認します。影響が小さい通常更新は計画して進め、悪用情報があり外部から到達できる問題は先に調査します。「対象外」と判断した場合も理由を残し、構成が変わった際に再確認できるようにします。NIST SSDF RV.2

修正版がなければ、該当機能の停止、公開範囲の制限、別製品への移行などを検討します。機能制限は業務を妨げるため、開発側だけでなく業務責任者が影響を確認し、再判断日を決めます。監視を増やすだけで危険がなくなったとは扱いません。OWASP A03

更新は検証環境で、ログイン、権限、決済など対象システムの重要な操作を確認してから段階的に反映します。問題の版が配布物から消えたことも再調査し、試験結果と公開した版を残します。互換性と段階的な展開はOWASPの推奨にも含まれます。OWASP A03

たとえばnpmの監査ツールは判断材料になりますが、audit fix --forceはメジャー更新を適用し、動作変更を伴う場合があります。警告件数を減らすために無条件で実行せず、変更内容と公式の移行案内を読みます。npm CLI v11

更新に失敗した際の戻し方も必要です。ただし脆弱な旧版へ戻すなら、公開範囲を制限するなどの暫定措置と、再更新する期限を合わせて決めます。更新速度と停止リスクの両方を扱うための判断です。