ソフトウェア資産台帳とは何か、CVE対応・SBOM・SaaS棚卸しで集める情報、優先度判断、初動対応、更新サイクルを整理。情シス・開発者が脆弱性ニュースを見た直後に使えるチェックリスト付き。
冒頭要約：ソフトウェア資産台帳はCVE対応の「探す時間」を短くする
ソフトウェア資産台帳とは、自社が使っているソフトウェア、SaaS、コンテナ、ブラウザ拡張、開発ツール、依存ライブラリを、所有者・バージョン・利用場所・公開範囲・重要度と一緒に管理する一覧です。
CVEやCISA KEVのニュースを見たとき、最初に必要なのは「危険そうか」ではなく「自社に対象があるか」「どこにあるか」「誰が直すか」を短時間で答えることです。台帳が弱いと、パッチ作業より前の棚卸しで時間を失います。
この記事では、2026年7月1日時点で確認できるNIST、CISA、CycloneDX、SPDXの公式情報をもとに、情シス・開発者・SaaS管理者が実務で使えるソフトウェア資産台帳の作り方を整理します。
この記事は、防御・確認・初動対応を目的にした実務ガイドです。第三者環境の探索、攻撃再現、PoC、悪用コード、外部スキャン手順は扱いません。確認は自社の台帳、管理画面、SBOM、契約、ログ、ベンダー公式情報に基づいて行います。
読者別の影響：誰がどの台帳を見るべきか
ソフトウェア資産台帳は、情シスだけの管理表ではありません。CVE対応、SaaS棚卸し、SBOM、監査、インシデント初動で見る人が変わるため、読者ごとに目的を分けます。
| 読者 | まず知りたいこと | 主な確認対象 |
|---|---|---|
| 個人・一般利用者 | 自分の端末やブラウザが更新されているか | OS、ブラウザ、拡張機能、セキュリティソフト |
| 情シス担当者 | 全社端末・サーバー・SaaSに対象製品があるか | 端末管理、MDM、SaaS管理画面、契約台帳、管理画面 |
| 開発者 | 自分たちのアプリやCI/CDに対象ライブラリがあるか | リポジトリ、lockfile、SBOM、コンテナ、CIログ、GitHub |
| SaaS管理者 | 外部共有や連携アプリがリスクを広げていないか | SaaS権限、OAuthアプリ、ゲスト、SCIM、監査ログ |
| CSIRT / SOC | 影響資産とログの確認先をすぐ特定できるか | SIEM、EDR、監査ログ、資産重要度、対応チケット |
| 管理部門・法務 | 契約・委託先・ライセンスの責任分界を説明できるか | 契約書、委託先一覧、SaaS契約、保守期限、例外承認 |
台帳の価値は「一覧があること」ではなく、ニュースやアラートを受けて次の判断に進めることです。CVE、KEV、SBOM を別々に見るのではなく、同じ資産IDやサービス名に結びつける必要があります。
ソフトウェア資産台帳とは：製品名だけでなく判断材料を持つ一覧
ソフトウェア資産台帳は、単なるライセンス管理表や購入一覧とは違います。CVE対応で使うには、製品名、バージョン、所有者、利用場所、公開範囲、重要度、更新可否、ログ確認先まで含める必要があります。
NIST SP 800-40 Rev. 4は、エンタープライズのパッチ管理を、パッチや更新を識別し、優先付けし、取得し、適用し、適用を検証するプロセスとして整理しています。実務では、この流れの最初に「対象資産を特定できるか」があります。
最初に持つべき項目は次の通りです。
| 項目 | 例 | なぜ必要か |
|---|---|---|
| 資産名 | Microsoft 365、Apache ActiveMQ、Chrome、GitHub Actions Runner | ニュースやベンダー情報と照合する |
| 資産ID | 管理番号、クラウドタグ、リポジトリ名、SaaSテナント名 | 重複や同名サービスの混同を防ぐ |
| 所有者 | 部門、システムオーナー、技術責任者 | 対応判断と例外承認を止めない |
| 利用場所 | 端末、サーバー、コンテナ、SaaS、CI/CD、委託先 | 対象範囲とログ確認先を絞る |
| バージョン | 製品版、build、lockfile、イメージdigest、拡張機能版 | CVEの影響有無を確認する |
| 公開範囲 | インターネット公開、VPN内、社内限定、端末内、SaaS内部 | 到達可能性と緊急度を判断する |
| 重要度 | 顧客データ、認証基盤、管理者権限、開発基盤への近さ | 事業影響を説明する |
| 更新方式 | 自動更新、手動更新、委託先保守、EOL、例外あり | パッチ計画を現実的にする |
| ログ確認先 | EDR、SIEM、SaaS監査ログ、クラウド監査ログ | 侵害確認や初動記録に使う |
| 例外期限 | 更新延期理由、暫定対策、次回レビュー日 | 放置された例外を減らす |
最初の目的は、全社の完全な構成管理データベースを作ることではありません。まずは、外部公開、認証基盤、顧客データ、開発基盤、管理者権限に近い資産から、CVE対応に必要な最小項目をそろえます。
まず確認すること：10項目チェックリスト
新しいCVE、KEV、ベンダーアドバイザリ、SaaS障害情報を見たときは、次の順に確認します。攻撃再現や外部探索ではなく、自社の正規管理情報から始めます。
| 確認項目 | 見るもの | 完了条件 |
|---|---|---|
| 1. 対象名 | 製品名、ライブラリ名、SaaS名、CVE番号、CPE | 表記ゆれを含めて検索語を決めた |
| 2. 対象バージョン | ベンダー情報、NVD、CISA KEV、リリースノート | 影響あり・なし・調査中に分けた |
| 3. 自社利用有無 | 資産台帳、SaaS契約、MDM、EDR、SBOM、lockfile | 対象資産の候補一覧を作った |
| 4. 所有者 | システムオーナー、サービス管理者、開発責任者 | 対応責任者と連絡先を置いた |
| 5. 公開範囲 | DNS、WAF/CDN、VPN、クラウド、管理画面、SaaS設定 | 外部到達の有無を説明できる |
| 6. 重要度 | 顧客データ、認証、管理者権限、決済、CI/CD | 対応優先度の根拠を残した |
| 7. 更新可否 | パッチ、暫定緩和、停止、委託先対応、EOL | 今日できる対応と後続対応を分けた |
| 8. ログ | EDR、SIEM、SaaS監査ログ、クラウド監査ログ | 確認したログと期間を記録した |
| 9. 例外 | 期限、承認者、代替策、監視強化、再レビュー | 例外が無期限になっていない |
| 10. 台帳更新 | 更新日、判断、残リスク、次回確認日 | 次のCVE対応で再利用できる状態にした |
このチェックリストは、CVE初動対応チェックリスト と合わせて使うと実務に落とし込みやすくなります。開発者向けには、SBOMとOSV-Scannerで依存関係リスクを棚卸しする実習 で、依存関係と脆弱性情報を照合する考え方を確認できます。
初動対応：CVEやKEVを見つけたときに台帳でやること
CVEやCISA KEVに関係するニュースを見つけた直後は、対応を「探索」「判断」「実施」「記録」に分けます。慌ててパッチだけ当てると、対象外資産に時間を使ったり、侵害確認のログを見落としたりします。
やること
- ベンダー公式アドバイザリ、NVD、CISA KEVで、CVE番号、影響製品、影響バージョン、修正版、緩和策を確認する。
- 自社の資産台帳、端末管理、SaaS契約、SBOM、リポジトリ、コンテナ、CI/CDを検索し、対象候補を洗い出す。
- 外部公開、認証基盤、管理画面、顧客データ、開発基盤に近いものを先に見る。
- パッチ前後で、適用対象、適用日時、担当者、確認方法、残リスクを記録する。
- KEV入りや外部公開資産に該当する場合は、KEVとは と KEVとEPSSの違い を参考に、優先度を上げる根拠を明確にする。
- 開発基盤や依存関係に関係する場合は、開発ツール・OSSサプライチェーン確認チェックリスト と パッケージマネージャー緊急更新チェックリスト へ進む。
やらないこと
- 攻撃再現や外部探索から始めない。
- 製品名だけで「使っていない」と判断しない。別名、組み込みコンポーネント、コンテナイメージ、委託先利用、検証環境まで確認する。
- パッチ適用だけで完了にしない。ログ確認、影響範囲、例外期限、台帳更新を残す。
- KEVに未掲載だから安全と断定しない。自社の公開範囲と重要度で優先度を調整する。
- SBOMを一度生成して終わりにしない。リリースやコンテナ更新と結びついていなければ、インシデント時に古い情報になる。
記録すること
| 記録項目 | 例 |
|---|---|
| 対象情報 | CVE番号、製品名、ライブラリ名、SaaS名、CPE、ベンダー情報URL |
| 対象資産 | ホスト名、リポジトリ、コンテナ、SaaSテナント、拡張機能、委託先 |
| 判断 | 対象あり、対象なし、影響不明、更新済み、緩和済み、例外 |
| 優先度根拠 | KEV、CVSS、EPSS、公開範囲、資産重要度、データ分類 |
| 実施内容 | パッチ、設定変更、公開停止、権限見直し、監視強化、委託先確認 |
| 検証 | バージョン確認、ログ確認、再起動確認、SaaS監査ログ、EDR状態 |
| 次回対応 | 例外期限、恒久対応、再レビュー、台帳の不足項目、教育対象 |
判断基準：どの資産から直すか
ソフトウェア資産台帳は、優先順位を決めるために使います。CVSSの点数だけでなく、KEV、EPSS、外部公開、資産重要度、更新可否を組み合わせます。
| 優先度 | 条件 | 対応 |
|---|---|---|
| 高 | CISA KEV掲載、外部公開、認証基盤・管理画面・顧客データ・CI/CDに近い、既に不審ログがある | 24時間以内に対象有無、暫定緩和、ログ確認、責任者、報告先を確定する |
| 中 | CVSSが高い、EPSSが高い、社内重要資産に近い、更新延期が必要 | 72時間以内にパッチ計画、例外期限、監視強化、事業影響を記録する |
| 低 | 対象製品なし、影響対象外バージョン、社内限定かつ重要度が低い | 対象外の根拠を台帳に残し、次回確認日を置く |
CISA KEV JSONは機械可読なフィードとして提供されており、2026年7月1日の確認時点では catalogVersion が 2026.06.29、dateReleased が 2026-06-29T18:57:01.4113Z として取得できました。KEVは更新され続けるため、記事やSNSの要約ではなく、公式カタログやJSONフィードを定期的に確認する運用が必要です。
ただし、KEVは米国連邦機関向けの期限も含むため、自社にそのまま日付だけを適用するのではなく、対象資産、公開範囲、契約、運用停止可否と合わせて判断します。
台帳に見つからないことは「使っていない」ことの証明ではありません。部門導入SaaS、検証用コンテナ、開発者端末、委託先運用、古いVM、ブラウザ拡張は見落とされやすいため、対象なしにする前に複数の情報源を確認します。
SBOM・SaaS・端末台帳をつなげる
CISAはSBOMを、ソフトウェアセキュリティとソフトウェアサプライチェーンリスク管理の重要な構成要素として整理しています。2025 Minimum Elements for SBOMのページでも、SBOMがソフトウェアコンポーネントの詳細なインベントリになり、脆弱性特定、リスク評価、利用・展開するソフトウェアの判断に役立つと説明されています。
ただし、SBOMだけでは全社のソフトウェア資産台帳にはなりません。SBOMは主に「その成果物が何でできているか」を示すため、運用上は次の情報と結びつけます。
| 情報源 | 得られること | 台帳で結びつける項目 |
|---|---|---|
| SBOM | コンポーネント、バージョン、依存関係、形式 | アプリ名、リリース、リポジトリ、環境、所有者 |
| MDM / EDR | 端末上のOS、アプリ、更新状態 | 端末、利用者、部署、パッチ状態、隔離可否 |
| SaaS契約台帳 | 利用中SaaS、契約責任者、更新日 | サービス名、管理者、データ分類、委託先 |
| SaaS監査ログ | 共有、ログイン、権限、外部連携 | 外部共有、ゲスト、OAuth、管理者操作 |
| CI/CD | ビルド、ランナー、アーティファクト、コンテナ | リリース、イメージdigest、デプロイ先、SBOM |
| クラウドタグ | VM、コンテナ、サーバーレス、ストレージ | 環境、公開範囲、所有者、重要度 |
CycloneDXは、ソフトウェアコンポーネントやサービス、依存関係を機械可読に表すSBOMの能力を説明しています。SPDXも、ソフトウェアパッケージ、ライセンス、セキュリティ関連情報を交換する仕様として使われます。どちらを使うかよりも、リリースや成果物とひもづけ、CVE確認時に検索できる状態にすることが重要です。
SaaSに関しては、ライブラリのSBOMとは別に、テナント、契約、管理者、外部共有、OAuthアプリ、SCIM、監査ログを台帳化します。関連する実務は SaaS権限棚卸しチェックリスト と SaaS外部共有リンクの棚卸し にまとめています。
よくある誤解
「資産台帳がないならEDRやSaaS管理画面を見ればよい」
EDRやSaaS管理画面は重要ですが、それぞれの見える範囲は違います。端末、SaaS、クラウド、CI/CD、委託先、SBOMを横断して判断するには、複数の情報源を同じ資産名や所有者に結びつける必要があります。
「SBOMがあればソフトウェア資産台帳は不要」
SBOMは依存関係の把握に強い一方で、誰が運用しているか、どこにデプロイされているか、外部公開されているか、どのログを見るかまでは必ずしも示しません。SBOMは台帳の一部として使います。
「CVE対応はセキュリティ担当だけで完結する」
対象製品の所有者、更新可否、業務停止可否、委託先契約、SaaS管理者、開発者が関係します。セキュリティ担当は判断軸を作れますが、修正・停止・例外承認は所有者と一緒に進めます。
「台帳に載っていないものは対象外」
台帳に載っていない資産こそ、部門導入や検証環境として残っていることがあります。特にAIツール、ノートブック、ブラウザ拡張、開発者ツール、古い管理画面は、正式な購入台帳に出ないことがあります。
「パッチ適用率だけ追えばよい」
パッチ適用率は重要ですが、KEV、外部公開、管理者権限、顧客データ、例外期限が見えなければ、最も危険な資産が後回しになる可能性があります。
関連用語・関連ページ
ソフトウェア資産台帳は、脆弱性管理、開発者セキュリティ、SaaS管理、インシデント対応をつなぐ入口です。次のページを合わせて読むと、実務へ落とし込みやすくなります。
| 目的 | 内部リンク |
|---|---|
| 用語を確認する | SBOM、CVE、KEV、EPSS、CPE、CSAF、VEX、資産台帳 |
| 違いを理解する | CVEとCVSSの違い、KEVとEPSSの違い |
| 初動対応に使う | CVE初動対応チェックリスト、セキュリティ例外申請テンプレート |
| 開発者向けに確認する | SBOMとOSVで学ぶ依存関係確認、開発ツール・OSSサプライチェーン確認 |
| SaaS管理へつなげる | SaaS権限棚卸しチェックリスト、SaaS外部共有リンクの棚卸し |
| 知識を確認する | セキュリティクイズ、GitHub secret leak 初動ミニCTF |
公式情報・参考情報
一次情報を確認するときは、次のページを起点にします。CVEやSBOMの運用は更新されるため、記事の要約だけで判断せず、公式情報と自社台帳へ戻ることが重要です。
- NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
- CISA: Software Bill of Materials (SBOM)
- CISA: 2025 Minimum Elements for a Software Bill of Materials (SBOM)
- CISA Known Exploited Vulnerabilities Catalog
- CISA KEV JSON feed
- CycloneDX: Software Bill of Materials (SBOM)
- SPDX Specifications
まとめ：台帳は「持っているもの一覧」ではなく対応判断の材料
ソフトウェア資産台帳は、購入管理や監査のためだけの表ではありません。CVE、KEV、SBOM、SaaS外部共有、開発者ツールのリスクを見たときに、対象有無、所有者、公開範囲、重要度、更新可否、ログ確認先をすぐ判断するための材料です。
最初から完璧に作る必要はありません。外部公開、認証基盤、顧客データ、開発基盤、管理者権限に近い資産から始め、CVE対応のたびに不足項目を埋めていくほうが継続できます。
次に進むなら、まず CVE初動対応チェックリスト で確認項目をそろえ、開発者向けには SBOMとOSVで学ぶ依存関係確認 を使って、依存関係の棚卸しと優先度判断を練習してください。
