SBOMをどうやって作るか

公開日：2026年2月12日

前回のコラムでは、SBOMというアウトプットの立ち位置について、述べました。
今回は、ツールを使用せずに、手動で作成する作業について、述べたいと思います。

SBOMの作成する手順は、およそ、以下の項目になります。
(1)SBOM管理項目の決定
(2)コンポーネント解析及び抽出
(3)バージョンの決定
(4)ライセンスの特定
(5)SBOM表への記載

順番に説明していきます。

目次

• (1)SBOM管理項目の決定
• (2)コンポーネント解析及び抽出
• (3)バージョンの決定
• (4)ライセンスの特定
• (5)SBOM表への記載

(1)SBOM管理項目の決定

SBOMには、米国 NTIA：The Minimum Elements For a Software Bill of Materials (SBOM)において、SBOM の「最小要素」の定義に関する文書が公開されており、その中で、3つの分野に定義されています。

• データフィールド
• 自動化サポート
• プラクティスとプロセス

データフィールドは、ソフトウェアを一意に特定するための情報になり、下記の項目があります。

• サプライヤー名
• コンポーネント名
• バージョン情報
• その他、一意に識別するための不可情報
• 依存関係
• SBOM作成者
• タイムスタンプ

全社的に定義されている場合、SBOMの運用を行うPSIRTや、品質管理部門、OSSを管理している部門(OSPO)、ソフトウェアライセンスを管理している部門に確認してください。
定義が存在しない場合は、上記の項目で収集するのが良いです。
また、そのようなケースでは、運用部門が存在しないか、開発部門で運用することが多いため、実際に運用に必要な情報があれば、別途、追加してください。

自動化サポートは、SBOM作成の自動化をサポートするための定義となっており、現状では、下記のタグを用いることが推奨されています。

• SPDX
• CycloneDX
• SWID

プラクティスとプロセスについて、SBOM作成の話から、少し離れてしまうかもしれませんが、重要な要素となりますので、述べていきます。

NTIA の最小要素に関する NIST 文書では、「SBOM の要求、生成、活用に関する運用を定義すること」と記載されています
つまり、SBOM をどのように作成・更新・共有・活用するかという「運用ルールと手順」になります
SBOM自身の管理について、作成及び更新のタイミング、バージョン管理が必要になります

(2)コンポーネント解析及び抽出

SBOM作成時のコンポーネントは、主に３つの範囲からなります。

• 自社で作成したソフトウェア(別会社に作成を発注したものも含む)
• サプライヤーから提供されたソフトウェア(SDKや、フレームワークなど)
• OSS

自社作成ソフトウェアについては、開発段階でバージョン管理していることが多く、特に解析の必要はありません
作成したソフトウェアを、そのままSBOMに登録します
OSSの一部を、コピー＆ペーストしてきた部分については、開発者に確認することで、抽出するしかありません。
これについては、ツールを使用しない場合、コードレビュー等で実際のコーディングについて、色々質問し、説明が出来ない場合は、オリジナルコードでは無い可能性があるので、ヒアリングして確認していきます

※オリジナルのソースコードを保障するには、ツールを使用することをお薦めします。

サプライヤーから提供されたソフトウェアについても、入手経路が明確になっているので、特に解析の必要はありません
ただし、どのようなOSSが含まれているかについては、サプライヤーから提供されたSBOMを使用することが望ましいです。
事前に提供されていることや追加で提供してもらえることを確認しておく必要があります
SBOMが提供されない場合は、サプライヤーにて管理されているソフトウェアとして、SBOMに登録していきます

OSSについては、最初に、直接使用しているソフトウェアを、SBOMに登録する。
その後、依存関係を解析して、抽出したものを登録していく。
依存関係については、リンクされているライブラリや、OSSのフォルダ構造をみて、third_partyのような名前で管理しているものを抽出する。
パッケージマネージャがあれば、それを解析していく必要がある。

(3)バージョンの決定

コンポーネントを管理する上で、ソフトウェアを識別するための情報となり、実際に使用しているバージョンを調べます。
自社作成ソフトウェアについても、バージョンを付与し管理する必要があります。
OSSについては、バージョンが変わるタイミングでソフトウェアラインセンスが変わることがありますので、使用する際は、動的に変わらないようにすることも検討します。
特に、機能の追加や既存機能の大幅な変更がある場合は、メジャーバージョンが変わりますので、ライセンスについても確認を 忘れないようにしてください。

※バージョンの付け方は、Semantic Versioning(セマンティックバージョニング)が一般的です。
形式：MAJOR.MINOR.PATCH（例：1.4.2）

MAJOR（メジャー）：互換性を壊す変更。API の大きな変更、仕様の大きな変更など
MINOR（マイナー）：後方互換性を保ったまま機能追加。新しいAPIの追加など
PATCH（パッチ）：バグ及び不具合の修正など

(4)ライセンスの特定

ソフトウェアライセンスを特定するには、提供元が、正式に発効しているライセンスの定義を見ます。
License.txt、LICENSE、READNE.md等に記載されていることが多いです。
その他には、提供元の公式サイトを見ることで、確認することができます。
使用しているバージョンに対応したライセンスを特定することが重要です。

ライセンスの特定が出来たら、条文を確認して、実際の使用方法により、必要な対応を行う必要があります。
ソースコードの開示が条件であった場合、一部か全部かにもよりますが、対応が不可能になるケースがあります。
その場合は、そのOSSが使用できなくなり、大きな手戻りが発生して、開発コストを増加させる要因になる可能性があり、注意が必要です。

(5)SBOM表への記載

予め決定した項目の情報を収集しておき、SBOM表へ記載していきます。
その際、表記ゆれの無いようにする必要がありますので、SPDXのライセンス一覧(SPDX License List)で定義されている、名称や識別子を使用します。
CycloneDXでも、使用しているため、統一した表記になり、今後の管理が容易になります。

今回は、簡単ではありますが、SBOMの作成について記載しました。