IT企業 M&A SBOM｜OSSライセンス・脆弱性・ソース来歴を整えるデューデリジェンス

2026年8月22日2026年10月23日

IT企業 M&A SBOMで最初に押さえる結論は、SBOMファイルを一度出力しただけではOSSデューデリジェンスは完了しない、という点です。買い手が知りたいのは、どの顧客へ提供されたどのリリースに、どの版の部品が、どの経路で入り、どのライセンス義務と脆弱性判断が残り、誰がいつ是正するかです。生成時刻も対象範囲もない一覧は、現在の本番成果物を説明できません。

売り手は「スキャンで重大項目ゼロ」と断言する前に、製品、リポジトリ、ビルド成果物、配布形態、契約、脆弱性台帳の母集団を合わせます。直接依存だけでなく推移的依存、コンテナのOSパッケージ、コピーされた断片、社内フォーク、外注納品、商用SDK、サービスとして呼び出す部品も入口を分けます。分からない項目はUNKNOWNまたは未評価として残し、無理に安全へ変換しません。

本稿は特定ライセンスの法的結論や個別脆弱性の安全保証を行うものではありません。CTO、CISO、法務、開発責任者が弁護士・技術専門家・買い手へ同じ事実を渡すために、5台帳連携、SBOM完全性テスト、ソース来歴チェーン、是正優先度、段階開示、Day 1引継ぎを実務手順として示します。

SBOMが必要でも一覧だけではデューデリジェンスを終えられない理由

SBOMはソフトウェアを構成する部品情報を交換するための重要な記録ですが、ライセンス適合や脆弱性不存在を自動的に証明する証明書ではありません。生成対象がソースだけなのか、配布バイナリや稼働コンテナまで含むのか、依存の深さ、除外、未知項目、版が明記されて初めて評価の入口になります。

最大売上顧客が利用する実物から、SBOM、義務、脆弱性、担当者まで同じIDで追跡できますか。

製品・リリース台帳とSBOM生成記録を突き合わせる

証拠・フィールド	確認できること	注意信号
製品・リリース台帳	契約顧客が使う版とサポート終了日を確認する。	最新版しか載らず旧版の売上が残る。
SBOM生成記録	入力、ツール、設定、時刻、形式を再現する。	ファイルだけがあり生成方法を誰も説明できない。
成果物ハッシュ	SBOMと配布バイナリ・イメージの同一性を確認する。	ハッシュがリリース後に上書きされる。
未知項目ログ	未識別・未走査・例外承認を追跡する。	空欄と該当なしが同じ表記になっている。

経営者は「SBOMあり・なし」ではなく、対象リリースごとのカバレッジ、検証結果、未評価、対応責任を答えます。買い手が任意の顧客版を選び、成果物から構成、義務、是正までたどれる状態を完了条件にします。

取引対象製品を列挙する

取引対象製品を列挙する：販売中、保守中、無償版、OEM、社内基盤を含む製品母集団を作り、廃止予定も残します。対象外と決めた古い版が顧客環境で稼働していることがあるためです。
顧客利用版へ固定する：最新版だけでなく売上・契約・サポート台帳から実際の配布版と稼働版を特定します。開発ブランチのスキャン結果では顧客へ渡った成果物を説明できません。
生成条件を記録する：ツール名・版、入力、除外、依存深度、形式、生成時刻、成果物ハッシュを保存します。同じ製品名でも設定差により部品一覧が変わるためです。
未評価を管理対象にする：識別不能部品や走査不能領域をゼロ扱いせず、件数、影響、調査期限、暫定措置へ変換します。未知を消すと買い手がリスクを再評価できなくなります。

誤認・失敗	実務上の修正
部品数だけを品質指標にする	数の多寡は構成や義務の良否を示しません。対象範囲と変化を併記します。
スキャン成功を完全性と呼ぶ	ツールが終了コード0でも、除外ディレクトリや取得不能レジストリが残る場合があります。
最新リリースだけを提出する	旧版顧客、LTS、OEM、オンプレミス提供版を販売・保守台帳から追加します。

OSS・商用SDK・内製コード・外注成果物の母集団を切り分ける

一つの実行ファイルには、公開OSS、商用ライブラリ、クラウドAPI、内製コード、顧客提供コード、外注成果物、生成コードが混在します。全てをOSSとして扱うと契約条件を見落とし、OSSだけをスキャンするとコピー済み断片や外注由来の権利確認が抜けます。

判断を急がない：ファイル名からOSSと推定する

ファイル名からOSSと推定する：同名の商用品や社内フォークがあるため、ハッシュ、由来、契約を照合します。
外注成果物を内製扱いする：検収済みでも権利帰属や第三者部品の保証範囲を契約・納品記録から確認します。
クラウドAPIを無関係とする：SDK、利用規約、終了時の移行、データ処理、料金条件を別台帳で扱います。

構成物を技術分類と権利根拠の二軸で分けます。名称が分からない部品も除外せず、検出経路、所在、使用先、調査担当を持つ仮IDへ置き、判明時に履歴を保って統合します。

判断・作業	進め方	根拠資料	読み方
構成物の入口を七つに分ける	パッケージ管理、コピー、サブモジュール、コンテナ、ビルドツール、外部サービス、外注納品を別々に探索します。一種類のスキャナでは全経路を捉えられないためです。	構成物マスター	部品種別、出所、権利根拠、利用製品を管理する。注意信号は商用SDKをOSS欄へ入れ契約更新を見落とす。
権利根拠を付ける	OSSライセンス、購入契約、雇用契約、委託契約、顧客許諾、社内制作のどれかを部品へ結びます。コードの所在だけでは利用権限を説明できません。	調達・委託契約	取得権限、再配布、譲渡、監査、終了条件を読む。注意信号は発注書だけで知財条項が見つからない。
提供形態を記録する	SaaS、バイナリ配布、ソース提供、端末組込み、API利用、社内限定を製品版ごとに持ちます。同じ部品でも利用・配布の事実が異なるからです。	コード所有者一覧	社員、退職者、委託先、買収前会社の関与を示す。注意信号は個人アカウントにしか履歴がない。
識別不能を隔離する	出所不明ファイルは削除せず隔離ブランチで影響テストし、所有者と期限を決めます。稼働中コードを性急に消す停止事故を避けます。	利用形態マップ	各部品が顧客へどう届くかを確認する。注意信号はSaaSとオンプレ版を同じ扱いにする。

配布成果物を構成する全ての部品について、技術上の出所と利用権限の根拠を分けて答えられますか。

製品・リポジトリ・ビルド・SBOM・是正の5台帳を共通IDで結ぶ

製品一覧、Git、CI/CD、SBOM、脆弱性管理が別々の命名規則で運用されると、買い手の質問ごとに手作業の照合が発生します。ファイルを一つへ統合する必要はありませんが、製品ID、リリースID、成果物ID、部品ID、課題IDの関係は機械的に結べる必要があります。

製品IDの正本を選ぶ

作業	実施内容	判断理由
製品IDの正本を選ぶ	販売管理または製品管理の恒久IDを親キーとし、ブランド名変更を別履歴にします。	マーケティング名は頻繁に変わり過去契約と結べないためです。
リリースと成果物を一対多で結ぶ	一つの版にOS別バイナリ、コンテナ、モバイル、オンプレ構成があることを表現します。	代表一ファイルだけのSBOM提出を防ぎます。
部品座標を正規化する	package URL、名称、版、供給者、ハッシュ、エコシステムを併記し、同名異物を分けます。	文字列だけの一致では誤結合が起きるためです。
是正課題へ影響範囲を渡す	脆弱性・ライセンス課題から製品、顧客、契約、担当、修正版へ逆引きできるようにします。	修正完了後も対象顧客への展開漏れが起こり得ます。

正本を一つに決め、他台帳は参照キーと有効期間を持たせます。名称変更やリポジトリ分割があっても旧IDを消さず、どの期間・顧客・成果物へ適用されたかを再現します。

ID対応表でリリースマニフェストの前提を検証する

ID対応表: 全台帳の主キー・外部キー・有効期間を示す。注意信号は名称の部分一致で毎回手結合している。
リリースマニフェスト: 成果物、ビルド、SBOM、署名、配布先を固定する。注意信号は再ビルドで同じ版番号の中身が変わる。
部品識別子: 版と供給者を含む一意性を確認する。注意信号はlatestやmasterのような可変値が残る。
是正チケット: 発見から修正版配布・受入まで追跡する。注意信号は開発完了だけで顧客適用を確認しない。

「全台帳を一枚へコピーする」という進め方は採りません。更新責任が曖昧になるため、正本と参照関係を定義します。「IDを再利用する」と判断する前に、廃止製品のIDを新製品へ使わず、恒久的な履歴を保ちます。「版番号だけで同一性を判断する」だけでは説明が足りません。成果物ハッシュ、ビルド番号、署名、生成時刻を併用します。

任意の是正チケットから、影響部品、成果物、顧客、契約、修正版まで双方向にたどれますか。

ソース・ロックファイル・コンテナ・バイナリからSBOMを生成して照合する

ソース解析は宣言された依存を見つけやすい一方、ビルド時に取り込まれる部品や配布物へコピーされたファイルを落とすことがあります。バイナリ解析は実物へ近い一方、名称・版・ライセンスを確定できない場合があります。単一の走査面を正解とせず、差分を説明する設計が必要です。

境界を誤る場面：開発ブランチを走査する

誤認・失敗	実務上の修正
開発ブランチを走査する	取引基準日時点のリリースタグと実配布物へ固定します。
コンテナのアプリ層だけを見る	OSパッケージ、サイドカー、起動時取得、ベースイメージも別面で確認します。
差分を手修正して保存する	元出力、補正理由、承認者、再生成手順を残し、監査不能な完成版を作りません。

宣言された依存と顧客へ渡った実物の差を、部品ごとに理由コードで説明できますか。

重要製品は少なくとも宣言、解決、ビルド、配布の各面を照合します。差分は誤検知として一括削除せず、なぜ片方だけに存在するか、顧客影響があるか、次回生成で再現するかを判定します。

宣言依存を採取する

1. 宣言依存を採取する：manifest、ロックファイル、サブモジュール、vendoredディレクトリを版管理された時点で保存します。開発者端末の現在値では過去リリースを復元できないためです。
2. ビルド環境を固定する：ベースイメージ、コンパイラ、プラグイン、パッケージレジストリ、環境変数の版を記録します。同じソースでも生成物の依存が変わり得ます。
3. 配布実物を走査する：コンテナレイヤー、バイナリ、モバイルパッケージ、インストーラを顧客提供物と同じハッシュで調べます。テスト成果物の分析を本番へ流用しないためです。
4. 差分理由を分類する：未使用、静的リンク、動的取得、重複、検出不能、生成物、誤認の理由コードを付けます。例外が次回走査で再発したとき比較できます。

ロックファイルスナップショット・ビルド来歴に残す再計算根拠

証拠・フィールド	確認できること	注意信号
ロックファイルスナップショット	解決された直接・推移依存を固定する。	リリースタグ後に更新されている。
ビルド来歴	使用した環境、ツール、入力、出力を確認する。	CIログの保存期間がDD対象期間より短い。
配布物保管庫	顧客に渡した実物とハッシュを保持する。	同じファイル名で上書きされる。
差分判定票	各走査面の不一致と採否を説明する。	ツールの除外ボタンだけで理由が残らない。

SPDXとCycloneDXは目的・受渡先・対応ツールから版を固定する

SPDXとCycloneDXは広く使われるSBOM形式ですが、名称だけを書けば相互運用できるわけではありません。仕様版、プロファイル、必須・任意フィールド、識別子、拡張、シリアライズ形式、利用ツールの対応状況が異なります。M&A用に唯一の形式を断定するより、誰が何を検証するかから選びます。

形式選定メモとスキーマ検証結果が示す反証

形式選定メモ: 目的、受渡先、仕様版、採否理由を残す。注意信号はSPDXまたはCycloneDXという名称しかない。
スキーマ検証結果: 機械可読性と参照整合を確認する。注意信号は警告を削除し結果ファイルを残さない。
変換差分: 原本から失われたフィールドと補完方法を示す。注意信号は空欄が自動的にNOASSERTIONへ置換される。
ツール対応表: 生成・読込・検証できる版を確認する。注意信号は仕様の現行版とツール実装版を混同する。

売り手は原本となる内部情報モデルを保ち、受渡先の要件に応じて公式仕様の対応版へ出力します。変換前後の欠落、未知値、拡張項目、検証器の結果を保存し、最新版という言葉だけで版を変更しません。

利用目的を定義する：ライセンス照合、脆弱性、調達回答、規制対応、買い手取込のどれを優先するか明記します。目的が違えば必要フィールドと更新頻度が変わるためです。
相手の受入仕様を確認する：形式、仕様版、プロファイル、文字コード、ファイル上限、署名、転送方法を質問します。ファイル提出後の変換失敗を避けます。
変換テストを行う：内部台帳から出力し、公式・対応検証器で構文、参照、必須要素、識別子を確認します。見た目が読めても機械処理で関係が切れる場合があります。
版変更を承認する：ツール更新、仕様改定、買い手要請時に差分、互換性、再生成範囲を記録します。取引途中の無断更新で比較不能になることを防ぎます。

仕様名、版、プロファイル、生成ツール、受入検証、変換損失を一つの受渡票で説明できますか。

SBOMの完全性を母集団・深さ・未知・時刻・ハッシュで検査する

完全性は「全て入っています」という自己申告では測れません。対象となる成果物の母集団、直接・推移依存の深さ、静的・動的リンク、コピー断片、除外、未知値、生成時刻、ハッシュを検査し、分母と欠落を示す必要があります。完全性の基準は製品リスクと買い手要件で変わります。

Yes/NoだけでなくUnknownとNot Applicableを分けます。重要リリースは独立した逆方向テストを行い、SBOMの部品が成果物に存在するか、成果物から抽出した部品がSBOMに存在するかの双方を確認します。

分母を確定する

1. 分母を確定する：対象製品、版、成果物、プラットフォーム、顧客区分を販売・配布台帳から数えます。生成済みファイル数だけでは未生成分が見えないためです。
2. 深さを検査する：直接依存、推移依存、ベースイメージ、ビルド時取得、実行時取得の捕捉状況を区分します。ツールにより追跡できる範囲が異なります。
3. 未知値を数える：供給者、版、ライセンス、ハッシュ、関係が不明な要素をフィールド別に集計します。空欄を除外すると確度を過大表示します。
4. 双方向サンプルを行う：SBOM起点と成果物起点で無作為・高リスクサンプルを選び、差分率と原因を記録します。一方向だけでは幽霊部品か検出漏れか判断できません。

証拠・フィールド	確認できること	注意信号
カバレッジ表	全成果物に対する生成・検証・未生成を数える。	最新版100％だけを全製品100％と表示する。
未知値集計	項目別の未確定件数と影響を確認する。	空文字、null、NOASSERTIONの意味が混在する。
双方向検査記録	SBOMと実物の一致率・差分理由を示す。	意図的除外と検出不能を同じコードにする。
鮮度指標	リリース時刻とSBOM生成時刻のずれを測る。	過去SBOMを新リリースへコピーする。

完全という表現を使わずに、分母、範囲、未知、検査方法、誤差を数値と文章で説明できますか。

ライセンス義務を部品名ではなく利用・改変・配布の事実へ結び付ける

ライセンス名だけをリスク色へ変換しても、個別製品の義務は確定しません。対象版、ライセンス本文、改変、結合方法、配布物、提供先、ソース提供の有無、表示、契約上の追加制限などの事実をそろえ、法律専門家が判断できる状態を作る必要があります。

重要部品について、ライセンス名ではなく、どの版をどう利用し誰へ何を渡したかを証拠で説明できますか。

ライセンス証拠パックと利用形態質問票を突き合わせる

証拠・フィールド	確認できること	注意信号
ライセンス証拠パック	本文、部品版、出所、ハッシュを固定する。	Webページの現在版しか保存していない。
利用形態質問票	結合・改変・配布・提供の事実を確認する。	SaaSだから無関係という回答だけが残る。
履行物サンプル	顧客が受け取った表示・同梱物を示す。	社内テンプレートと配布実物が違う。
法務判断ログ	前提、結論、担当、確認日、再検討条件を記録する。	許可という結論だけで前提が消える。

技術チームは事実と証拠を整え、法務は解釈と対応を記録します。社内の「許可・禁止リスト」は一次選別に使えても、個別ライセンス本文と利用形態の確認を置き換えません。

ライセンス本文を固定する

ライセンス本文を固定する：部品版に同梱されたLICENSE、NOTICE、ヘッダー、レジストリ情報を保存し出所URLとハッシュを持ちます。名称だけでは例外条項やデュアルライセンスを識別できません。
利用事実を採取する：改変、静的・動的結合、プロセス分離、ネットワーク利用、配布、ソース提供を開発者へ確認します。抽象的な製品説明では義務の前提を判断できません。
履行証拠を探す：著作権表示、NOTICE、ライセンス同梱、ソース提供案内、申出、顧客通知の実物を版ごとに保存します。方針書だけでは実際の配布へ反映されたか分かりません。
例外を法務へ上げる：不明、独自条項、複数ライセンス、特許条項、商用例外を期限付きの照会票にします。開発者が法的結論を一人で確定することを避けます。

誤認・失敗	実務上の修正
強弱コピーレフトだけで色分けする	実際の利用・配布事実と個別本文を先に確定します。
ライセンス表示を後から一括追加する	対象版と顧客配布の実態を確認し、必要な対応を法務と決めます。
独自フォークの元版を失う	上流コミット、差分、社内変更、適用ライセンスを来歴台帳へ残します。

社員・退職者・委託先・買収前組織のソース来歴をコミットへ結ぶ

SBOMが第三者部品を示しても、内製と呼ぶコードの著作・利用権限までは説明しません。創業者個人の過去コード、退職者の持込み、外注成果物、顧客提供素材、買収した事業のリポジトリが混ざると、会社がどの根拠で利用・譲渡できるかが不明になります。

判断を急がない：全社員へ一律の誓約書を求めて終える

全社員へ一律の誓約書を求めて終える：重要リポジトリと作成時点へ具体的に対応させます。
履歴を消してきれいにする：原本を保全し、是正ブランチと法務判断を別に管理します。
外注検収を権利移転と同一視する：基本契約、個別発注、再委託、第三者部品、人格権等の条項を専門家が確認します。

全行の法的鑑定を目指すのではなく、重要リポジトリの作成者母集団と契約根拠を対応させ、異常な大量追加、外部メール、履歴欠落、持込み申告をリスクベースで深掘りします。

判断・作業	進め方	根拠資料	読み方
作成者を正規化する	Git名・メールを社員ID、委託先ID、bot、外部者へ対応させ、別名を統合します。個人メールや退職者の別アカウントを見落とさないためです。	作者対応表	Git作者と契約当事者を対応させる。注意信号はunknown作者をbotと決めつける。
契約期間へ照合する	コミット日が雇用・委託期間内か、職務範囲や成果物条項と整合するか確認します。在籍した事実だけで全コードの権利根拠は確定しません。	契約期間一覧	作成時点と業務範囲の整合を確認する。注意信号は契約更新の空白期間がある。
持込みイベントを抽出する	初回大量コミット、履歴のsquash、他社ヘッダー、外部URL、アーカイブ投入を検出します。元の出所を後から追えなくなる箇所を優先できます。	持込み検知レポート	履歴異常・外部由来候補を抽出する。注意信号は現在のファイルだけで削除済み履歴を見ない。
確認と是正を証拠化する	追加契約、確認書、置換、隔離、法務見解をコミット・ファイル範囲へ結びます。会社全体の一般確認だけで具体的な問題を覆わないためです。	是正証跡	対象コード、方法、承認、完了版を示す。注意信号は口頭の了承だけで原本がない。

売上上位製品の主要コードについて、作成者、作成時点、契約根拠、持込み、是正をコミット単位へ戻せますか。

CVE・JVN・到達可能性・悪用状況・EOLを分けて脆弱性を判断する

脆弱性スキャナの件数は出発点であり、事業影響の順位ではありません。部品版の同定、該当条件、実行経路、外部露出、権限、悪用情報、修正版、サポート期限、顧客契約を重ねて初めて、対応期限と暫定措置を決められます。情報は日々更新されるため、固定した「安全」表示は危険です。

識別精度を確認する

作業	実施内容	判断理由
識別精度を確認する	CPE、package URL、版範囲、ベンダー情報、ハッシュを照合し、候補と確定を分けます。	名称一致だけで別製品のCVEを割り当てる誤りを減らします。
実行可能性を調べる	該当関数、呼出経路、設定、入力経路、権限、ネットワーク露出を技術証拠で評価します。	CVSSだけでは自社製品の文脈を表せません。
外部情報を更新する	JVN、ベンダーアドバイザリ、CVE、悪用情報、サポート終了を確認日時付きで保存します。	発見後に評価が変わるためです。
展開完了まで追う	修正版作成、テスト、配布、顧客通知、適用確認、旧版停止を個別状態で管理します。	コード修正済みでも顧客リスクが残ることがあります。

検出結果、技術評価、受容判断、修正、配布、顧客受入を別イベントにします。誤検知や到達不能の判断にも根拠、承認者、再評価条件、有効期限を持たせます。

脆弱性観測票で到達可能性証拠の前提を検証する

脆弱性観測票: 情報源、取得時刻、版範囲、評価変化を残す。注意信号はスクリーンショットだけで更新履歴がない。
到達可能性証拠: 呼出、設定、露出、権限を確認する。注意信号は開発者の記憶だけでnot affectedとする。
EOL台帳: 部品・ランタイム・OSの支援期限を管理する。注意信号は脆弱性なしを保守可能と同一視する。
顧客展開台帳: 修正版がどこまで適用されたか示す。注意信号はリリースノート公開を完了扱いする。

「CVSS順だけで対応する」という進め方は採りません。露出、重要データ、悪用、代替、契約期限を追加して優先順位を決めます。「到達不能を永久例外にする」と判断する前に、コード・設定・製品版の変更時に再評価する期限付き判断にします。「未公表情報を通常VDRへ置く」だけでは説明が足りません。JPCERT/CC等の取扱指針と案件権限に従い、対象者・経路を制限します。

重大というラベルではなく、自社製品で悪用に至る経路、影響顧客、暫定措置、修正版展開を説明できますか。

顧客・調達契約のSBOM提供、通知、監査、支配変更を台帳へ接続する

技術的に是正できても、顧客契約上の通知期限、SBOM形式、脆弱性回答、監査、下請承認、支配変更、輸出・業界要件を満たさなければ取引リスクは残ります。反対に契約へ明文がなくても、提案書やセキュリティ質問票で約束した内容が運用義務になっている場合があります。

境界を誤る場面：契約にSBOMとないから対象外とする

誤認・失敗	実務上の修正
契約にSBOMとないから対象外とする	セキュリティ別紙、調達要件、提案回答、業界ルールを追加確認します。
全顧客へ同じ詳細を送る	契約と必要性に応じ、営業秘密・脆弱性情報を保護した開示範囲を決めます。
M&A通知と事故通知を同文にする	法的根拠、目的、期限、受領者が違うため別ワークフローにします。

顧客ごとに、何をいつどの形式で渡し、何を通知し、誰が受領を確認するかを製品運用へ結べますか。

法務台帳と製品台帳を顧客ID・製品IDで結び、契約原本、注文書、仕様書、質問票、例外合意を一つの義務セットとして読みます。技術チームが履行可否を回答し、法務が通知・同意・開示を管理します。

契約文書の全層を集める

1. 契約文書の全層を集める：基本契約、注文書、SLA、仕様、セキュリティ別紙、質問票、変更合意を顧客ごとに束ねます。基本契約だけでは個別の提供義務を落とすためです。
2. 義務を構造化する：SBOM形式・頻度、通知事由・期限、監査権、是正期間、費用、責任、終了を列にします。自由記述の要約では期限管理できません。
3. 技術実装へ結ぶ：義務ごとに対象製品、パイプライン、連絡先、承認者、証拠の保存場所を割り当てます。法務の一覧が開発運用へ反映されないことを防ぎます。
4. 取引時の通知を計画する：支配変更や契約移管の同意と、脆弱性・SBOM開示を混ぜず、相手・時期・話法を決めます。不要な早期通知や期限超過を避けます。

義務台帳・回答履歴に残す再計算根拠

証拠・フィールド	確認できること	注意信号
義務台帳	顧客別の形式、頻度、期限、責任を確認する。	契約PDFへのリンクだけで検索できない。
回答履歴	質問票・監査へ何を表明したか示す。	営業の過去回答が製品実態とずれる。
通知カレンダー	取引・脆弱性・更新の期限を区別する。	起算点と営業日定義がない。
履行証拠	送付ファイル、受領、是正、例外合意を残す。	メール送信だけで相手の受領を確認しない。

削除・置換・更新・表示・ソース提供・例外承認を比較して是正する

リスク項目の是正は最新版への更新だけではありません。部品の削除、代替、設定変更、隔離、表示追加、ソース提供、商用例外取得、顧客合意、期限付き受容など複数の選択肢があります。停止影響、互換性、顧客テスト、法務判断、所要日数を同じ表で比較します。

是正比較票と影響顧客表が示す反証

是正比較票: 候補案の停止、費用、日数、義務充足を比べる。注意信号は最新版更新だけが候補になっている。
影響顧客表: 契約・版・展開窓・連絡先を確認する。注意信号は売上集計だけで技術版が不明。
受入証跡: テスト、SBOM、配布、受領、承認を示す。注意信号はコードマージ日時を全体完了日とする。
残存リスク票: 未完了理由、暫定措置、期限、所有者を残す。注意信号は赤項目を黄へ変えた理由がない。

是正の優先順位は、権利・セキュリティ・契約の重大性、影響製品と顧客、悪用・配布の事実、代替可能性、完了証拠から決めます。赤旗を隠すための短期変更ではなく、買い手が残存リスクを価格・契約・PMIへ反映できる粒度にします。

影響範囲を固定する：部品から成果物、製品、顧客、売上、SLA、データ区分へ展開します。影響が分からないまま修正を始めると優先順位を誤ります。
選択肢を比較する：削除、置換、更新、履行、例外、隔離ごとに日数、停止、費用、残存リスクを見積もります。技術的に最短の案が契約上の完了とは限りません。
完了条件を先に決める：コード変更、再生成SBOM、回帰試験、顧客配布、受領、法務承認の必要状態を定義します。開発チケット完了だけでリスクを閉じないためです。
残存リスクを取引へ渡す：未完了項目の影響、期限、費用、責任、暫定措置を開示資料とDay 1計画へ載せます。クロージングで担当が消えることを防ぎます。

各赤旗に対し、複数の是正案、選定理由、完了証拠、残存リスク、Day 1所有者がありますか。

リポジトリと脆弱性情報をNDA・段階開示・閲覧ログで守る

技術DDでは詳細な証拠が必要ですが、リポジトリ、SBOM、脆弱性台帳には秘密鍵、顧客名、内部URL、未公表脆弱性、個人情報、営業秘密が含まれ得ます。全候補へ早期に原本を渡すことは、検証可能性と機密保護の両方を損ないます。

質問の重要性と取引段階に応じ、集計、匿名化サンプル、限定閲覧、クリーンルーム、専門家報告、原本照合へ段階を上げます。開示したファイルは版・ハッシュ・受領者・目的・返却削除を記録します。

情報を分類する

1. 情報を分類する：公開、社外秘、顧客機密、個人情報、未公表脆弱性、資格情報を検出し表示します。同じVDRフォルダへ権限だけで置く事故を避けます。
2. 検証目的を明示する：買い手の主張、必要フィールド、サンプル、閲覧者、保存可否を質問票で合意します。目的外の全量取得を抑えられます。
3. 段階を選ぶ：集計、マスク、画面共有、閲覧専用環境、第三者確認、原本提出の順に必要性を評価します。証拠強度と漏えい影響を比較できます。
4. 終了処理を確認する：失注・完了・差替時のアクセス停止、ダウンロード確認、返却削除、ログ保全を実施します。取引後に旧ファイルが外部へ残ることを防ぎます。

証拠・フィールド	確認できること	注意信号
情報分類票	機密度、法的制約、開示可能形を決める。	ファイル名だけで機密度を推定する。
開示台帳	誰へ何をいつ何の目的で渡したか示す。	差替前の版の所在が分からない。
閲覧ログ	アクセス、操作、異常、期限を確認する。	共有リンクが無期限・再転送可能。
削除確認	終了後の返却・削除と例外を記録する。	契約条項だけで実施証跡がない。

各資料について、検証したい主張、最小開示、閲覧者、保存可否、失注時の削除まで決まっていますか。

表明保証・補償・前提条件へ技術事実を正確に引き渡す

OSSや脆弱性の問題は、発見しただけで契約文言が自動的に決まるものではありません。対象範囲、知識限定、重要性、開示済み事項、是正期限、損失定義、第三者請求、上限、存続期間などを弁護士が取引全体で検討します。技術チームが曖昧な「準拠しています」を渡すと交渉の前提が崩れます。

技術台帳の各未解決項目が、開示、是正、契約検討、Day 1のいずれへ渡ったか確認できますか。

主張・証拠マトリクスと開示事項一覧を突き合わせる

証拠・フィールド	確認できること	注意信号
主張・証拠マトリクス	各契約論点の技術母集団と根拠を示す。	準拠という一語だけで範囲がない。
開示事項一覧	買い手へ渡した課題と版を固定する。	VDR更新が別紙へ反映されない。
是正コミット表	期限・依存・完了条件を確認する。	ベンダー提供日を自社完了日と誤認する。
責任分担表	取引前後の監視・通知・修正責任を切る。	Day 1の連絡先が退職予定者だけ。

技術・法務台帳の事実を、開示事項、是正コミット、残存リスク、Day 1作業へ一対一で対応させます。契約の解釈や最終文言は専門家へ任せ、記事のテンプレートをそのまま条項へ転記しません。

主張の対象を限定する

主張の対象を限定する：会社、製品、版、期間、重要部品、知識者を明示し、全世界・全履歴という曖昧な母集団を避けます。検証不能な絶対表現を減らせます。
開示事項へ証拠を付ける：課題ID、影響、原因、対応、未完了、買い手受領、VDR版を一覧にします。口頭説明と契約別紙のずれを防ぎます。
是正約束を実行計画へ落とす：責任者、期限、顧客窓、費用、依存先、完了証拠、失敗時措置を作ります。契約締結後に実行不能と判明するのを避けます。
Day 1責任を合意する：売り手、買い手、対象会社、外部ベンダーのどこが監視・通知・更新を担うか決めます。クロージングを境に脆弱性対応が止まることを防ぎます。

誤認・失敗	実務上の修正
全OSSが完全適法と保証する	技術的に検証できる母集団と法的判断を弁護士と限定します。
開示すれば対応不要と考える	契約上の効果と事業継続上の是正必要性を別に判断します。
技術チームだけで条項を直す	事実整理を担当し、契約文言・救済は案件弁護士へ引き継ぎます。

Day 1後もPSIRT・SBOM更新・顧客通知を止めない引継ぎ

クロージング直後は組織、メール、チケット、CI/CD、レジストリ、署名鍵、顧客窓口が変わり、脆弱性情報の受信や修正版の配布が途切れやすい時期です。SBOMをDD時の一回限りの成果物にすると、翌日のリリースから陳腐化します。

判断を急がない：クロージング日に全ツールを切り替える

クロージング日に全ツールを切り替える：最低運用を保ち、検証済み単位で移行します。
DDのSBOMを正本として固定する：各リリースのCI/CDから更新し、生成失敗を出荷条件へ反映します。
窓口変更を顧客へ伝えない：契約とコミュニケーション計画に従い受信・通知経路を確認します。

Day 1の最低運用と将来統合を分けます。まず新しい脆弱性を受け、評価し、顧客へ通知し、修正版とSBOMを同じリリースで出せる経路を維持し、その後に買い手のPSIRT、開発基盤、ポリシーへ段階統合します。

判断・作業	進め方	根拠資料	読み方
受信経路を移す	security窓口、JVN・ベンダー通知、バグ報奨、顧客通報を新旧担当へ並行転送します。ドメインや担当変更で報告が失われることを防ぎます。	PSIRT連絡網	内外の受信、判断、承認、顧客窓口を確認する。注意信号は旧ドメインへしか通知が届かない。
権限を棚卸しする	リポジトリ、CI、レジストリ、署名、SBOM保管、通知システムの管理者と緊急権限を確認します。退職・異動アカウントへの依存を除きます。	権限マトリクス	通常・緊急・復旧の操作主体を示す。注意信号は署名鍵を一人だけが管理する。
最低リリース訓練を行う	架空の部品更新で検知、評価、修正、SBOM再生成、署名、配布、通知を通します。手順書だけで実運用できるとは限りません。	リリース訓練記録	一連の時間、失敗、手動工程を測る。注意信号はテスト環境だけで顧客通知を通さない。
統合バックログを作る	買い手標準との差、期限、互換性、顧客制約、停止許容を優先順位化します。 Day 1に全基盤を一括変更する事故を避けます。	統合バックログ	差分、価値、リスク、依存、期限を管理する。注意信号は買い手標準化を理由に緊急運用を先送りする。

担当者が交代した翌日に脆弱性が届いても、受信からSBOM付き修正版の顧客適用まで止めずに実行できますか。

取締役会へ提出するOSS・SBOMリスクサマリーの設計

取締役会が必要とするのはスキャナの全件出力ではなく、どの製品売上と顧客契約が、どの未確定事項にさらされ、どの選択肢へいつ資源を配分するかという判断材料です。重大件数だけを月次比較すると、走査範囲の拡大で数が増えたのか、実際にリスクが悪化したのか、是正により対象顧客が減ったのかを読み違えます。分子、分母、確認時点、対象版、確度を同じ欄へ表示します。

技術部門は検出結果と到達可能性、法務は利用・配布事実と解釈、営業は顧客義務、財務は是正費用と売上影響を持ち寄ります。各部門の色判定を平均せず、同じ課題IDへ異なる見解と根拠を並べます。例えば法的評価が未確定でも、外部公開製品への到達可能性があれば暫定防御を先行でき、反対に技術的な更新が完了しても顧客配布が終わらなければ残存リスクは閉じません。

経営者向けサマリーは、現在値だけでなく前回との差を理由コードへ分解します。母集団追加、ツール変更、外部情報更新、誤検知解消、修正版作成、顧客適用、例外期限到来を別イベントとして集計すれば、数値改善の実体を説明できます。売却準備中は、買い手へ開示した版と社内最新版を混同せず、VDR版から後に変わった項目を質問ログへ反映します。

一点の総合点で案件の可否を自動判定しないことも重要です。取引前に直すもの、暫定措置と開示で扱うもの、契約条件を弁護士が検討するもの、Day 1へ引き継ぐものを分け、期限超過または顧客影響の拡大時だけ経営会議へ再上程する条件を定めます。これにより、低重要度の件数消化に追われず、企業価値と事業継続に直結する意思決定へ時間を使えます。

経営判断へ直結させる10の表示項目

表示項目	分母・単位	読み取れること	誤読を防ぐ注記	求める決定
顧客稼働版カバレッジ	稼働成果物数	売上を生む実物の生成・検証範囲	最新版だけの比率を全製品へ外挿しない	未生成版の優先順位
双方向差分率	検査した部品・成果物	SBOMの幽霊部品と検出漏れ	ツール・走査面・除外を固定する	追加解析または例外承認
識別不能部品	全検出部品	名称・版・供給者の確度	空欄と該当なしを分ける	調査期限と隔離方針
法務判断待ち	重要ライセンス課題	利用事実は確定したが解釈未了の範囲	スキャナ推定を法的結論にしない	外部弁護士への照会
履行未確認顧客	対象契約・配布先	表示・同梱・提供等の実施状態	方針書ではなく配布実物で測る	通知・再配布・合意の計画
到達可能な脆弱性	確定脆弱性候補	製品文脈で実行され得る範囲	CVSSと悪用・露出を別表示する	暫定防御と修正期限
EOL依存売上	対象製品売上・顧客数	保守不能化が事業へ与える影響	現時点のCVEゼロと混同しない	更新・置換・終了の予算
来歴未確認コード	重要リポジトリ・寄与量	作者・契約根拠が未確認の範囲	行数だけで権利価値を測らない	確認・置換・契約是正
是正後顧客適用率	影響顧客・成果物	修正版が実際に展開された状態	コードマージを完了としない	顧客窓と残存例外
取引後引継ぎ額	未完了課題の費用レンジ	Day 1へ残す工数・外部費・停止影響	一点見積りに確度を付ける	責任分担と予算枠

取締役会資料の全指標に対象製品、対象版、確認日、分母、データ所有者を記載したか。
件数増減を新規発見、範囲変更、外部情報変更、是正、顧客適用へ分解したか。
技術的影響、法的解釈、契約義務、財務影響を一つの総合色へ潰していないか。
重大なUnknownに暫定措置、調査方法、責任者、期限、再上程条件があるか。
買い手へ提出したVDR版と社内最新版の差を開示担当が追跡できるか。
修正済みという表示に、再生成SBOM、回帰試験、署名、顧客配布、受領が含まれるか。
例外承認には有効期限、補完統制、再評価契機、承認権限が設定されているか。
経営判断を要しない低重要度項目は運用会議へ委任し、報告過多を避けているか。

このサマリーは取締役会がライセンス適法性や脆弱性受容を専門家に代わって判断するためのものではありません。経営者が、どの事実が確定し、どの専門判断が残り、顧客・売上・日程・費用へどう波及するかを理解し、資源、取引前是正、開示、契約検討、Day 1引継ぎを選ぶためのものです。元となる5台帳とのリンクと更新履歴を保ちます。

5台帳連携型OSS・SBOMデューデリジェンス管理表

次の表は特定ツールの出力を置き換えるものではありません。製品・リリース、リポジトリ・ビルド、SBOM部品、ライセンス義務、脆弱性・是正という五つの正本を共通IDでつなぐための索引です。一行に結論を詰め込まず、事実、専門判断、対応状態を別々の列へ持ちます。

欄	記入内容	検証方法	更新契機
製品・リリースID	販売・保守・配布の実態へ固定した恒久IDと版。	顧客契約と配布成果物へ双方向で戻れるか。	新規提供、更新、EOL、顧客例外時。
成果物ID・ハッシュ	OS別バイナリ、コンテナ、モバイル、インストーラの同一性。	保管物を再計算し値が一致するか。	ビルド、再署名、再配布、差替時。
生成条件	ソースタグ、ロック、イメージ、ツール・版、設定、時刻、形式。	隔離環境で同じSBOMを再生成できるか。	パイプライン、仕様、ツール変更時。
部品座標	名称、供給者、版、package URL、ハッシュ、関係、深さ。	同名異物と複数版を区別できるか。	依存追加、更新、フォーク、検出補正時。
ライセンス証拠	本文、NOTICE、出所、デュアル選択、商用例外の原本。	対象部品版と保存原本が一致するか。	版更新、提供形態、契約変更時。
利用・配布事実	改変、結合、プロセス、SaaS、バイナリ、ソース、提供先。	実装図、成果物、顧客資料と整合するか。	設計、商品、チャネル変更時。
履行・法務判断	表示、同梱、提供、例外、前提、確認者、確認日の記録。	配布実物と法務判断の前提が一致するか。	新ライセンス、利用変更、法令・契約更新時。
脆弱性観測	情報源、識別、版範囲、取得日時、悪用・EOL情報。	公式情報源へ戻り更新差を確認できるか。	新規公表、評価変更、ベンダー更新時。
製品文脈評価	到達可能性、露出、権限、顧客・データ影響、確度。	コード、設定、実行ログで再実施できるか。	製品版、設定、環境、脅威変更時。
是正・残存リスク	選択肢、決定、期限、担当、暫定措置、完了証拠、未完了。	修正版が顧客へ適用されたところまで追えるか。	決定、遅延、配布、受領、例外期限時。
開示統制	機密区分、開示段階、受領者、VDR版、閲覧、返却削除。	誰がどの版を保持するか説明できるか。	候補追加、優先交渉、差替、失注時。
取引引継ぎ	開示事項、契約検討、Day 1担当、統合バックログへの参照。	未解決項目に受け手と期限があるか。	契約交渉、クロージング、責任移管時。

表の完成度は空欄の少なさではなく、UnknownとNot Applicableを区別し、元証拠へ戻れ、更新の責任が決まっているかで評価します。買い手へは必要な列と証拠だけを段階開示し、原本台帳の機密情報を無制限に複製しません。

SBOM完全性テストとソース来歴チェーンの必須フィールド

完全性の自己宣言を避けるには、分母、走査面、差分、未知、来歴、確度を構造化します。以下は法定様式ではなく、技術・法務・セキュリティが同じサンプルを検証するための独自フィールド辞書です。

1. 対象成果物: 顧客へ配布または本番稼働する実物のIDです。名称、版、プラットフォーム、ハッシュ、顧客区分を固定します。
2. 走査面: ソース、宣言、解決、ビルド、コンテナ、バイナリ等の入口です。単一ツールで見えない領域と差分を表します。
3. 依存関係種別: 直接、推移、静的、動的、実行時、ビルド時等の関係です。対象範囲と影響経路の深さを示します。
4. 部品識別確度: 確定、候補、競合、不明という識別状態です。名称一致による過剰断定を防ぎます。
5. ライセンス確度: 原本確認、レジストリ表示、推定、NOASSERTION等の根拠強度です。法務判断とスキャナ推定を同じ列へ混ぜません。
6. 作者・供給者: 部品または内製コードを提供した主体です。 Git作者、雇用・委託契約、上流プロジェクトへ結びます。
7. 来歴イベント: 作成、持込み、フォーク、コピー、生成、移管、置換の履歴です。現在ファイルから見えない権利根拠を追跡します。
8. 利用形態: 改変、結合、配布、ネットワーク利用等の事実です。ライセンス解釈の前提として技術担当が記録します。
9. 履行証拠: 表示、NOTICE、ライセンス、ソース提供等の実物です。製品版・顧客へ対応し、テンプレートだけを証拠にしません。
10. 脆弱性観測日時: 外部情報を取得・評価した時点です。日々変わるCVE、JVN、ベンダー情報の鮮度を示します。
11. 到達可能性根拠: 該当コードが実行され得る経路と証拠です。 not affected判断へ有効期限と再評価契機を付けます。
12. 影響顧客: 部品・成果物を利用する契約相手と版です。通知、更新窓、SLA、受領確認へつなぎます。
13. 是正状態: 未評価、計画、実装、試験、配布、適用、受領の状態です。開発完了と顧客リスク解消を区別します。
14. 例外期限: 期限付き受容や代替検査を再評価する日です。永久例外化を防ぎ、担当者交代後も通知します。
15. 開示版: 外部へ提示したファイルの版・ハッシュ・受領者です。差替、質問、返却削除を同じ記録へ載せます。

自由記述は補足に使い、主要状態は定義済みコードで集計できるようにします。ただしツールがライセンスの法的結論や脆弱性の受容を自動決定する設計にはしません。人が判断した箇所には、前提、証拠、権限、確認日、再評価条件を残します。

売却前90日でOSS・SBOMの不確実性を減らすロードマップ

90日で全てのコードを無欠陥にする計画ではありません。重要製品の母集団を確定し、検出・判断・是正・開示・引継ぎを動かし、未解決項目を買い手が評価できる状態へ変える一例です。

時期	実施事項	完了条件	経営者の判断
1〜7日	製品、版、顧客、リポジトリ、ビルド、成果物、既存スキャンの所在と責任者を棚卸しする。	母集団、データ源、保存期間、欠落、機密区分が一覧になる。	売上・重要度に基づく対象範囲と開示原則を承認する。
8〜14日	製品ID、リリースID、成果物ID、部品ID、課題IDの対応表を設計する。	重要製品で販売台帳から配布物へ逆引きできる。	各台帳の正本と更新責任を決める。
15〜21日	ソース、ロック、コンテナ、バイナリの走査面と生成条件を標準化する。	一つのリリースで再生成とハッシュ照合に成功する。	利用する仕様版・ツール版・例外承認者を決める。
22〜30日	売上上位・高権限・外部公開製品からSBOMを生成し双方向テストする。	カバレッジ、未知値、差分率、原因コードが見える。	全件展開と追加解析の優先順位を承認する。
31〜38日	ライセンス原本、利用形態、履行物、法務照会を重要部品へ結ぶ。	事実・スキャナ推定・法務判断が別列になる。	外部弁護士へ上げる例外と期限を決める。
39〜46日	作者対応、契約期間、持込み、外注成果の来歴サンプルを検査する。	主要リポジトリの権利根拠と未確認範囲が示される。	確認書、置換、隔離等の是正方針を決める。
47〜54日	CVE、JVN、ベンダー、到達可能性、悪用、EOLを脆弱性台帳へ統合する。	件数ではなく製品文脈で優先度を比較できる。	緊急対応、期限付き例外、顧客通知の権限を定める。
55〜62日	顧客・調達契約、質問票、監査回答からSBOM・通知義務を構造化する。	顧客別の対象、形式、期限、証拠、連絡先が決まる。	取引・脆弱性に関する通知方針を法務と承認する。
63〜70日	赤旗ごとに削除・置換・更新・履行・例外の選択肢を比較する。	影響、費用、停止、期限、完了証拠、残存リスクがある。	取引前是正とDay 1引継ぎを振り分ける。
71〜78日	NDA、匿名化、限定閲覧、クリーンルーム、ログ、削除を含むVDR索引を作る。	主張ごとの最小証拠と段階開示が決まる。	候補段階別の閲覧権限と承認者を指定する。
79〜85日	買い手役が旧版・外注・高リスク部品を選び、証拠から再実施する。	同じ結論へ到達できない項目が未解決ログへ入る。	修正、追加開示、専門家確認、条件反映を決める。
86〜90日	PSIRT受信、緊急更新、SBOM再生成、署名、顧客通知をDay 1想定で訓練する。	担当交代後も一連の運用を完走し失敗点が記録される。	最低運用と買い手基盤統合の順序を最終承認する。

終了時にUnknownが残っても、分母、影響、暫定措置、調査方法、期限、責任者があれば評価可能です。反対に「全件確認済み」と表示しても、成果物へ戻れず、法務判断とツール推定を区別できず、Day 1の受け手がいなければ完了とはいえません。

売り手CTO・CISO・法務が買い手面談で答える12の質問

役職ごとに別の正解を暗記するのではなく、同じ製品・リリース・部品・課題IDへ戻って答えます。質問への回答は対象、確認日、証拠、例外、次回更新を含め、断定できない部分を明示します。

SBOMはどの製品・リリース・成果物を何％カバーしていますか？
分母を販売・配布台帳で示し、生成済み、検証済み、未生成、未知、対象外を分けます。最新版だけの割合を全製品へ外挿しません。
SBOMはどの入力とツール版から生成しましたか？
ソースタグ、ロック、コンテナ、バイナリ、ツール、設定、仕様版、時刻、成果物ハッシュ、再現手順を一つの例で示します。
直接依存以外の部品をどう把握していますか？
推移依存、静的リンク、コピー、フォーク、ベースイメージ、実行時取得、商用SDK、外注納品ごとの探索方法と欠落を答えます。
ライセンス義務を誰がどの事実から判断しますか？
技術が部品版・改変・結合・配布を整理し、法務が原本と前提を確認する責任分担、判断日、再検討条件を示します。
著作権表示やソース提供の履行をどう確認しますか？
方針書ではなく、顧客へ渡ったNOTICE、ライセンス同梱、提供案内、申出、受領等の版別サンプルへ戻ります。
内製コードが会社に帰属する根拠は何ですか？
Git作者、雇用・委託期間、契約、職務、持込み、共同作者、買収前組織を重要リポジトリのサンプルで説明します。
脆弱性件数と事業上の優先順位はどう違いますか？
識別確度、到達可能性、外部露出、権限、顧客データ、悪用、EOL、契約期限を重ねた順位と、件数表示を区別します。
not affectedや例外承認はいつ再評価しますか？
根拠、承認者、有効期限、製品・設定・脅威・外部情報の変更契機、補完統制を示し、永久例外ではないことを説明します。
顧客ごとのSBOM提供・通知義務を把握していますか？
基本契約だけでなく注文書、セキュリティ別紙、質問票、監査回答を構造化した義務台帳と最終履行証拠を示します。
取引前に完了しない是正はどう扱いますか？
影響、選択肢、暫定措置、費用、依存、期限、完了証拠、開示、契約検討、Day 1担当を課題IDで結びます。
リポジトリや未公表脆弱性をどのように開示しますか？
検証目的、最小範囲、匿名化、限定閲覧、専門家報告、受領者、ログ、返却削除を取引段階ごとに説明します。
クロージング翌日に脆弱性が見つかったら誰が動きますか？
受信、評価、緊急権限、修正、SBOM再生成、署名、顧客通知、適用確認の新旧担当と連絡先を時系列で答えます。

回答が食い違った場合は言い回しを統一する前に、製品ID、対象版、確認日、台帳の正本を合わせます。法的評価が未確定なら、技術事実、法務照会中、暫定措置、期限という順で開示し、安全・適法という結論を先に作りません。

一次資料の読み方と更新管理

以下は2026年8月22日時点で確認した行政資料、脆弱性取扱資料、国際標準の公式公開元です。仕様・脆弱性情報・ガイドは更新されるため、記事の要約よりリンク先の現行版、公開日、適用範囲を優先します。

一次資料・公式標準	この記事で確認する論点	更新上の注意
経済産業省「SBOM導入に関する手引 ver.2.0」公表ページ	SBOM導入・運用、脆弱性管理、適合・取引モデルの公式入口。	2024年8月29日公表版。改訂・後続資料の有無を公開前に確認する。
経済産業省のサイバーセキュリティ・ソフトウェア部品表資料・OSS公式資料一覧	英語版手引、概要、チェックリスト、国際共有資料への入口。	英語・日本語資料の版と対象範囲を取り違えない。
経済産業省「OSSの利活用及びそのセキュリティ確保に向けた管理手法に関する事例集」公表ページ	企業のOSS管理体制、役割、課題の実例と資料への公式入口。	2023年公表ページから現行掲載資料を確認し、現在のツール仕様は別資料で補完する。
IPA「OSPOスターターキットドラフト版」	OSSポリシー、役割、教育、ライセンス・セキュリティ運用。	2026年のドラフト版。正式版への更新状態を確認する。
IPA「SBOM導入・運用の手引き」	生成ツール、運用、ライセンス管理の実装例。	教育プロジェクト成果物でありMETI手引との位置付けを区別する。
経済産業省「サイバーセキュリティ経営ガイドライン Ver.3.0」	経営責任、サプライチェーン、委託先、インシデント対応。	掲載中の版と改訂履歴を公開前に再確認する。
IPA「脆弱性対策情報」	JVN・JVN iPedia等の国内脆弱性情報と届出制度への入口。	情報は継続更新されるため件数・評価に確認日時を付ける。
JPCERT/CC「脆弱性関連情報取扱い」	未公表情報の取扱い、調整、公表、関係者の役割。	最新ガイドライン版と個別案件の調整状況を確認する。
NIST SP 800-218「安全なソフトウェア開発の枠組み」	セキュア開発、第三者部品、来歴、組織的な実装の共通語彙。	本文Version 1.1とページ更新日を区別し、法的義務と断定しない。
米国サイバーセキュリティ・インフラセキュリティ庁「ソフトウェア部品表の最低要素・2025年版」	最小データ、生成頻度、カバレッジ、既知・未知等の米国政府資料。	日本国内の一律な法的義務とは扱わず、調達要件を個別確認する。
米国電気通信情報庁「ソフトウェア部品表の最低要素・2021年版」	SBOM最小要素の原型と用語の経緯、および公式PDFへの入口。	CISA 2025資料との新旧関係を明示する。
SPDX仕様書	SPDXの公式仕様、プロファイル、版固定。	候補・RCと正式公開版を混同せず、利用ツールの対応版を確認する。
Ecma International ECMA-424 CycloneDX	CycloneDX仕様の公式公開元とBOM構造。	規格版と個別ツールの実装対応時期を分けて確認する。
OpenChain ISO/IEC 5230「ライセンスの遵守」	持続的なOSSライセンスコンプライアンス・プログラム。	規格のレビュー・改訂状態と認証範囲を公開前に確認する。
文化庁「著作権テキスト」	プログラム著作物、職務著作等の制度上の基礎。	令和6年度版。個別帰属は契約と事実を弁護士へ示して確認する。
文化庁「著作権の登録制度」	プログラム著作物を含む登録手続の公式案内。	登録の存在を全権利・非侵害の保証と扱わない。
特許庁「M&Aにおける知財デューデリジェンス調査研究報告書」	知財DDの対象設定、調査、リスク整理の公的報告。	2017年度資料であり最新法令・現在の開発慣行で補完する。

上表の仕様やガイドは相互に同じ法的効力を持つものではありません。日本の案件で米国政府資料や国際標準を参照するときは、契約・調達・業界要件としての位置付けを明示します。ライセンス解釈、著作権帰属、通知義務、契約救済は、対象版、利用形態、提供先、契約原本を案件弁護士へ渡して確認してください。

よくある質問

SBOMを作ればOSSライセンス違反がないと証明できますか？

証明書にはなりません。SBOMは部品情報を共有する重要な入口ですが、対象範囲、版、未知値、利用・改変・配布の事実、ライセンス原本、履行証拠、法務判断が別に必要です。スキャナの推定を法的結論へ置き換えず、重要部品は製品版と提供形態ごとに弁護士が確認できる証拠パックを作ります。

SPDXとCycloneDXはどちらか一方に統一すべきですか？

一律の答えはありません。利用目的、買い手・顧客の受入仕様、必要フィールド、既存ツール、仕様版、変換損失で選びます。内部の正本データを保ち、必要な形式へ再現可能に出力する方法もあります。取引途中で版を変える場合は、両版、変換条件、検証結果、失われる情報を記録します。

一つのSCAツールで全ての依存関係を把握できますか？

単一走査で全経路を必ず把握できるとは限りません。ソース、manifest、ロック、サブモジュール、コンテナ、バイナリ、コピー断片、実行時取得、商用SDK、外注成果物には異なる検出方法が必要です。重要成果物は複数面を照合し、差分と未知を測ります。ツール名より、分母と再現可能な生成条件を示します。

NOASSERTIONやライセンス不明は直ちに違反ですか？

不明表示だけで違反を断定しません。しかし未評価のまま安全とも扱えません。対象部品版、同梱文書、上流情報、取得契約、利用形態を調べ、確定できない理由、影響、暫定措置、担当、期限を記録します。法的結論は弁護士へ渡し、スキャナ結果と分けます。

SaaSならOSSライセンスの確認は不要ですか？

不要とは限りません。具体的な義務は個別ライセンス本文、改変、結合、ネットワーク利用、配布、顧客への提供物、契約によって変わります。SaaSというラベルだけで結論を出さず、オンプレ版、SDK、クライアントアプリ、コンテナ提供等が併存しないかも確認します。専門的な解釈は弁護士へ依頼します。

スキャン結果の重大CVEがゼロなら安全と説明できますか？

安全を保証できません。検出範囲、部品識別、情報取得時刻、未知の脆弱性、設定、露出、シークレット、独自コードの欠陥、EOLなどは別論点です。ゼロという結果には対象版、ツール・データベース版、確認時刻、除外、未知を付け、継続監視と顧客版への展開を説明します。

到達不能と判断した脆弱性は永久に無視できますか？

永久例外にはしません。該当関数、呼出経路、設定、露出、権限を証拠化し、承認者、有効期限、補完統制、製品・設定・脅威・外部情報の変更時に再評価する契機を持たせます。コード更新で経路が変われば判断も変わるため、SBOMと脆弱性台帳をリリース工程へ組み込みます。

社員が書いたコードなら会社の権利として問題ありませんか？

社員であることだけから個別結論を断定しません。作成時点、職務、契約、持込み、共同作者、過去勤務先、外注・顧客素材等を確認する必要があります。重要リポジトリではGit作者を契約期間と対応し、異常な大量投入や外部メールを調べます。具体的な帰属・譲渡は契約と事実を弁護士へ示します。

買い手へGitリポジトリを全て渡す必要がありますか？

初期段階から全面提供するとは限りません。質問の重要性、取引段階、NDA、顧客秘密、個人情報、秘密鍵、未公表脆弱性を考慮し、集計、匿名サンプル、限定閲覧、クリーンルーム、第三者報告、原本照合を選びます。開示版、受領者、閲覧ログ、返却削除も管理します。

OSSの赤旗はクロージング前に全件直すべきですか？

全件完了を無条件に約束するのではなく、重大性、影響顧客、代替可能性、停止リスク、所要日数、契約期限を評価します。取引前是正、暫定措置、開示、契約条件、Day 1引継ぎを組み合わせます。未完了項目には責任者、期限、費用、完了証拠、買い手の受領を付けます。

サポート終了した旧リリースもSBOM対象ですか？

顧客利用、契約、保守義務、アクセス可能性、データ影響によって扱いを決めます。EOL表示だけで実際の利用が消えるとは限りません。販売・サポート・配布台帳から稼働版を確認し、未生成なら対象外理由、顧客移行、隔離、通知、削除等の対応と期限を記録します。

SBOM整備をすればM&Aの譲渡価格は上がりますか？

価格上昇を保証するものではありません。整備により買い手が構成、権利、脆弱性、是正費用を再検証しやすくなり、不確実性を条件へ反映できる可能性はあります。一方、重大問題が明確になれば費用、補償、前提条件が必要になることもあります。目的は安全に見せることではなく、事実と残存リスクを透明にすることです。

免責事項と専門家へ引き継ぐ境界

本記事はIT企業のOSS・SBOMデューデリジェンスに関する一般的な情報提供であり、個別の法律、知的財産、契約、サイバーセキュリティ、輸出管理、投資、企業価値評価の専門助言ではありません。ライセンス義務、著作権帰属、脆弱性影響、顧客通知、契約上の救済は、部品版、利用形態、提供先、契約、法域、確認時点により結論が変わります。

実案件では、対象製品・版、配布成果物、SBOM生成条件、ライセンス原本、ソース来歴、脆弱性情報、顧客・調達契約、開示履歴をそろえ、弁護士、弁理士、情報セキュリティ専門家、FA等へ確認してください。記事内の架空例、90日計画、台帳は公式標準そのものでも、適法・安全・成約を保証する様式でもありません。

IT企業 M&A SBOMの事実確認日は2026年8月22日です。公開後に制度、法令、会計基準、標準仕様、行政ガイドラインが更新された場合は、IT企業 M&A SBOMに関係するリンク先の最新版と施行日を確認し、この記事の更新履歴へ反映してください。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

IT M&A総合センター編集部

IT企業・Web事業のM&A、会社売却、事業承継に関する実務情報を編集しています。