脆弱性管理

自組織の資産にどのような脆弱性があるかを継続的に把握し、危険度に応じて修正プログラムの適用や回避策を実施する一連の活動。資産目録やSBOMの整備が前提となる。

自組織の資産構成を把握したうえで脆弱性情報を収集し、影響度を評価して修正プログラムの適用や緩和策を計画的に実施する一連の活動。SBOMやソフトウェア構成分析を用いて依存関係まで含めて把握する。

組織が利用するソフトウェアや機器の技術的な脆弱性について、情報の収集、資産の目録との照合による影響の把握、リスクに応じた優先順位付け、修正プログラムの適用や回避策の実施、適用状況の確認を継続的に行う活動。JIS Q 27002の「技術的脆弱性の管理」に当たり、SBOMやCVSSを活用する。

ソフトウェアを構成する部品（OSS などの外部コンポーネントを含む）と、その開発・提供に関わる供給元を把握し、品質、ライセンス、脆弱性などのリスクを調達から運用まで管理すること。SBOM（ソフトウェア部品表）による構成の可視化が有効とされる。

ソースコードが公開され、オープンソースライセンスの条件に従って誰でも利用・改変・再配布できるライブラリ。開発を効率化できる一方、ライセンス条件の順守や、脆弱性が見つかったときの更新など、利用する側での管理が必要になる。

AIシステムを構成する要素を一覧にした部品表。AIモデルの名称・版・提供元、学習や評価に使ったデータセット、依存するライブラリ、ライセンスなどを記録し、来歴の追跡や脆弱性・ライセンスの管理に使う。SBOMの考え方をAIに広げたもの。

個々の脆弱性に一意の番号を付けて識別する仕組み。「CVE-2024-12345」のように公表年と連番で表し、米国のMITREが運営して、採番機関（CNA）とともに番号を割り当てている。製品ベンダー、脆弱性データベース、セキュリティ製品が同じ番号で同じ脆弱性を指せるため、情報の突合せが容易になる。

脆弱性の識別や設定の点検といったセキュリティ管理を自動化するために、情報の表現形式を標準化した仕様群。NISTが策定し、脆弱性を識別するCVE、製品を識別するCPE、設定項目を識別するCCE、深刻度を評価するCVSS、点検の手順を記述するXCCDFやOVALなどで構成される。共通の形式で表すことで、異なるツールの間で点検結果を比較・共有できる。

ソフトウェアの設計や実装の誤りによって生じた、情報セキュリティ上の欠陥。攻撃者に悪用されると不正アクセスやマルウェア感染の原因になるため、開発元が提供する修正プログラム（セキュリティパッチ）を適用して塞ぐ。技術的な脆弱性とほぼ同じ意味で使われる。