「SBOM（ソフトウェア部品表）を提出してください」。完成品メーカーや発注元の取引先から、こう求められる中小企業が増えています。初めてだと戸惑いますが、やることは整理できます。本記事で最初の一歩をご案内します。

なぜ今、SBOM提出を求められるのか

背景には、ソフトウェアのサプライチェーンを透明にする世界的な流れがあります。

  • EU CRA（サイバーレジリエンス法）：EUに製品を出す企業にSBOM・脆弱性対応を要求（CRA対応）。
  • 取引先のOpenChain/調達基準：完成品メーカーが、サプライヤーにOSS管理の証跡を求める。
  • 米FDA 524B（医療機器）・PCI DSS（決済） など、業種ごとの規制。

つまり、取引先は自社が課された要件を満たすため、部品であるあなたの製品のSBOMを必要としています。対応できれば取引継続・拡大の条件になり、できなければ取引のリスクになります。

SBOMとは（おさらい）

SBOMは、製品に含まれるソフト部品（その多くはOSS）の一覧です。詳しくは SBOMとは？なぜ今求められるのか をご覧ください。

求められたら、まず確認する3点

慌てて作り始める前に、取引先に次を確認すると手戻りが減ります。

  1. 対象：どの製品・どのバージョンのSBOMか。
  2. 形式：SPDX か CycloneDX か（指定があることが多い）。
  3. 期限と範囲：いつまでに、どこまで（依存パッケージのみか、脆弱性情報も含むか）。

中小企業の対応手順

① 依存の棚卸し

製品の依存マニフェスト／ロックファイル（package.json・requirements.txt・go.mod・pom.xml 等）を集めます。正確なバージョンが要るので、ロックファイルがあると確実です。

② SBOMを生成する

依存情報から SPDX または CycloneDX 形式でSBOMを出力します。取引先が形式を指定していれば、それに合わせます。

③ ライセンスと脆弱性を点検

SBOMができたら、同じデータから2つを点検します。

  • ライセンス：各OSSの義務（GPLの公開義務など）を確認し、配布上の論点を把握。
  • 脆弱性：各バージョンに既知のCVEが無いかを確認。

④ 提出できる体制にする

「誰が・どの形式で・どう更新して出すか」を決めます。依存は更新で変わるため、一度きりでなく更新できる仕組みにしておくと、次回以降が楽になります。

よくあるつまずき

  • 形式の不一致：先方はCycloneDX希望なのにSPDXで出した等。先に形式確認を。
  • 「宣言ベース」の限界：マニフェストのライセンスは”宣言”であり、内部に同梱された別ライセンスのコードや、自社コードへの混入は別途確認が要ります（深く見るにはソース単位のスキャン）。
  • ライセンス義務の見落とし：GPL系を製品に組み込んで配布していないか等は、専門的な確認が安全です。

まず無料でできること

  • 自社が規制（CRA等）の対象か・準備度はどうかを、5分・登録不要で確認：EU CRA 5分セルフチェック。
  • 製品の依存リストから、**OSSライセンスを整理した「無料サンプル」**をお作りします（製品のソース本体は不要・お問い合わせ）。

取引先からのSBOM要求は、慌てず手順で対応すれば乗り切れます。最初の「依存の棚卸し（SBOM）」だけでも作っておくと、次の要求にも強くなれます。