依存ライブラリの脆弱性管理は、外部ライブラリやパッケージに含まれる既知の脆弱性を把握し、更新や代替でリスクを下げる管理です。SG試験で迷いやすいSBOMや脆弱性診断との違いを整理します。

sg sg-security-management sg-security-measures threat_vulnerability it_security_operations

まず結論

  • 依存ライブラリの脆弱性管理とは、ソフトウェアが利用している外部ライブラリやパッケージに脆弱性がないかを確認し、更新・修正・代替などでリスクを下げる管理です。
  • SG試験では、「自分たちが書いたコード」だけでなく「利用している外部部品の脆弱性」も管理対象になる点を押さえます。

直感的な説明

依存ライブラリは、ソフトウェアを作るときに使う外部部品のようなものです。

たとえば、製品を作るときに、自社で全部の部品を作るのではなく、外部メーカーの部品を使うことがあります。

その部品に不具合が見つかれば、製品全体にも影響する可能性があります。

ソフトウェアでも同じです。

自分たちのコードに問題がなくても、利用しているライブラリに脆弱性があれば、攻撃に悪用される可能性があります。

たとえば、次のようなものが対象になります。

  • Webフレームワーク
  • 認証ライブラリ
  • 暗号ライブラリ
  • 画像処理ライブラリ
  • JavaScriptパッケージ
  • PythonやJavaなどの外部パッケージ

つまり、依存ライブラリの脆弱性管理は「使っている外部部品に弱点がないかを継続的に確認する」活動です。

定義・仕組み

依存ライブラリの脆弱性管理では、ソフトウェアが依存している外部ライブラリ、パッケージ、フレームワークなどを把握し、既知の脆弱性がないかを確認します。

基本の流れは次のとおりです。

  1. 利用しているライブラリやパッケージを把握する
  2. バージョン情報を確認する
  3. 公開されている脆弱性情報と照合する
  4. 影響の有無と危険度を判断する
  5. 更新、修正、代替、回避策などを検討する
  6. 対応後も継続的に監視する

重要なのは、ライブラリは一度確認すれば終わりではないことです。

開発時点では安全に見えても、後から脆弱性が公表されることがあります。

そのため、運用中も継続的に脆弱性情報を確認し、必要に応じてバージョンアップや設定変更を行います。

脆弱性情報を確認する代表的な情報源として、IPAとJPCERT/CCが共同運営するJVN（Japan Vulnerability Notes）があります。国内で公表される脆弱性情報を確認する際の参考になります。

依存ライブラリの管理では、SBOMが関係することもあります。

SBOMは、ソフトウェアに含まれる部品の一覧表です。

どのライブラリを使っているかを把握できていないと、脆弱性が公表されたときに、自分たちのシステムが影響を受けるか判断できません。

そのため、SBOMや依存関係管理ツールを使って、利用部品を見える化することが重要になります。

どんな場面で使う？

依存ライブラリの脆弱性管理は、ソフトウェア開発と運用の両方で必要になります。

たとえば、次のような場面です。

  • 新しいライブラリを導入するとき
  • ライブラリのバージョンを更新するとき
  • 脆弱性情報が公表されたとき
  • CI/CDで自動的に依存関係を確認するとき
  • 委託先が開発したソフトウェアの構成を確認するとき
  • 運用中のシステムで古いライブラリが残っていないか確認するとき

特に、外部ライブラリは便利ですが、管理せずに使い続けるとリスクになります。

たとえば、古いバージョンに既知の脆弱性がある場合、攻撃者はその情報を使って攻撃できる可能性があります。

そのため、次のような対応が必要になります。

  • 脆弱性が修正されたバージョンへ更新する
  • 影響を受ける機能を無効化する
  • 別のライブラリに置き換える
  • 設定変更やアクセス制限で一時的にリスクを下げる
  • 更新できない理由と残留リスクを管理する

SG試験では、外部部品を使っている以上、脆弱性情報を継続的に確認する必要があると整理します。

よくある誤解・混同

依存ライブラリの脆弱性管理は、SBOM、脆弱性診断、SAST、パッチ管理と混同しやすいです。

混同しやすい用語 判断ポイント
依存ライブラリの脆弱性管理 外部ライブラリやパッケージの脆弱性を把握し、更新や代替で対応する
SBOM ソフトウェアに含まれる部品の一覧表
脆弱性診断 システムやアプリの既知の脆弱性や設定不備を広く洗い出す活動
SAST ソースコードを実行せず、ツールで危険な実装を検出する手法
パッチ管理 OSやソフトウェアの修正プログラムを適用・管理する活動

SG試験では、次のような表現に注意します。

  • 「利用している外部ライブラリの脆弱性を確認する」
    → 依存ライブラリの脆弱性管理を疑います。

  • 「ライブラリのバージョンを把握し、脆弱性情報と照合する」
    → 依存ライブラリの脆弱性管理です。

  • 「ソフトウェア部品の一覧を作る」
    → SBOMです。

  • 「既知の脆弱性や設定不備を広く洗い出す」
    → 脆弱性診断です。

  • 「ソースコードを実行せずに解析する」
    → SASTです。

よくあるひっかけは、SBOMを作れば脆弱性対応まで完了すると考えることです。

SBOMは、利用している部品を把握するための一覧です。

しかし、一覧を作るだけでは脆弱性は解消されません。

脆弱性情報と照合し、影響を判断し、更新や代替などの対応を行うところまでが重要です。

また、依存ライブラリの脆弱性管理は、開発時だけで終わるものではありません。

後から新しい脆弱性が見つかるため、運用中も継続的に確認します。

まとめ（試験直前用）

  • 依存ライブラリの脆弱性管理は、外部ライブラリやパッケージの脆弱性を継続的に確認する管理です。
  • 自分たちのコードだけでなく、使っている外部部品もリスクになる点が重要です。
  • SBOMは、ソフトウェア部品の一覧表であり、脆弱性対応そのものではありません。
  • 脆弱性が見つかったら、更新、代替、回避策、残留リスク管理を検討します。
  • SG試験では、外部部品・バージョン・脆弱性情報・継続管理の4点で判断します。

確認問題

依存ライブラリの脆弱性管理の説明として、最も適切なものはどれか。

ア. ソフトウェアに含まれる外部ライブラリやパッケージのバージョンを把握し、公開された脆弱性情報と照合して、更新や代替などの対応を行う。
イ. 実行中のWebアプリケーションに外部からアクセスし、応答や挙動を確認して脆弱性を検査する。
ウ. 社内ネットワークへ接続する端末の状態を確認し、条件を満たす端末だけ接続を許可する。
エ. 攻撃者の視点で侵入シナリオを作成し、重要情報へ到達できるかを検証する。

回答と解説を表示 正解は **ア** です。 依存ライブラリの脆弱性管理では、利用している外部ライブラリやパッケージを把握し、脆弱性情報と照合して、更新、代替、回避策などを検討します。 イはDAST、ウは検疫ネットワーク、エはペネトレーションテストに近い説明です。

🔗 関連記事

🏠 情報セキュリティマネジメントトップに戻る