システム開発を外部に委託していると、監査法人や親会社、大口取引先から「委託先の SBOM 対応状況を確認してほしい」と依頼を受ける場面が増えてきました。経済産業省が SBOM 導入手引 ver2.0 を公表し、EU ではサイバーレジリエンス法（CRA）が発効するなど、ソフトウェアサプライチェーンに関する要請は年々具体化しています。
とはいえ、「SBOM を発注要件に組み込むべきか」「契約書にどこまで書けばよいのか」「受け取った SBOM を社内で活用できるのか」といった実務上の疑問に対し、明確な指針を持てている発注者はまだ多くありません。ベンダー向けの解説記事は増えましたが、発注者視点で「何をどこまで求めるか」を整理した情報は限られているのが実情です。
そこで本記事では、SBOM の基本を発注者に必要な最小限の粒度で押さえたうえで、発注要件に組み込むか否かの判断軸、契約書・要件定義書に規定すべき条項の骨子、受け取った SBOM を継続運用につなげる手順を、経済産業省の SBOM 導入手引 ver2.0 を踏まえて整理します。中小・中堅企業でも取り組める段階導入アプローチにも触れますので、社内・ベンダーとの協議に向けた土台としてご活用ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
SBOM（ソフトウェア部品表）とは？発注者が押さえるべき最小限の定義
SBOM（Software Bill of Materials）は、日本語では「ソフトウェア部品表」と訳される、ソフトウェアを構成する部品（コンポーネント）と、それらの依存関係を一覧化した文書です。製造業における BOM（部品表）と同じ発想で、「このソフトウェアは何と何を、どのバージョンで、どのライセンスで組み合わせて作られているか」を機械可読な形式で記録します。
発注者が押さえるべきポイントは、SBOM 自体を「読み解く」必要は必ずしもないという点です。重要なのは、SBOM があることによって「委託先が納品したソフトウェアの中身が可視化され、脆弱性照合や責任範囲の議論の出発点にできる」ことにあります。
SBOM の基本定義と含まれる主な情報項目
SBOM に含まれる情報は、フォーマットや実装によって差はありますが、概ね次のような項目で構成されます。
- コンポーネント名とバージョン: 使用しているオープンソースソフトウェア（OSS）や商用ライブラリの識別情報
- サプライヤー情報: そのコンポーネントを提供している組織（例: Apache Software Foundation、npm レジストリの特定パッケージ作者など）
- 依存関係: あるコンポーネントが別のどのコンポーネントに依存しているかの構造情報
- ライセンス情報: 各コンポーネントの利用ライセンス（MIT、Apache 2.0、GPL など）
- 一意識別子: PURL（Package URL）や CPE（Common Platform Enumeration）など、脆弱性データベースと突合できる識別子
- 作成者・作成日時: SBOM を作成した主体と時点
これらは米国 NTIA（National Telecommunications and Information Administration）が定めた「SBOM の最小要素」を基礎としており、経済産業省のSBOM 導入手引 ver2.0でも国内標準として言及されています。
発注者が SBOM を持つと何が見えるか
発注者にとっての SBOM の実用的な意義は、次の 4 点に集約できます。
- コンポーネントの一覧が見える: 委託先が独自開発した部分と、OSS・商用部品を組み合わせた部分の割合が把握できる
- 依存関係の階層が見える: 直接使っている部品だけでなく、その部品が内部で利用している「間接的な依存関係」も追える
- ライセンスの一覧が見える: 事業モデル上リスクとなり得るライセンス（例: GPL 系）の混入を確認できる
- 脆弱性照合の起点になる: NVD や JVN といった脆弱性データベースと突合することで、既知の脆弱性を含む部品の有無を機械的に確認できる
言い換えれば、SBOM は「委託先ベンダーの内部事情をブラックボックスにしないための共通言語」です。発注者はこの共通言語を持つことで、「サプライチェーン攻撃が発生したとき、自社が発注したシステムに影響があるかどうか」を素早く判断できる素地を整えることになります。
なぜ今、発注者側で SBOM が話題になっているのか
SBOM 自体はソフトウェア工学の中では以前から存在した概念でしたが、ここ数年で急速に「発注者・調達者側でも避けて通れないテーマ」として浮上しました。その背景には、実際に起きたサプライチェーン攻撃と、国内外の規制動向という二つの流れがあります。
サプライチェーン攻撃の実例と発注者側への波及リスク
象徴的な事例が、2021 年 12 月に発生した Log4Shell（CVE-2021-44228）です。Java の広く使われているログ出力ライブラリ Apache Log4j に、外部から任意のコードを実行できる重大な脆弱性が見つかりました。CVSS スコアは最大値の 10.0 が付けられ、世界中の Web システムが影響を受けたと言われています（トレンドマイクロによる解説）。
Log4j は「間接的な依存関係」として組み込まれているケースが多く、開発者本人が「自社のシステムが Log4j を使っている」と自覚していない例も珍しくありませんでした。SBOM が整備されていれば、「どのシステムに Log4j のどのバージョンが含まれているか」を機械的に照合できたはずですが、当時 SBOM を整備していた組織は限定的で、多くの発注者・運用者が手作業での棚卸しを迫られました。
もう一つの代表例が、2020 年末に明らかになった SolarWinds 事件です。ネットワーク監視製品の正規アップデートに攻撃者が悪意あるコードを混入させ、その製品を利用していた米政府機関・大手企業を含む多数の組織に侵入経路を開きました。「信頼していたベンダー製品の中身に何が含まれていたか」が事後的に把握できないことが、被害拡大の一因になったと指摘されています。
発注者から見れば、これらは「委託先が納品したシステムに含まれるコンポーネントの中に、後から重大な脆弱性が発覚するリスクが常にある」ことを意味します。SBOM はそのリスクを完全にゼロにするものではありませんが、「自社発注システムが影響を受けるかどうか」を短時間で判断するための土台になります。
国内動向：経済産業省「SBOM 導入手引 ver2.0」が発注者にも触れている理由
国内では、経済産業省が 2023 年 7 月に SBOM 導入手引の初版を公表し、2024 年 8 月には ver2.0 に改訂しました（経済産業省プレスリリース（2024 年 4 月改訂案公表時））。ver2.0 では、SBOM を「作る側」の実務手順だけでなく、SBOM を用いた取引モデル、すなわち発注者と受注者の間で SBOM をどう授受・活用するかが具体的に扱われています。
手引 ver2.0 では、SBOM の作成・共有・運用に関するプロセスや、取引時に発注者側が確認すべき事項、脆弱性管理への活用手法などが整理されており、日経クロステックの解説記事も「経産省の本気が見える」と評しています（日経クロステック解説）。
発注者にとっての要点は、「SBOM の導入は開発ベンダーだけの課題ではなく、調達・発注側もその活用方法を理解して取引条件に組み込む必要がある」という位置づけが公的に示されたことにあります。監査や親会社から SBOM 対応状況を問われた際、この手引が事実上の参照点となる場面が今後さらに増えていくと考えられます。
海外動向：EU サイバーレジリエンス法・米国大統領令が日本発注者に及ぼす影響
海外では、米国と EU の動きが日本の発注者にも影響を及ぼします。
米国では、2021 年 5 月にバイデン大統領が署名した大統領令 14028「国家のサイバーセキュリティの強化」により、連邦政府へのソフトウェア納入において SBOM の提供が求められるようになりました。同年 7 月には NTIA が「SBOM の最小要素」を公表し、SBOM に含むべき情報項目・データフィールドの標準が明確化されています（JETRO のビジネス短信）。
EU では、2024 年 12 月に発効したサイバーレジリエンス法（CRA）が特に注目されます。CRA は「デジタル要素を含む製品」の製造者にセキュリティ対策と脆弱性対応を義務付ける規則で、SBOM の作成・維持もその一部として求められます。段階適用のスケジュールでは、脆弱性・インシデント報告義務が 2026 年 9 月頃から、全面適用が 2027 年 12 月頃からと整理されています（日立ソリューションズによる解説）。
これらの規制は直接的には海外の話ですが、日本の発注者にとっても無関係ではありません。EU 市場に製品を投入している自社製品の発注案件はもちろん、グローバルサプライチェーンに組み込まれる部品・SaaS を利用する案件では、取引先からの要請という形で SBOM の提出を求められる場面が現実に増えています。国内 SIer やセキュリティベンダーの解説記事でも、CRA を「日本企業も無関係ではない」と位置づけて注意喚起する傾向が続いています（トレンドマイクロによる考察）。
SBOM を発注要件に組み込むべきか？案件別の判断フレーム
ここからが本題です。「SBOM は重要である」ということまでは分かっても、「では、自社の発注案件でどこまで要求すべきか」が判断できずに止まってしまうケースは少なくありません。すべての案件で一律に SBOM を求めるのは費用対効果に見合わず、逆に一切求めないのはリスク管理として不十分です。ここでは、発注者が案件ごとに判断するための 4 つの軸を整理します。
判断軸1: 取り扱うデータの機密度・規制業種該当性
最初に押さえるべきは、そのシステムが扱うデータの重要度と、業種特有の規制への該当性です。
- 個人情報保護法上の要配慮個人情報、金融規制（FISC 安全対策基準など）、医療情報（3 省 2 ガイドライン）、政府調達関連など、規制業種に該当するシステムは SBOM を要求する優先度が高くなります
- 顧客情報を含む基幹業務システム、決済・認証を担うシステムも、脆弱性を突かれた場合の影響が広範囲に及ぶため、優先度は高いと考えられます
- 一方、社内向けの参照系ツール、社外公開しないプロトタイプ、廃止予定のレガシー改修などは、優先度が下がる場合があります
判断軸2: 案件規模と OSS 利用量の見込み
SBOM の価値は、そもそも OSS や外部ライブラリを多用するシステムほど高くなります。
- モダンな Web アプリケーション、SaaS、モバイルアプリのような案件では、数百から千を超える OSS 依存関係を持つことが珍しくないため、SBOM 抜きで脆弱性管理を続けるのは現実的ではありません
- 逆に、既製パッケージ製品の設定変更のみに近い案件、ノーコードツール上の設定案件など、外部依存が薄い案件では SBOM 要求の緊急度は下がります
判断軸3: 保守・運用契約の長さと更新頻度
SBOM が真価を発揮するのは、「納品時の 1 回」ではなく「継続運用中に新しい脆弱性が発覚したとき」です。
- 5 年、10 年と長期保守を想定するシステムでは、公開時には存在しなかった脆弱性が後から発覚することを前提に、SBOM の更新を含む運用契約を組んでおく価値が高くなります
- 短期間のキャンペーンサイト、単発の PoC のように運用期間が明確に短い案件では、費用対効果を見て判断する余地があります
判断軸4: 取引先・監査法人からの要請有無
自社の内部要件だけでなく、外部からの要請有無も無視できません。
- 監査法人から「委託先の SBOM 対応状況を確認するよう」指示されている場合、発注要件に組み込む必然性は自ずと高くなります
- 大口取引先や親会社が SBOM を含むサプライチェーンセキュリティ基準を求めている場合も同様です
- EU 市場への製品供給に関わる案件は、CRA の適用スケジュールを踏まえて前倒しで対応を進めることが望まれます
パターン別の推奨レベル（必須／推奨／任意）
上記 4 つの軸を掛け合わせた大まかな目安として、次のような整理が現実的です。
パターン | SBOM 要求レベル | 主な根拠 |
|---|---|---|
個人情報・決済・規制業種に該当する基幹システム | 必須 | 機密度・規制要請・監査対応 |
一般顧客向け Web サービスの新規開発（OSS 多用） | 推奨 | 継続運用中の脆弱性発覚に備える |
EU 市場に関わる製品開発 | 必須（前倒し） | CRA 適用スケジュール |
社内向け業務ツールの新規開発 | 推奨（軽量版で開始可） | 中程度のリスク、まず取り組みの土台作り |
短期キャンペーンサイト・PoC | 任意 | 費用対効果を個別判断 |
ノーコード設定・パッケージ導入のみ | 任意 | 外部依存が薄い |
このマトリクスはあくまで出発点であり、業界ガイドラインや自社のセキュリティポリシーに照らして調整してください。重要なのは「案件ごとに機械的に判断できるフレームを事前に社内合意しておく」ことです。フレームがないと、案件担当者が個別に悩むうえに、ベンダーとの交渉でも軸がぶれてしまいます。
契約書・要件定義書で規定すべき SBOM 関連条項
SBOM を発注要件に組み込むと決めた後に発注者が直面するのが、「契約書・要件定義書に、具体的に何をどう書けばよいか」という悩みです。ここでは経済産業省のSBOM 導入手引 ver2.0で示されている「SBOM 取引モデル」の考え方を踏まえ、規定すべき条項の骨子を 5 つに分けて整理します。文言例まで踏み込むと自社の法務・情シスとの調整が必要ですが、以下の粒度であれば社内の議論の出発点として使えるはずです。
SBOM の提出範囲（対象コンポーネント・階層深度）を明記する
まず合意しておきたいのが「どこまでを SBOM の対象とするか」です。曖昧なままだと、ベンダーは「直接依存する主要 OSS のみ」を出し、発注者は「間接依存も含めた全部品」を期待するといった認識ずれが起きます。
- 対象コンポーネント: 自社開発コード、直接依存する OSS、間接依存する OSS、商用ライブラリ、コンテナベースイメージ、外部 API を含むか
- 階層深度: 直接依存のみ（第 1 階層）か、推移的依存関係（第 N 階層）まで含めるか
- 対象環境: 本番相当のビルド構成のみか、開発・テスト依存も含むか
フォーマット・更新頻度・提出タイミングを合意する
次に、SBOM のフォーマットと運用サイクルを決めます。
- フォーマット: 主要な標準として SPDX（Linux Foundation 系。ライセンスコンプライアンスに強く、国際標準規格化されている）と CycloneDX（OWASP 系。セキュリティに強く、脆弱性照合との親和性が高い）があります。両者の違いは開発元の目的が異なる点にあり、選定の際の考え方は @ITの比較記事などの解説を参考にできます。発注者側で強い理由がなければ、ベンダーが CI/CD に組み込みやすい方を選び、必要に応じて相互変換する運用も現実的です
- 更新頻度: 納品時のみか、リリースごとか、月次・四半期ごとか
- 提出タイミング: 検収前・検収時・運用開始後の定期報告のいずれか
責任分担とコスト負担
SBOM の作成・維持には工数がかかります。ここを曖昧にすると、後から「追加費用」の話が発生しがちです。
- 作成責任: SBOM の生成はベンダー責任とするか、発注者側のツールで生成するか
- 作成コストの扱い: 見積に含めるか、別項目として明示するか
- 脆弱性検出時の対応義務: 重大脆弱性が発覚した場合の通知義務・調査義務・修正対応の範囲と応答時間（SLA）
- 修正対応のコスト負担: 保守契約の範囲内か、都度見積か
権利・機密保持
SBOM には、ベンダーの技術資産・実装ノウハウの一端が含まれます。取扱いのルールを明確にしておきます。
- 所有権・利用権: 発注者が受け取った SBOM を、社内の脆弱性管理システムに取り込む権利、監査法人に提出する権利、後継ベンダーへの引継ぎに使う権利
- 機密保持: SBOM に含まれる情報の第三者開示制限
- 再委託先の SBOM: ベンダーがさらに再委託している場合、再委託先のコンポーネントも SBOM に含めるかどうか
よくある誤解：SBOM 提出＝脆弱性ゼロの保証ではない
契約条項の議論をするうえで、発注者側が持っておきたい重要な認識があります。それは「SBOM の提出は、そのソフトウェアに脆弱性が一切ないことを保証するものではない」という点です。
SBOM は、あくまで「何が使われているか」を可視化する文書です。可視化されたコンポーネントに未発見の脆弱性が潜んでいる可能性はゼロにできませんし、新しい脆弱性は日々発見されます。つまり SBOM は「静的なチェック」ではなく「継続的な監視の起点」として位置づけるべきものです。
この認識をベンダーと共有していないと、「SBOM を出したのだから脆弱性は無いはずだ」といった非現実的な期待が生まれ、後の運用フェーズで衝突する原因になります。契約書には「SBOM の提出は脆弱性の非存在を保証するものではなく、継続的な監視・対応義務と一体で運用する」旨を、前文や覚書に明記しておくとよいでしょう。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
受け取った SBOM を活かすための受入・運用プロセス
契約と要件が整い、いざベンダーから SBOM を受領した後、発注者が次に悩むのが「これを社内でどう扱えばよいか」です。読み解くための専門知識がない、突合するツールが決まっていない、といった不安から、SBOM が「もらったまま放置される文書」になってしまう例は少なくありません。ここでは、無理なく取り組める受入・運用プロセスを段階的に示します。
受入時チェックリスト（フォーマット妥当性・網羅性・更新履歴）
まず受入時に確認したいのが、SBOM 自体の妥当性です。難しい技術評価は必要ありません。次のチェックリストをベンダーとの受入会議で使うだけでも、抜けを大きく減らせます。
- 合意したフォーマット（SPDX / CycloneDX）で提出されているか
- 合意した対象範囲（第 N 階層までの依存関係、開発・本番の区別）が反映されているか
- 各コンポーネントに バージョン情報が含まれているか（「latest」等の曖昧な記述になっていないか）
- 各コンポーネントに 一意識別子（PURL や CPE など）が含まれているか
- ライセンス情報が含まれているか
- 作成者・作成日時が明記されているか
- 前回受領版がある場合、差分（追加・削除・バージョン変更）が説明可能か
脆弱性データベース（NVD / JVN）との突合体制の作り方
SBOM を継続監視につなげるには、脆弱性データベースとの突合が欠かせません。突合対象として代表的なのは、米国の NVD（National Vulnerability Database）と、国内の JVN（Japan Vulnerability Notes）です。
小さく始めるなら、次のような体制設計が現実的です。
- 月次照合からスタートする（毎日突合できるのが理想だが、初期は無理せず月次で運用を回す）
- 一次受け入れは 情シス内の担当者 1〜2 名を指名し、社内の脆弱性管理台帳と紐付ける
- 重大な脆弱性（CVSS スコア 7.0 以上を目安）が発見されたら、ベンダーへ照会し対応可否と時期を確認する
- 対応可否の判断は「発注者が業務影響を、ベンダーが技術的難易度を」持ち寄って合議で決める
継続運用：更新版 SBOM の受領サイクルと社内共有
SBOM は一度受け取って終わりではありません。ベンダーがソフトウェアをアップデートするたびに更新版を受け取り、差分を確認する運用が必要になります。
- リリースごとの更新版受領を基本ラインとし、保守契約の中で明記しておく
- 大規模なアップデートの前後では、変更点説明と一体で受領する
- 社内では、脆弱性管理台帳と SBOM 受領履歴を紐付けて保管する
- 監査対応時に第三者に説明できるよう、受領日・提出者・確認結果の記録を残す
SBOM 管理ツール活用の判断（自社導入 or ベンダー提供）
SBOM の受入・突合・管理は、Excel 台帳での運用も不可能ではありませんが、コンポーネント数が増えると急速に破綻します。ここでツール活用の判断が必要になります。
- ベンダー提供のツールに乗る: ベンダーが SCA（Software Composition Analysis）ツールで脆弱性照合レポートまで含めて提供してくれる場合、初期はこれに乗るのが最も低コストです。ただし委託先ロックインには注意が必要です
- 自社で SBOM 管理ツールを導入する: 複数ベンダーからの SBOM を横断管理したい、監査要件として自社側での管理が必要、といった状況では自社導入が現実的です
- 段階的にツールを高度化する: 最初は Excel + 月次目視、次に軽量な OSS ツール（例: dependency-track など）、最終的に商用 SCA ツール、といった段階アプローチも取れます
いずれのパターンでも、「発注時に SBOM を要求する」段階と、「継続運用で活用する」段階では、必要な体制・ツール投資が異なることを社内で認識しておくことが大切です。
中小・中堅発注者のための段階導入アプローチ
「大企業や規制業種ならまだしも、自社の規模で SBOM 対応を進めるのは重すぎるのでは」という不安を持たれる発注者は少なくありません。しかし、SBOM 対応は最初から完成形を目指す必要はなく、段階的に取り組むことが十分に可能です。中小・中堅企業の発注者が現実的にたどれるステップを整理します。
Step 1: 新規案件でパイロット的に SBOM 提出を依頼する
いきなり全案件を対象にせず、新規に発注する案件のうち影響度が中程度のものを 1 件選び、パイロットとして SBOM 提出を要件に組み込みます。この段階では次を目安にします。
- フォーマットはベンダーが提供しやすい方（SPDX か CycloneDX）に合わせる
- 更新頻度は「納品時のみ」から始める
- 受入チェックは、本記事で示したチェックリストを社内で運用する
- 脆弱性突合は「月次で 1 回、重大脆弱性のみ確認」の軽量運用にとどめる
パイロットの目的は完璧な運用構築ではなく、「自社の発注プロセスに SBOM を組み込むと、どこに手間が発生するか」を体感することです。
Step 2: 既存の重要システムに範囲拡大する
パイロットの学びを踏まえ、次は既存システム（保守中の案件）にも範囲を広げます。ここでポイントになるのは、既存システムに対して SBOM を後から要求する場合、ベンダー側の対応コストと、既存契約の改訂交渉が発生することです。
- 対象は「機密度が高い」または「保守期間が長く残っている」システムに絞る
- ベンダーに対しては「既存案件への SBOM 提出を保守契約の変更点として合意したい」旨を丁寧に伝える
- コスト負担については、「一度作成すれば以降は差分更新でよい」ことを共有し、初回作成費用の妥当な範囲を協議する
Step 3: 全案件標準化と社内ガバナンス確立
パイロットと既存拡大の 2 段階を経て、社内に「SBOM を発注に組み込むノウハウ」が蓄積された段階で、標準化のフェーズに入ります。
- 発注時の要件定義テンプレートに、SBOM 関連条項を標準組込
- 案件区分（機密度・規模・保守期間）ごとの SBOM 要求レベルを社内ガイドラインとして定義
- 情報セキュリティ委員会など、経営レベルの意思決定に SBOM 対応状況を組み込む
- 監査法人・親会社への説明資料として、SBOM の運用状況をまとめる
ベンダーから「対応できない」と言われた場合の交渉ポイント
現場でよくあるのが、ベンダーから「SBOM の提出は難しい」と回答されるケースです。ここで諦めず、次のような交渉ポイントを持っておくと建設的な議論につながります。
- 背景と目的の共有: 「SBOM を求めるのは、契約打ち切りの材料にするためではなく、継続監視のためであり、共同で運用する意図であること」を先に伝える
- 段階的な提出: 最初から完全版でなく、「主要 OSS の一覧＋ライセンス情報」だけの簡易版から始める提案をする
- ツール選定の柔軟性: ベンダーが日常使いしている CI ツールで生成できるフォーマットに合わせる
- 費用の透明化: 「SBOM 作成にかかる初回費用」と「継続更新の費用」を切り分けて協議する
- 代替案の提示: どうしても SBOM 提出が難しい場合、脆弱性対応 SLA の強化・保守レポートの定期提出などで補完する案を用意する
「SBOM を出せるベンダーが良いベンダー、出せないベンダーが悪いベンダー」という二元論ではなく、「一緒にサプライチェーンセキュリティを改善する関係をどう築くか」という視点で協議に臨むことが、長期的な関係維持と実効性の両立につながります。
発注者が SBOM 対応を進めるうえで押さえたい関連トピック
最後に、SBOM を単体のタスクとして扱うのではなく、発注時の総合的なセキュリティ確認プロセスの一部として位置づけるために、隣接する関連トピックを整理しておきます。
OSS ライセンス確認と SBOM の関係
SBOM に含まれるライセンス情報は、そのままオープンソースライセンスの棚卸しに使えます。特に GPL 系ライセンスは、リンク方法や配布形態によって自社成果物への影響が変わるため、事業モデル（SaaS 提供か、パッケージ配布か等）に応じたチェックが欠かせません。SBOM の受入プロセスに、ライセンス確認の観点を明示的に組み込むと、脆弱性管理とライセンスコンプライアンスを一つの流れで扱えます。発注者が押さえるべき OSS ライセンスの主要リスクと対処については発注者のためのOSSライセンスリスクでも解説していますので、あわせてご参照ください。
委託契約におけるセキュリティ条項全般との整合性
SBOM 関連条項は、委託契約のセキュリティ条項全体の中の一要素です。既存の秘密保持条項、脆弱性対応義務、インシデント通知義務、監査権限などとの整合性を取ることで、契約全体としての実効性が上がります。特に「重大脆弱性発覚時の対応義務」は、SBOM の受入プロセスと直結する条項なので、単体で書くのではなく、SBOM 条項と対応関係を明確にしておくのが望ましいでしょう。契約全体のセキュリティ条項をどう設計すべきかについてはシステム開発委託契約のセキュリティ条項で詳しく整理していますので、あわせてご覧ください。
発注者向け情報セキュリティガバナンスの位置づけ
SBOM 対応は、発注者側の情報セキュリティガバナンス体系の中に位置づけて運用することが望まれます。具体的には、情報セキュリティ委員会などの経営レベルの意思決定機関で、次のような論点を扱う流れを整えます。
- SBOM 要求方針（どの案件区分でどの水準を求めるか）の年次見直し
- 重大脆弱性発覚時のエスカレーションフロー
- ベンダー評価基準への SBOM 対応状況の反映
- 監査法人・親会社への説明責任の担保
このように「単体のセキュリティ施策」ではなく「継続的なガバナンス活動」として位置づけることで、SBOM 対応が形骸化することを防げます。ガバナンス体系全体の作り方については発注者のためのITガバナンスと情報セキュリティの基本で基礎から解説していますので、社内で議論する際の参考にしてください。
関連情報
外部委託先のセキュリティ確認や、発注要件の整理を進める際の実務ガイドとして活用できるお役立ち資料をご用意しています。SBOM 対応を含めた発注時のチェックポイントを社内で議論する際の土台としてご利用ください。
お役立ち資料一覧から、貴社の状況に合わせた資料をご覧いただけます。
発注要件の整理段階からご相談いただけます。SBOM 対応を含めた委託先セキュリティ要件の設計や、既存契約への織り込み方について検討中の方は、お問い合わせフォームよりお気軽にご連絡ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- SBOMを発注要件に組み込むべきか判断に迷う場合、まず何から始めればよいですか？
全案件に一律導入するのではなく、影響度が中程度の新規案件を1件選んでパイロット導入するのが現実的です。フォーマットはベンダーが対応しやすい方に合わせ、更新頻度は納品時のみから始めることで、自社プロセスへの組み込みで発生する手間を無理なく体感できます。
- 既存の保守契約にSBOM提出を追加すると、追加費用は発生しますか？
初回作成費用が発生するのが一般的です。既存契約の変更としてベンダーと協議し、初回作成費用と以降の差分更新費用を切り分けて交渉すると、双方が納得しやすい落とし所を見つけやすくなります。見積に含めるか別項目として明示するかも契約書上で事前に取り決めておくと、後のトラブルを防げます。
- SBOMのフォーマットはSPDXとCycloneDXのどちらを選べばよいですか？
発注者側に強い指定理由がなければ、ベンダーがCI/CDに組み込みやすい方に合わせるのが現実的です。ライセンス管理を重視するならSPDX、脆弱性照合を重視するならCycloneDXが向いており、必要に応じて相互変換する運用も選べます。
- ベンダーからSBOM提出に対応できないと言われた場合、どう交渉すればよいですか？
契約打ち切りの材料ではなく共同で運用する意図であることを先に伝えた上で、主要OSS一覧とライセンス情報のみの簡易版から始める提案や、脆弱性対応SLAの強化といった代替案での補完を検討してください。あわせてSBOM作成にかかる初回費用と継続更新の費用を切り分けて協議する姿勢を示すと、ベンダー側の心理的ハードルも下がります。
- 自社にセキュリティ専門知識がなくても、受け取ったSBOMを運用に活かせますか？
可能です。月次でCVSSスコア7.0以上を目安に重大脆弱性のみをNVD・JVNと突合する軽量運用から始め、情シス担当者1〜2名を窓口にすれば、専門知識がなくても継続監視の体制を構築できます。対応可否の判断は発注者が業務影響を、ベンダーが技術的難易度を持ち寄って合議で決める形にすると、専門知識不足を補えます。
