OSSが少ない/ない製品のSBOMはどう作る？
（兼務でも回る最小手順）
「うちはOSSをあまり使っていないから、SBOMはまだ要らないのでは？」
この認識で止まっているサプライヤーは少なくありません。
ですが、SBOMは“OSS一覧”ではなく、製品を構成するソフトウェア要素の棚卸しです。
CISAはSBOMを、ソフトウェアを構成するコンポーネントの入れ子状のインベントリ、いわば“ingredients list（材料表）”として説明しています。NTIAの「SBOM minimum elements」も、最低限必要なものとしてデータ項目だけでなく、生成・利用のための運用やプロセスを挙げています。
つまり、OSSが少なくても、ソフトウェア構成を説明する必要があるならSBOMの対象です。
先に結論：OSSが少ない/ない製品でもSBOMは作れる
結論はシンプルです。
-
“OSSが少ない”なら
その少ないOSSと、商用/自社ソフトを含めてSBOM化する。 -
“OSSがない”なら
スコープ内に含まれる商用部品、自社ソフト、RTOS、BSP、ブートローダ、診断/更新モジュールなどを整理する。
それでも本当に第三者ソフトが無いなら、「何を確認した結果、スコープ内に第三者ソフトが無いと判断したか」を残した上で、最小の構成宣言として扱います。
SBOMの価値は“OSSの量”ではなく、対象版数と構成を説明できることにあります。
まず誤解を解く：SBOMは「OSSだけの表」ではない
実務で多い誤解は次の2つです。
- × OSSが少ない ＝ SBOM不要
- × SBOM ＝ ライセンス一覧
どちらも不十分です。NTIAのSBOM minimum elementsは、最低限のデータ項目としてコンポーネント名、サプライヤ、バージョン、その他の識別に必要な情報を重視しています。これは「OSSだけ書けばよい」ではなく、構成要素として追うべきソフトウェア部品を特定できることが本質だという意味です。
さらに、CISAのSBOM FAQはSBOMの作成・配布・利用をまとめて扱っており、SBOMを単なる提出書類ではなく、継続運用に載せるべきものとして整理しています。
3つのパターンに分けると迷わない
パターン1：OSSは少ないが、商用ソフトや自社コードは多い
このケースがいちばん多いです。
例えば、暗号ライブラリは商用、通信スタックはベンダー提供、アプリ層は自社開発、という構成です。
この場合のSBOMは、OSSの有無ではなく、ソフトウェア構成を版数付きで説明する台帳として作ります。
パターン2：OSSは使っていないが、RTOS/BSP/ベンダーバイナリがある
「OSSなし」と言っても、実際にはRTOS、BSP、マイコンSDK、ブートローダ、診断ツール、更新モジュールなど、第三者提供のソフトウェア要素があることが多いです。
この場合、供給元が自社ではないソフトウェアは“追える状態”にするのが基本です。
パターン3：本当に第三者ソフトが無い
これが成立する製品は多くありませんが、ゼロではありません。
その場合も、「何を確認し、どこまでをスコープに入れ、第三者ソフト無しと判断したか」を残す必要があります。
なぜなら、OEMや監査が知りたいのは“ゼロと言っていること”ではなく、ゼロと判断した根拠だからです。
まず固定すべき最小項目（Excelで十分）
OSSが少ない/ない製品で最初に持つべき最小項目は、次の通りです。
この中で最重要は 「製品バージョン」と「コンポーネントバージョン」を分けて持つこと です。CVE照会では必ず「どの製品版まで影響するのか」が問われます。
さらに、assembled products に関するCISAのガイダンスでも、複数コンポーネントを組み合わせる製品では、バージョン変化を追えることが重要だとされています。
手順：兼務でも破綻しないSBOM作成ステップ
スコープを先に切る
最初から全製品をやらないことです。まずは次のどれかに当てはまる製品から始めます。
- OEM照会が来やすい製品
- 外部IFや更新機能を持つ製品
- 顧客向け派生が多く、版数差分が出やすい製品
ソフトウェア要素を“列挙”する
ここではOSSかどうかで分けず、製品に含まれるソフト要素を全部出すことが目的です。候補は次のとおりです。
- 自社アプリケーション
- ベンダー提供ミドルウェア
- RTOS ／ BSP/ドライバ
- 暗号/通信ライブラリ
- ブートローダ ／ 診断/更新関連モジュール
証跡を残す
「なぜそう書いたか」の根拠を残します。候補になるのは、設計資料、供給元文書、構成表、ビルド設定、リリース記録などです。
本当に“第三者ソフトなし”とするなら、その確認に使った資料IDを残します。
提出版と社内版を分ける
CISAのSBOM FAQでも、SBOMの配布・共有には実務上の論点があることが示されています。一般にコンポーネント一覧そのものは多くの場合IPそのものではありませんが、敏感な情報を含む場合は“known unknowns”のような形で一部を伏せる運用もあり得ます。つまり、社内正本を持った上で、提出版は必要な範囲に絞るのが安全です。
更新トリガーを決める
更新ルールがないと、SBOMはすぐ古くなります。最小はこの3つで十分です。
- 製品リリース時
- 第三者ソフト更新時
- OEM照会時（必要な備考・証跡を追記）
“OSSが無い”と説明するときの書き方
OEMや監査で「OSSは使っていますか？」と聞かれたときに、「使っていません」だけで終えると弱いです。
次のように、範囲と根拠 を含めて返すのが安全です。
この書き方なら、「OSSなし」でも “何を確認したのか” が説明できます。
自社製品の構成に合わせて、SBOM整備・提出運用をどこから始めるか整理したい方はご相談ください。
【無料】オンライン相談を予約するよくある失敗（ここだけ避ける）
- OSSが少ない＝SBOM不要 と判断してしまう
- RTOS/BSP/ベンダーバイナリ を“自社ソフト”扱いで埋もれさせる
- 製品版数が無く、照会に答えられない
- 本当にゼロかを確認した証跡が無い
- 提出版と社内版を分けず、出しすぎる or 出せなさすぎる
FAQ：OSSが少ない場合のSBOMについて
必要になることがあります。SBOMはOSS一覧ではなく、製品に含まれるソフトウェア構成の説明資料だからです。OEM照会や監査では、OSSが少なくても対象版数や供給元を答えられることが重要です。
コンポーネント名、バージョン、供給元、搭載箇所、更新日を最小項目として持てば十分始められます。後からライセンスや証跡列を追加できます。
不要と即断せず、「何を確認して第三者ソフト無しと判断したか」を残してください。スコープ宣言と確認根拠があると、OEMや監査に説明しやすくなります。
はい。まずはExcelで最小項目を固定し、更新運用を回すことが重要です。その後、必要に応じてSPDXやCycloneDXへ移行する方が現実的です。
自社の構成表から、自動で脆弱性チェックしませんか？
Auto PSIRT Cloudなら、商用ソフトやRTOS情報が混ざったExcelの部品表でも、そのままアップロードして管理が可能。自動で関連する脆弱性がないか突合・スクリーニングを行います。