SBOM提出業務はどこまで外に出せるか｜内製すべき判断と委託できる判断

まず結論：外に出せるのは「処理」、残すべきなのは「責任」

実務的に言い切ると、SBOM提出業務のうち、以下の作業は外に出しやすい領域です。

生成ジョブの運用
フォーマット変換、形式検証
提出用ファイルの整形
ポータル登録、版管理
一次問い合わせの受付

逆に、以下の内容は社内に残すべきです。

何をSBOMの対象に含めるか
どこまでマスキングするか
いつ改訂版を出すか
顧客からの差異指摘にどう答えるか
どの内容を正式回答として承認するか

これは、NTIAが minimum elements の中に distribution、delivery、access control、mistake handling まで含めていること、また supplier/consumer 向け文書で generation・update は契約化できても、機密性や正確性・完全性は別論点として扱っていることから導ける実務上の結論です。

1. SBOM生成そのものは委託しやすい

SBOM生成は、外に出しやすい業務です。
NTIAの Supplier Playbook は、SBOM生成を「含まれるソフトウェア部品の特定」「部品データの取得」「構造化フォーマットへの取り込み」「形式検証」という4段階で整理しています。また、現在のベストプラクティスとして、git や CI/CD パイプライン、ビルドシステム、パッケージマネージャと連携した build-time SBOM の自動生成を挙げており、こうした自動生成は手入力ミスが少なく、より authoritative な識別情報を持ちやすいと説明しています。つまり、ツール実装や生成運用は委託しやすいのです。

【内製すべき判断】どのデータを「正」とみなすか

同じ NTIA 文書は、レガシー環境や post-build SBOM では、情報源を engineering process にできるだけ近づけるべきで、パッケージマネージャやリポジトリ由来の情報は、手作業のスプレッドシートより望ましいとしています。スプレッドシートは出発点にはなっても、ハッシュがなければ「その名前の部品が本当にその製品に入っている」ことを検証しにくいからです。
したがって、外部にSBOM生成を任せても、何を根拠データに採用するかの判断は内製で持つべきです。

2. 更新運用は委託できるが、「いつ更新版を出すか」は内製判断

更新も委託しやすい業務です。
Consumer Playbook では、SBOMの生成と更新は、ソフトウェア開発の MSA やその配下の SOW で要求でき、下請けへのフローダウンも契約の範囲に入ると説明しています。つまり、改訂版SBOMの再生成や再提出を、サービスとして委託すること自体は可能です。

【内製すべき判断】いつ新しいSBOMを出すべきか

Minimum Elements は、新しい build や release があれば新しい SBOM を作るべきだとし、さらにコードが変わっていなくても、新たな情報が分かったり誤り訂正が必要なら revised SBOM を出すべきだとしています。Formats and Standards の調査でも、ソフトや部品の更新だけでなく、宣言情報の修正でも SBOM は更新されうると整理されています。
だから、再出力の実行は外注できても、改訂トリガーと対顧客の更新ポリシーは内製で持つべきです。

3. マスキングや提出用整形は委託できるが、開示方針は委託できない

SBOM提出で迷いやすいのが、どこまで見せるかです。
NTIAの Supplier Playbook は、SBOMが競争情報とみなされる場合があり、公開したくないと考える供給者がいること、そしてその場合は著作権で流通を止めるのではなく、契約で取り決めた機密情報として扱うのが適切だと説明しています。Minimum Elements も、access control を practices and processes の一部として挙げ、アクセス条件は何らかの arrangement で指定されるべきだとしています。

このため、提出前のマスキングや整形の実行は外に出せます。たとえば、承認済みルールに従って特定列を非表示にする、顧客別テンプレートに整える、NDA前提の配布チャネルへ載せる、といった処理です。

【内製すべき判断】開示対象とアクセス権の設計

どの部品情報を秘匿対象にするか、どの顧客まで開示するか、アクセス権をどう設計するかは、製品責任と契約責任に直結するため、社内で決めるべきです。ここを外部委託先の裁量にすると、営業・法務・品質保証の説明がぶれやすくなります。

4. 提出の物流は外に出せる

提出作業そのものも、かなり外部化しやすい領域です。
NTIAの Formats and Standards 調査では、SBOMの下流への伝え方に単一の正解はなく、ソフトウェア本体に同梱する方法、supplier portal で提供する方法、事前に合意した場所に置く方法、第三者保管を使う方法などがありうるとしています。さらに、過去時点の構成確認のために older SBOMs へアクセスしたいという要望も想定されています。つまり、アップロード、保管、履歴管理、配布実行は運用作業として外注しやすいのです。

【内製すべき判断】提出のポリシー

どれを公式提出版とみなすか、どの取引先にどの深さのSBOMを出すか、改訂履歴をどの期間残すか、といった点です。NTIAは distribution and delivery を minimum elements の一部に入れており、これは「出す場所の問題」ではなく、「どういう条件で運用するか」の問題です。したがって、配送の実行は外注、提出ポリシーは内製が基本です。

5. 問い合わせの一次受けは外に出せるが、最終説明は内製すべき

問い合わせ対応も、全部を社内で抱える必要はありません。
一次受付、受付番号の払い出し、必要資料の回収、定型回答の返送、期限管理は外に出しやすい仕事です。

【内製すべき判断】製品範囲と完全性の最終説明

Consumer Playbook は、完全な SBOM であるためには、製品に取り込まれた third-party dependencies だけでなく、runtime dependencies や container contents も含めるべきだとしています。漏らすと consumer 側の situational awareness に危険な gap が生じるとも述べています。つまり、「この依存関係はなぜ載っていないのか」「この installer や updater は対象外なのか」という問い合わせは、単なる事務処理ではなく、製品範囲の説明です。

さらに、同文書は請負・受託開発において、consumerがsupplier提供SBOMを比較（cross-compare）したりリバースエンジニアリングして差異を確認したりしうるとしています。不整合が出たときに、外部委託先だけで完結するのは危険です。差分の説明、完全性の説明、是正方針の回答は、最終的に供給者側の責任として内製で握っておくべきです。

6. 外部サービスやSaaSが絡むなら、なおさら最後は社内判断

もう一つ、外注境界で見落としやすいのが外部サービスです。
Consumer Playbook は、SaaS や MSP からの SBOM 取得をその文書の scope 外としています。一方、Supplier Playbook は、外部サービスへの call-out や automated update services のような trust boundary をまたぐ要素は security-relevant でありつつ、現時点では SBOM baseline の外にある evolving requirement だと説明しています。

つまり、コネクテッド機能や外部更新サービスが絡む製品では、提出ファイルだけ整えれば終わりではないということです。ここは OEM への説明の仕方自体が設計判断なので、外部化しても最後の説明責任は社内に残ります。

中小サプライヤーにとって現実的な切り分け

中小サプライヤーで失敗しにくいのは、次のような切り分けの形です。

外部委託できる「処理」

SBOM生成の仕組み運用
再生成の実行
フォーマット検証
提出用ファイルの整形・マスキング
ポータル登録、履歴保管
一次受付・期限管理

社内に残すべき「責任・判断」

対象範囲（正のデータ）の定義
runtime dependency等の包含判断
機密区分・開示方針の決定
改訂版発行（トリガー）の承認
差異・不整合への理由説明
最終的な対顧客回答の承認

この切り分けなら、SBOMのBPO（アウトソーシング）の効果が出やすく、それでいて製品責任と契約責任を失いません。
NTIA文書に照らしても、委託しやすいのは format・workflow・distribution の実行部分 で、内製すべきなのは completeness、access、update trigger、discrepancy resolution の判断部分 です。

まとめ

SBOM提出業務は、かなりの部分を外に出せます。ですが、外に出せるのは「業務」であって、「説明責任」ではありません。

生成、更新、整形、検証、登録、履歴管理は委託しやすい。
一方で、何を含めるか、どこまで開示するか、いつ改訂するか、差異や不足にどう答えるかは、供給者側に残るべき判断です。

※これはNTIAの minimum elements と supplier/consumer playbooks を読むと、かなり一貫しています。

自社のSBOM運用で、どこまで外に出せて、どこを社内で持つべきかを整理したい場合は、SBOM業務の切り分けを相談するところから始めるのが最短です。
生成ツールの話から入るより、まず対象範囲、開示方針、提出フロー、問い合わせ責任を分けて考えた方が、後でやり直しが起きにくくなります。

SBOM提出業務はどこまで外に出せるか
内製すべき判断と委託できる判断