SBOMとは｜ソフトウェア部品表と2級で問われる点

一言でいうと、SBOM は「このソフトウェアは、どの部品のどの版でできているか」を記録した部品表です。製造業で製品の部品を並べた部品表（BOM）を、ソフトウェアに当てはめた考え方です。米国の CISA は SBOM を、ソフトウェアの部品を構成する「材料の一覧」と説明しています。

今のアプリやサーバのソフトウェアは、多数のオープンソースのライブラリを組み合わせて作られ、そのライブラリがさらに別のライブラリに依存しています。開発した本人でも、どの部品がどの版で入っているかを把握しきれないことがあり、部品の一つに脆弱性が見つかると影響の範囲を調べるだけで時間がかかります。SBOM はこの問題を、部品の一覧を最初から作って持っておくことで解決します。

MCPC の公式テキストのページでは、『モバイルシステム技術テキスト 第11版』（2026年2月発刊、第42回から適用）の改版の要点として、SBOM の活用についての記述が加わったことが示されています（2026年9月27日確認）。

具体的な判断へ進むにはSBOM受領時の確認を確認してください。

SBOM に記録する代表的な項目は、部品の名前、版、供給者、部品を一意に示す識別子、部品どうしの依存関係、SBOM を作った者と作成日時などです。米国の NTIA は2021年7月に SBOM の最小要素をまとめた報告を公表し、CISA はその見直しを進めています（2026年9月時点）。ライセンスの情報を含めれば、オープンソースのライセンスの管理にも使えます。

どちらの形式も機械で読めることが重要で、表計算ソフトに手で書いた一覧では、脆弱性の情報と自動で照らし合わせることができません。実際には、ビルドの工程でツールを使って自動で作るのが一般的です。

経済産業省の手引の ver2.0 は、ver1.0 に加えて、脆弱性の管理の一連の流れで SBOM を効果的に使う具体的な手順、導入が妥当な範囲を検討するための枠組み（SBOM 対応モデル）、委託先との契約で決めておく事項（SBOM 取引モデル）を盛り込んだと説明されています。流れを一般化すると、次のようになります。

1. 1ソフトウェアのビルドや納品のたびに SBOM を作り、版ごとに保管する。
2. 2新しく公表された脆弱性の情報と、SBOM に載っている部品と版を照らし合わせる。
3. 3該当する部品を含む製品について、その部品の問題の箇所が実際に使われているかなど、影響の有無を判断する。
4. 4影響がある場合は、部品の更新や回避策を適用し、利用者に知らせる。
5. 5修正後のソフトウェアで SBOM を作り直し、最新の状態を保つ。

注意したいのは、SBOM は部品の一覧であって、脆弱性がないことの証明ではない点です。脆弱性の有無は、別に公表される脆弱性の情報と照らし合わせて初めて分かります。また、部品を更新すれば一覧も変わるため、一度作って終わりにはできません。

開発の早い段階からセキュリティの確認を組み込む考え方は、IoT中級の範囲のDevSecOpsとはでも扱っています。

MCPC の公式ページでは、モバイルシステム技術検定2級（100問・100分・4者択一）の出題カテゴリに「情報セキュリティ管理」があり、比率は9%と示されています（2026年9月27日確認）。当サイトでは、公式テキスト第11版の第11章「情報セキュリティ」がこの範囲に当たると推定しています（章名から当サイトが判断した対応で、公式の発表ではありません）。

4択では、次のような観点が考えられます。出題頻度は公表されていないので、特定の型が多いとは言えません。

• ✓定義：SBOM の説明を、似た管理の台帳や指標の説明の中から選ばせる。
• ✓形式：SPDX と CycloneDX が何か、ほかの用語（脆弱性の評価指標など）と取り違えた記述を見抜かせる。
• ✓使い方：脆弱性の管理での使い方や、更新の必要性を問う。
• ✓限界：SBOM があれば脆弱性がない、と言いすぎた記述を不適切として選ばせる。

試験全体の形式・日程・受検料はモバイルシステム技術検定2級とはにまとめています。

SBOM は新しく加わった用語なので、似た管理の言葉と混同しやすい点に注意します。

同じく第11版の改版の要点に挙がっている送信ドメイン認証はDMARC・SPF・DKIMとは、アクセスのたびに確かめる設計の考え方はゼロトラストとはで解説しています。

SBOMとVEXの違いでは、影響あり・影響なし・修正済み・調査中を区別します。対象製品の版・構成と、説明の発行元・更新時点を照合する自作例も扱います。