販売後製品のSBOM整備をどこから始めるか
SBOMが必要と分かっていても、「もう販売している製品にSBOMを作れるのか」という疑問を持つ方は少なくありません。結論から言うと、販売後製品でもSBOMは作れます。ただし、新製品の開発時とは異なるアプローチが必要です。
なぜ販売後製品のSBOMは難しいのか
開発時であれば、使用するOSSやライブラリは開発環境に記録されており、SBOMの生成ツールを走らせればある程度自動的にリストが作れます。一方、すでに出荷された製品では以下のような問題が起きがちです。
- 開発した時期が古く、当時の記録が残っていない
- 担当者が退職していて詳細を把握している人間がいない
- ビルド環境が再現できず、自動解析ツールが使えない
- ファームウェアが独自フォーマットで、解析が困難
これらの困難はありますが、「できないから諦める」ではなく、「どこまで把握できるか」を段階的に進めることが現実的な対応です。
ステップ1：入手できる情報から始める
まず、手元にある情報で作れる部分から始めます。
- 開発ドキュメント・設計書に記載されているOSS・ライブラリのリスト
- ソースコードや設定ファイルに残っている依存情報（package.json、requirements.txt、Makefileなど）
- ビルドスクリプト・リリースノートに記録されたコンポーネント情報
これらを元に「暫定SBOM」を作り、記録が不明確な部分には「確認中」「詳細不明」と明示しておきます。完璧を目指すより、「現時点で分かっていること」を文書化しておくことが重要です。
ステップ2：実物から解析する
ソースコードや開発記録が不十分な場合、実機のファームウェアや実行ファイルを解析する手法があります。
- バイナリ解析：出荷済みのファームウェアイメージを展開し、含まれるファイル・ライブラリ・バージョン情報を抽出します。
- 動的解析：実機を動作させながら通信や呼び出しライブラリを観察し、構成要素を推定します。
- 文字列・シンボル抽出：バイナリに含まれる文字列からライブラリ名・バージョン文字列を検索します。
これらの解析は技術的なスキルが必要ですが、ゼロから記録を作るよりも現実的です。完全な精度が出なくても、主要なコンポーネントを把握できれば、脆弱性管理の出発点になります。
ステップ3：管理の仕組みを整える
SBOMは一度作って終わりではなく、製品のアップデートに合わせて更新し続ける必要があります。また、新たな脆弱性が公表されたときにSBOMと照合できる仕組みがあることで、初めて実用的な価値が生まれます。
最低限の運用として、以下を整えることを推奨します。
- SBOMを参照・更新できる担当者の明確化
- CVEデータベースや厚生労働省のセキュリティ情報を定期確認するフロー
- 影響ありと判断した脆弱性の対応（パッチ提供・告知・報告）の手順
どこから頼めばいいか
SBOMの整備は、製品の構成・記録の状況・目的（承認申請・納入先対応・社内管理）によってアプローチが変わります。AIGISでは、現状のヒアリングから始め、製品の状態に合わせた整備方法をご提案しています。まず「自社製品の今の状況」を話していただくところから始められます。