SBOMで脆弱性を管理するには？ 部品表を受け取った後の確認点

部品表と「影響なし」の文書に、同じ部品名と版がある。それだけで、自社が使う製品へ回答を当てはめられるのでしょうか。公開された公式サンプルを照合すると、参照するBOMの識別子は異なります。実製品の安全性を調べた事例とは分けて、この対応を手掛かりに、部品から製品版、稼働資産まで追う確認点を考えます。

監査で選ぶべきなのは「SBOMを出す会社か否か」という二択にとどまらない。受け取るだけで十分とするか、実際の製品版へひも付け、脆弱性が公表された時に影響と対応を判断できるようにするかである。重要なシステムなら後者を選びたい。ただし中身が分からないまま「一覧があるから安全」と断言せず、欠けた部品と更新の責任を明示する。

部品版が同じでも、対応するBOMは同じか

照合は、部品名→部品版→製品版→稼働資産の四段階に分ける。部品Xの1.2が含まれるSBOMでも、対象製品の旧版の部品表なら、運用中の新版に同じ部品が残るとは分からない。逆に製品名が違っても同じ部品を組み込んでいれば、調査対象になり得る。

VEXの「影響なし」という説明を使う場合も、その発行元、対象版、理由、条件を資産に照合する。機能が無効だから到達できないという理由と、修正版だから不備がないという理由では、再確認の契機が違う。前者は設定変更、後者は版変更へ対応させる。部品表を受領した日ではなく、どの稼働資産へ判断が届いたかを記録する。

公式サンプルでは、部品版が同じでも参照先が異なる

実際のファイルで確認点を追ってみよう。CycloneDX公式リポジトリーの固定版にあるbom.jsonとvex.jsonを照合した。これは形式を学ぶ公開サンプルであり、実運用の製品を調査した事例ではない。SBOM側の対象はexample-app 1.0.0で、部品にはjackson-databind 2.10.0がある。VEX側も同じ部品版を参照し、CVE-2020-25649についてnot_affected、理由はcode_not_reachableと記載している。

部品の名前と版、文書の版がそろっても、BOMの識別子は異なる。BOM-Linkの公式説明では、参照にBOMの識別子、文書版、内部の対象識別子を含める。この二ファイルをそのまま一組の納品物とみなすと、VEXが指すBOMを手元のbom.jsonとして解決できない。別のBOMを参照する設計もあるため、これだけでサンプルの誤りや製品の危険を断定しない。参照先のBOMを入手するか、供給者へ対応関係を尋ねる理由になる。

また、このbom.jsonにはdependencies項目がない。掲載された部品だけから、すべての間接依存を確かめたとはいえない。サンプルの「到達不能」も、記載された評価であり、本稿が実プログラムを解析して確認した結果ではない。製品の配布物や稼働環境の版・設定までは確認していないため、「自社の資産も影響なし」という結論には進めない。

購入側の選択はここで具体化する。対応するBOMと製品版を特定でき、影響なしの条件が自社構成でも成立すると確認できた対象だけ、回答を判断へ使う。BOMの参照先が違う、依存の範囲が不明、現在の構成を照合できない対象は、追加回答と調査を続ける。未知の箇所を「問題なし」へ変えるのではなく、どの対応が途切れたかによって次の問い合わせを変える。

手元の一覧を、現在の製品と構成へ結び付ける

CISAの2025年公開意見募集案、10頁は、版や更新ごとのSBOM、間接依存を含む構成要素、不明な依存関係を分けて扱う。この資料は最終決定ではない。CISAは2026年7月29日の発表で、2025年の意見募集を踏まえた共同ガイダンスの公表と、部品ハッシュ、ライセンス、作成ツール、生成時の文脈などの項目を案内した。ここでは旧案の説明と新しい公表案内を区別して参照する。米国の最低要素を、日本の全取引へ一律に適用する法令や、製品の安全認証として扱わない。

監査担当者は、手元のSBOMが現在使う製品・版・構成に結び付いているかを見る。開発時の部品表だけを受け取り、納入後の更新や別の組込み部品が反映されないなら、緊急時の照合に穴が開く。自社が使う機能を有効化したか、委託先が別のビルドを配布したかも区別する。製品のリリース番号、配布日時、SBOMの版、質問できる窓口を一つの記録で追えるようにする。

脆弱性の名前が一致しても影響確定ではない

CISAの構成要素の透明性に関する文書は、上流の部品が製品に含まれていても、問題となる機能が利用されていなければ、下流の製品が影響を受けない場合があると説明する。VEXのような影響状態の表現は、該当するか、修正済みか、調査中かを伝える助けになる。ただし「影響なし」という申告を無条件で確定扱いするのではなく、どの版と構成、どの根拠に対してそう言えるのか確認する。

反対に、一覧に部品名が見当たらないから安全とも即断しない。部品の名称が別名だったり、間接依存が欠けていたり、手元のSBOMが古い場合がある。CISAの資料は「既知の未知」を明示することにも触れる。受け取る側は完全性が不明な一覧を完全なものとして扱わず、調査中の箇所を残す。重要な脆弱性の発表後には、委託先の回答期限と暫定措置も決める。

仮想例で、判断が逆転するところ

以下は説明用の仮想例であり、特定製品の調査結果ではない。社内にある二つのツールが同じオープンソース部品を含む。片方は問題のある機能を外部から呼び出せる設定で、もう片方はその機能を組み込んでいるが利用経路が無いと委託先が技術的に説明した。前者は外部からの到達を制限し、修正の見通しを急ぐ。後者は影響なしの根拠と版を記録し、設定が変われば再確認する。部品名が同じでも対応を分けられる。

条件を変える。後者の「使っていない」という回答に構成の証拠がなく、提供会社が製品のビルドを更新していた。それなら影響なしと確定せず、調査中として暫定制限を選ぶ可能性がある。逆に前者でも、修正済みの版へ確実に更新でき、動作確認を通せたなら、長期間の利用停止は不要かもしれない。SBOM、脆弱性情報、実際の構成、修正の可能性をつなげて選ぶ。

通知から自社の対策まで、責任をつなぐ

NISTの安全なソフトウェア開発枠組みは、開発者の脆弱性対応と購入者・利用者との情報共有にも役立つ共通語を示す。これはリストを納品した企業は安全だという認証ではない。購入側ができるのは、供給者に必要な構成と更新情報を求め、自社の資産・利用状況と結び付け、重大な問題の通知から対策までの責任を確かめることだ。発見・評価・修正の技術的判断をすべて監査担当者が代行するわけではない。

監査の記録にも境界を設ける。部品表の有無、対象製品・版との一致、更新時の提供方法、欠けた依存、脆弱性発見後の影響回答、対処の承認者を分ける。自動照合ツールを導入しても、名称の取り違えや利用していない機能の誤検知は残る。アラート件数だけを管理成果にしない。重大性、到達可能性、利用者への影響、対策の実行可能性を見て、どの通知を先に処理するか決める。

回答待ちの間も、稼働資産と到達経路を調べる

通知を受けたら、供給者の回答を待つ間にも、自社の稼働資産と到達経路、当面停止できる機能を調べる。先に見た部品名・部品版・製品版・稼働資産の四段階へ、影響判断を対応させる。

対応を閉じるのは、供給者の返答だけでなく、自社への対策適用と確認がつながった時点にする。情報を共有できない範囲は残る制約として記録し、SBOMで見られない運用環境や設定を確認済みに含めない。

毎回の納品物ではなく、使える情報の流れにする

実務では、契約の段階で「どの製品・版へ対応するSBOMか」「更新時にいつ提供されるか」「不明な依存をどう示すか」「脆弱性発見後は誰へ何を伝えるか」を確かめる。運用では、新版を受け取るたびに自社資産との対応を更新し、影響の疑いが出たときに委託先へ質問した結果を追う。監査では一件の公表済み脆弱性を仮にたどり、対象製品から判断・対策までの時間と未解決事項を確認する。

小規模で更新がまれな製品では、すべてを高度な自動処理にする必要はない。製品と版の対応、責任者、連絡先を正確に保ち、重大な通知時に手で追えるなら、その範囲で足りる場合がある。複数の製品や頻繁な更新を抱えるなら、一覧の保管だけでは追い切れず、機械可読性と変更履歴の管理が必要になる。規模ではなく、必要な時間内に影響を判断できるかが分かれ目である。

SBOMの取得は出発点であり、結論ではない。今使う版と結び付き、既知の欠落が示され、脆弱性が出たときに構成と利用条件を照合し、対策へつなげられるなら、管理に役立つ。版が不明で通知先もなく、リストを保存するだけなら、監査上は「取得済み」と「影響判断可能」を分けて報告するべきだ。