INSIGHT
AIが選んだ部品を、会社が把握できる状態にする——SBOMの使いどころ
部品一覧を、現在動いているアプリの版へどう結び付けるか。
AIの支援で社内アプリを作り、無事に公開できた。数か月後、あるソフトウェア部品に脆弱性が見つかったという連絡が来る。ところが、開発時のメモには部品名しかなく、本番で使う版、間接的に入った部品、実際の稼働物との関係が分からない。
動くコードを納品しただけでは、会社が使っているソフトウェアの構成まで引き継いだことにはならない。AIが提案した部品も、人が追加した部品も、別の部品が連れてきた部品も、本番で使えば会社の管理対象になる。そこで役立つのがSBOMと依存関係の記録である。
SBOMは「安全なソフトウェア」の証明書ではない。稼働する成果物に何が含まれ、問題や変更が生じたときにどこを調べるかを示す構成台帳である。
SBOMと依存関係は、違う問いに答える
SBOMはSoftware Bill of Materialsの略で、ソフトウェアに含まれる部品、版、識別子、供給元などを機械で読める形にした一覧である。依存関係グラフは、どの部品がどの部品を必要としているかを結び付ける。直接選んだ部品だけでなく、その部品が内部で必要とする間接依存を追う助けになる。
OWASP Dependency Graph & SBOM Best Practices Cheat Sheet は、構成要素の名前と版、パッケージ識別子、チェックサム、供給元、生成時刻、ビルド識別子、直接・間接の関係などを実務的な記録項目として挙げる。また、依存関係を解決したビルド時にSBOMを生成し、成果物へ結び付ける考え方を示している。
一覧は「何が含まれるか」に答え、グラフは「なぜ含まれるか」に答える。脆弱性情報に出た部品が、自社アプリから直接使われているのか、別部品の依存として入ったのかが分かれば、影響確認や更新の入口を見つけやすい。
ただし、この記事はOWASPの例示するすべての項目やツールを、そのまま全案件の必須要件にするものではない。システムの重要度、配布方法、契約、開発環境に応じて、会社が必要な項目と形式を決める。
一覧を、本番の成果物へ結び付ける
開発者の端末でSBOMを一度作っても、本番の説明に使えるとは限らない。開発中には使ったが公開物から外れた部品、ビルド時に選ばれた別の版、コンテナへ後から入った部品があり得る。重要なのは、実際に配布・稼働する成果物と、どのSBOMが対応するかである。
外部サービスとして利用するAIのモデルや契約条件は、アプリ内の部品一覧だけでは把握できない場合がある。SBOMの対象外なら、接続先、利用するモデル、管理者を別のサービス台帳へ残し、アプリの版からたどれるようにする。一つの一覧ですべてを説明できるように見せない。
公開単位ごとに、アプリの版、成果物の識別子やチェックサム、ビルド番号、SBOMの生成日時・生成方法・保管先を結び付ける。Webアプリなら公開日時と稼働環境、配布ソフトなら配布ファイルと版、コンテナならイメージの識別子を残す。前の版と新しい版のSBOMを比較できれば、部品の追加・削除・更新も追える。
AIの会話に「このライブラリを使った」と残っていても、それは稼働構成の根拠にはならない。提案された部品が採用されなかった場合もあれば、コード生成後のビルドで別の依存が解決される場合もある。チャット履歴ではなく、成果物を作った工程から構成情報を得る。
「AIが選んだ部品の一覧」ではなく、「この稼働物に含まれる部品の一覧」を引き継ぐ。作成者の記憶と本番構成を混ぜない。
SBOMに載っていても、影響までは決まらない
脆弱性通知を受けたとき、SBOMに該当部品があれば影響確認を始められる。しかし、一覧に名前があるだけで、脆弱な機能が実行される、外部から攻撃できる、直ちに更新が必要、とまでは決まらない。利用方法、設定、到達経路、緩和策などを技術担当が確認する。
反対に、一覧に見つからないから影響なしとも限らない。SBOMが古い、生成範囲にOSやコンテナ層が含まれない、別名や識別子の違いで照合できない、実行時に部品を取得する、といった可能性がある。生成の対象範囲と品質を確認し、「載っていない」と「含まれていない」を分ける。
SBOMには、ライセンス情報を記録できる形式もある。だが、文字列が記録されていることと、利用条件を満たしていることは別である。同様に、部品の供給元URLがあることは真正性の保証ではなく、チェックサムがあることは安全性の保証ではない。契約・権利・脆弱性の判断は、それぞれの担当と根拠へつなぐ。
OWASP資料は、脆弱性が実際の製品・部品に影響するかを機械可読で伝えるVEXにも触れる。それも供給者や作成主体の評価と条件を確認する資料であり、SBOMそのものが影響判定を完了させるわけではない。
通知を受けた日の動きを、台帳に結び付ける
部品の問題が公表されたら、まず名称、版、識別子を、現在稼働する版のSBOMへ照合する。該当した場合は、どのシステム、顧客、環境に届くかを確認し、技術担当が利用状況と影響を調べる。業務責任者は、停止、機能制限、緩和、更新のどれを選ぶかを、影響と代替手段から決める。
更新する場合は、変更後の成果物からSBOMを作り直し、対象部品が除かれたか、または版が変わったかを確認する。別の部品が追加された場合も差分に残す。更新しないと判断する場合は、該当しない条件、緩和策、次の確認日、判断者を記録する。
ここでSBOMの担当を開発者一人に固定すると、休職や退職で運用が止まる。構成情報の保管責任、脆弱性通知を受ける窓口、技術的な影響確認、業務の利用判断を分ける。外部開発なら、納品時にどの形式・対象範囲・公開版との対応で受け取るかを契約や受入条件へ置く。
まず自分の成果物一つを、部品の一覧へ結び付ける
まず自分が作ったアプリを一つ選び、どの公開版にどの部品一覧が対応するかを確かめる。生成方法や間接依存が分からない場合は、アプリの版と作成工程を開発担当へ渡して確認する。全社の台帳を一人で完成させる必要はない。
構成情報には、内部のリポジトリ名、開発環境、供給元など、公開範囲を絞るべき情報が含まれることがある。OWASP資料もアクセス制御の考慮に触れている。取引先へ渡す版、社内の運用担当が見る版、一般公開する版を同じにする必要はない。必要な人が調査でき、不要な情報を広げない範囲を決める。
開発・運用の担当へ確認するのは、「SBOMを作る」だけではない。どの稼働物に対応させるか、生成に失敗した公開をどう扱うか、通知を誰が受け、いつ見直すか、外部開発から何を受け取るかである。実際の問い合わせを一件想定し、台帳から対象システムと担当へたどれるかを試す。
SBOMの価値は行数の多さではなく、稼働中の版から構成へ、構成から担当と判断記録へたどれることにある。
部品の一覧を、稼働中の版と調査を担う人へ結び付ける
AIの支援で部品を選んでも、会社が本番で使うなら、その構成を引き継げる状態が要る。SBOMと依存関係グラフは、部品名や版を、実際の成果物と結び付けるための道具である。
次に渡す成果物について、部品一覧の保管先と、対応する公開版を一組で残したい。自分で確かめられない生成範囲や間接依存は、未確認として担当へ渡す。安全性の証明書ではなく、後から調査を始められる記録として引き継ぐ。