SBOM提出時の機密対策
（秘匿/マスキング/範囲定義）
出しすぎず、足りなさすぎない作り方
SBOMをOEMや顧客へ提出しようとすると、実務現場ではほぼ必ずこの悩みにぶつかります。
- 「どこまで出せば相手が納得するのか」
- 「どこから先は設計情報に近く、出しすぎになるのか」
- 「伏せすぎると『それでは判断できない』と差し戻されないか」
結論から言うと、SBOM提出で大事なのは “全部出すか、全部隠すか” というゼロイチの議論ではありません。
重要なのは、提出の目的に合わせて範囲を定義し、機密区分に応じてマスキングし、それを再現できる形（証跡）として残すことです。
SBOMは、そのまま出すと設計や取引先情報に近い要素を含むことがあります。一方で、出す情報が少なすぎると、OEMや顧客側で脆弱性の影響判定ができません。
だからこそ必要なのは、「社内正本」 と 「提出版」 を明確に分けて考えることです。
まず押さえる：SBOM提出で守るべき3原則
1. 正本は1つ、提出版は複数
まず大前提として、社内で管理する「正本SBOM」 と、相手に出す 「提出版SBOM」 は分けて管理してください。
正本にはビルド環境や詳細なパスなどあらゆる情報を持ちますが、提出版は提出先や目的に合わせて抜粋・加工したスナップショットになります。
2. 出す/伏せるの基準を先に決める
案件ごとに「ここは出すべきか？」と毎回判断していると、担当者ごとにブレが生じ、説明責任が果たせなくなります。
製品名、版数、搭載箇所、供給元、社内モジュール名などを、あらかじめ「出す / 条件付き / 伏せる」に分類しておくのが最も安全なアプローチです。
3. マスキングした理由を残す
OEMからの監査や追加質問で効力を発揮するのは、「なぜそこを伏せたか」を論理的に説明できることです。
単に消すだけでなく、「削除・置換・粒度調整」のどれで対応したかをルールとして残しておくと、将来の再提出時や担当者引き継ぎ時に迷いません。
何が機密になりやすいのか？
機密になりやすい項目
そのまま出すとIP（知的財産）や契約上のリスクになる要素です。
- 社内モジュール名や内部命名規則
- 詳細すぎる搭載箇所（細かい機能分解）
- 顧客名や他案件の名称
- 供給元や取引先名
- リポジトリURL、ファイルパス、内部チケット番号
- ハッシュやビルド環境の詳細
- 備考欄の設計メモ
相手が最低限必要な項目
これがないと、OEM側で脆弱性管理（影響判定）が回りません。
- 製品名
- 製品版数
- コンポーネント名（OSS等）
- コンポーネント版数
- 影響判定に必要な範囲の説明
- 必要に応じた搭載箇所（大分類レベル）
つまり、「判断に必要な粒度は残し、設計の深部に入る粒度は落とす」 という考え方が基本になります。
手順：兼務でも破綻しないSBOM提出時の機密対策
専任者がいない組織でも安定して回せる、実践的な6ステップを解説します。
1提出の目的を1行で定義する
最初に、「何のために出すか」を書きます。これが曖昧だと、出す範囲もマスキング基準も決まりません。
例：「OEM照会に対する影響有無の説明」「契約上の提出物」「監査用の確認資料」など。目的によって相手が求める解像度は変わります。
2提出対象の範囲を切る
次に、どの製品・どの版数・どのモジュール範囲か を固定します。ここが曖昧なままでは、提出版をどう加工しても差し戻されやすくなります。
最低限、「製品名」「対象版数」「提出先」「対象となるコンポーネント範囲」は確定させます。
3項目を3区分に分ける
各データ項目を次の3区分に分けると実務で使いやすいです。このルールを事前に決めるだけで、毎回の迷いが劇的に減ります。
- 提出可 : そのまま出してよい
- 条件付き提出 : 粒度を落とす、置換する
- 非提出 : 原則出さない。必要時は別協議
4マスキング方法を決める
マスキングは、単に黒塗りするだけではありません。実務では次の3種類を使い分けます。
- 削除 : 完全に出さない。
- 置換 : 例：内部モジュール名を
MODULE-Aのように抽象化して置き換える。 - 粒度調整 : 例：詳細な機能名ではなく「通信モジュール」「更新モジュール」といった大分類にする。
おすすめは可能な限り「置換」か「粒度調整」です。全部削除してしまうと、相手が影響箇所を判断できなくなり、結果的に問い合わせが増えます。
5提出版を作り、正本との紐付けを残す
提出版を作成したら、必ず以下の情報を記録してください。これが無いと、後から「何を元にこの提出版を作ったのか」が追えなくなります。
6承認してから提出する
SBOM提出は、単なる技術データの連携ではなく、機密と取引の判断を含む重要な行為です。
最低限、「提出前の承認者」を1人決めてください。兼務でリソースが厳しい体制でも、ここのプロセスだけは省略しない方が安全です。
そのまま使える：機密区分・マスキング判断テンプレ
以下のテキストはタブ区切りになっています。コピーして、そのままExcelやGoogleスプレッドシートのA1セルに貼り付けて、自社の基準作成にご活用ください。
自社製品のSBOM整備や、OEMへの提出運用・マスキング基準をどこから始めるべきか整理したい方はご相談ください。
【無料】オンライン相談を予約するよくあるNG例（監査で詰まるパターン）
-
NG1：提出版を「正本」として上書き更新してしまう
後から詳細な情報を元に戻せなくなり、社内の開発用SBOMと外部提出版が混ざって管理不能になります。 -
NG2：担当者の感覚で毎回伏せ方が違う
相手先や提出時期によって文書の粒度がズレてしまい、後から「なぜ今回はこれがないのか？」と突っ込まれ説明が破綻します。 -
NG3：ひたすら「黒塗り（削除）」だけで提出する
情報が読めず、OEM側の影響判定プロセスが止まります。実務では「置換」や「粒度調整」で構造を残す方が親切であり、差し戻しを防げます。 -
NG4：なぜ伏せたかの記録がない
数ヶ月後の監査や再提出の際に「これって何で消したんだっけ？」と同じ議論を社内で繰り返すことになります。
FAQ：マスキングの実務
A. 基本的には、そのまま出さず「社内正本」と「提出版」を分けた方が安全です。特に内部モジュール名、詳細なファイルパス、取引先情報などは、そのまま出さない方が良いケースが大半です。
A. 「提出版のID」「元にした正本SBOMのID」「適用したマスキングルール」の3点です。この3つがセットになっていると、後からでも提出状態の完全な再現が可能になります。
A. 可能なら「置換」や「粒度調整」の方が推奨されます。完全に削除してしまうとツリー構造が崩れますが、置換であれば相手が「ここに何かコンポーネントがある」という構造を理解でき、判断材料を残しやすいからです。
マスキングしたSBOMでも、脆弱性の影響判定を自動化できます。
Auto PSIRT Cloudなら、社内正本のSBOMを登録しておくだけで、日々公開される脆弱性情報（CVE等）と自動で突合。マスキングして提出した範囲についても、「自社のどの製品の、どのモジュールに影響があるか」を即座に特定し、OEMへの回答期限（SLA）を守る運用を強力に支援します。