正しいSBOMを作るには？基本から応用までを解説
-
│
はじめに
近年、製品やサービスのセキュリティに対する社会的な要求が高まっています。特にIoT、医療、自動車分野などでは、法令や規制を背景に、SBOM（Software Bill of Materials：ソフトウェア部品表）の作成・管理が求められるようになりました。
本記事では、技術者の視点から、「なぜSBOMを作成する必要があるのか」「作成時にどのような注意点があるのか」「ツール選定で考慮すべきポイント」について、実践的に解説していきます。自社でSBOMを正しく運用するために、基本から応用まで整理していきます。
目次
- SBOMを作成する理由
- 法令・規制への対応
- 脆弱性管理・製品品質向上
- SBOM作成時の注意ポイント
- 作成側・受領側の合意形成
- 主流フォーマットと最小要素
- 記載項目のミス・抜け漏れ対策
- SBOM作成観点でのツール選定ポイント
- ツールが必要な理由
- 選定時に確認すべき機能
SBOMを作成する理由
法令・規制への対応
SBOMの作成が求められる背景として、国内外の厳格なセキュリティ関連の法令・規制が徐々に増えています。日本国内ではIoT製品向けに「セキュリティ適合性評価制度（JC-STAR）」、医療分野では「薬機法」の改正でSBOMの整備が必須項目となっています。海外では、アメリカの大統領令（EO 14028）、EUサイバーレジリエンス法（CRA）、自動車業界のUN R155／UN R156など、多様な分野でSBOMの作成・提出が企業に義務付けられています。
CRAでは、罰金が最大1,500万ユーロ、または前年度全世界売上の2.5%まで課せられる可能性があります。これらの法令・規制は今後さらに拡大・厳格化していく見込みです。
脆弱性管理・製品品質向上
法令対応だけでなく、SBOMが現場で活用される主なユースケースも重要です。SBOMによって出荷後の製品の脆弱性判定が容易になり、ユーザーからの問い合わせ対応や開発部門との連携がスムーズになります。また、新たな脆弱性情報が公開された際にもSBOMと照合して自社製品への影響を効率的に確認できます。
理想的には、サプライチェーン全体の関係者がそれぞれの責任範囲でSBOMを作成し、最終製品の透明性と脆弱性管理力を高めていくことが重要です。
SBOM作成時の注意ポイント
作成側・受領側の合意形成
SBOM作成の際は、作成者（製造業やベンダー）と受領者（利用者やエンドユーザー）で記載内容やフォーマットについて事前に合意しておくことが重要です。例えば、「SPDX」「CycloneDX」といったフォーマットの選定や、記載すべきデータフィールド、品質管理や提出・更新方法などを明確にしておくことで、運用時のトラブルを防げます。
主流フォーマットと最小要素
現在主流となっているSBOMフォーマットはSPDXとCycloneDXで、SPDXは特にライセンスとコンプライアンス管理に強みがあり、CycloneDXはセキュリティに重点を置いています。
また、SBOM作成時は、NTIAが定義する「SBOM最小要素」にも注意しましょう。データフィールドとして、サプライヤー名、コンポーネント名、コンポーネントバージョン、その他の一意な識別子、依存関係、SBOMの作成者、タイムスタンプの7項目が挙げられます。手作業でSPDXを構築する場合も、この7項目は必ず記載しましょう。
記載項目のミス・抜け漏れ対策
タイムスタンプ・作成者の書き方
タイムスタンプは必ずUTC形式で「YYYY-MM-DDThh:mm:ssZ」と記載し、SBOM作成者は組織名、担当者名、ツール名のいずれかを明記します。
識別子（CPE、PURL）の表記ゆれ・複数存在の問題
脆弱性管理やコンポーネント特定に用いる識別子（CPE、PURL）は、開発会社の買収やブランド変更などにより表記ゆれや複数割り当てが生じることがあります。例えば「ThreadX」はMicrosoftやEclipseへの移管により複数のCPEが付与されており、情報収集時に抜け漏れのリスクが高まります。これらを正しく管理するには、複数識別子を重ねて収集・照合する運用が必要です。
コンポーネント名・バージョン・サプライヤー名の表記ゆれ
表記の統一も重要な注意点です。例えば「OpenWrt」と「openwrt」、「18.06.2」と「18.6.2」など、細かな違いがあると脆弱性情報の検索や管理業務に支障が出ます。組織内で書式ルールや管理指針を設定しておくとよいでしょう。
依存関係の記述
SBOMではコンポーネント間の依存関係（relationship）を正確に記載します。SPDXでは「DESCRIBES」「CONTAINS」「DEPENDS_ON」「DYNAMIC_LINK」など多様な関係タイプを用いて構造を表現します。複雑なソフトウェア構成を持つ場合は特に注意が必要です。
SBOM作成観点でのツール選定ポイント
ツールが必要な理由
IoT機器や複雑な製品では、コンポーネント数が100以上になるのも珍しくありません。手作業でのSBOM作成は人的ミスや工数過多につながりやすく、正確性・効率性を担保するためにも専用ツールの導入が推奨されます。ツールを活用しつつ、エンジニアが最終確認する運用が現実的です。
選定時に確認すべき機能
ツール選定時は、以下の観点で比較検討しましょう。
- 解析能力：対応言語や検出力（誤検出・漏れの頻度も含む）
- データ出力：SPDXやCycloneDXなど、多様なフォーマットへの出力可否
- チェック・精査機能：自動レビュー、品質管理機能
- GUIの有無：直感的な操作性
- 他ツール連携・自動化：CI/CDパイプラインとの連携、ソフトウェアライフサイクル全体の効率化
- サポート体制：問い合わせ対応、OSS管理コンサルティング等
適切なツール選定で、SBOM作成・運用の負担を最小化できます。
SBOM作成は今や企業のセキュリティ・コンプライアンス対応の要となっています。小規模なプロジェクトなら手作業も可能ですが、正確性と効率化を求めるならツール活用が不可欠です。自社製品のセキュリティ品質向上のためにも、SBOM運用体制の整備を検討してみてください。
関連ソリューション
・Black Duck Software
・LeanSeeks
本記事の詳細は、無料動画ポータル「Macnica Security& DX Stream」で公開中！
１度の登録で、100セッション以上が見放題！今すぐ動画視聴申し込みする↓
SBOM管理や脆弱性管理に関するご相談は、マクニカまでお気軽にお問い合わせください。
自社の現場に合った運用支援やソリューション導入にも対応しています。
関連製品や最新情報も動画ポータル内で紹介していますので、ぜひ一度ご覧ください。
