📝
SBOMの重要性と導入事例：企業のセキュリティ強化のカギ レポート
公開
2025-03-13
文章量
約4486字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
2025年3月5日に開催された「SBOMの重要性と導入事例：企業のセキュリティ強化のカギ」は、ソフトウェアサプライチェーンのリスクが増大する中で、その対策として注目されているSBOM（Software Bill of Materials）について理解を深めるイベントでした。
主催はFindy Toolsで、セキュリティ担当者やエンジニアを含む多くの参加者がオンラインで集結。
SBOMを導入・運用する上で直面しやすい課題や、それを乗り越えるためのポイントが具体的に語られ、会場（オンライン）では活発な質疑応答も行われました。
以下では、東京ガスｉネット株式会社の繁田大輝（しげた だいき）さん、そしてKINTOテクノロジーズ株式会社の島村純平（しまむら じゅんぺい）さんの2名によるセッションの内容を中心に、当日のレポートをまとめます。
ソフトウェアサプライチェーンの脅威とSBOMへの期待
近年、サプライチェーンを狙ったサイバー攻撃が急増しており、オープンソースソフトウェア（OSS）の脆弱性を突かれたり、依存する外部ライブラリに改ざんが仕込まれたりする事例が増えています。
そこで「そもそも自社システムにはどんなコンポーネントが含まれているのか」を可視化し、万が一脆弱性が見つかった際には迅速に対応できるようにするのがSBOM（Software Bill of Materials）の目的です。
SBOMは「ソフトウェアの成分表」とも呼ばれ、各コンポーネントの名称やバージョン、ライセンス情報などを一覧化します。近年は米国・欧州を中心に法規制の動きも強まり、日本国内でもSBOMの導入を検討する企業が増えてきました。ただし、実際にSBOMの作成や運用に取り組もうとすると、
- どの工程でSBOMを生成するか
- 使用するツールをどう選ぶか
- 膨大に検出される脆弱性やEOL（End of Life）情報をどう扱うか
といった課題が山積し、具体的な方法に悩む声が絶えません。
今回のイベントでは、このSBOMを巡る最新動向を踏まえつつ、実際に企業内で導入・運用に取り組んでいる事例が共有されました。
1. 「SBOMのすゝめ 導入・運用のポイント」
登壇者： 東京ガスｉネット株式会社 CSIRT / 繁田 大輝 さん
1-1. サプライチェーン攻撃の増加とSBOM導入の背景
最初のセッションでは、東京ガスｉネット株式会社でCSIRT業務に携わる繁田さんが登壇。はじめに、ソフトウェアサプライチェーン攻撃が年々巧妙化し、Log4j脆弱性のように多くの組織が影響を受ける事件が繰り返されている現状が解説されました。
ポイントは「脆弱性を素早く把握し、修正プログラムを適用する」こと。しかし実際には、OSSライブラリを含む多層構造のソフトウェアでは、どこにどの脆弱ライブラリが潜んでいるか把握が難しく、時間差で攻撃に遭うケースが後を絶たないといいます。
1-2. SBOMがもたらすメリットと国際的な動向
SBOM（Software Bill of Materials）は、ソフトウェアを構成するあらゆるコンポーネントを可視化することで、脆弱性の特定や、ライセンス違反リスクの低減にも役立ちます。
海外ではEUがサイバーレジリエンス法（Cyber Resilience Act）を2027年頃から完全施行予定で、SBOMの提供が必須となる見込み。アメリカでも2021年の大統領令以降、公的調達でSBOMが要件化される動きが進んでおり、日本企業も無視できない状況だと繁田さんは指摘しました。
1-3. 導入・運用のポイントと注意点
繁田さんはSBOMについて、「作るだけで満足しては意味がない。適切に活用してこそセキュリティ向上につながる」と強調します。ただし、ツールやフォーマットによって検出されるコンポーネント数に差があったり、生成されたSBOMの“精度”にはまだバラつきがあるとのこと。
さらにSBOMを元に脆弱性を洗い出すと、これまで可視化できていなかった非常に多くの問題点が一度に炙り出され、「対応コストがむしろ増大する可能性がある」という現実的な課題にも触れられました。
ポイントまとめ：
- SBOMはソフトウェアサプライチェーンの可視化に大いに役立つが、精度にバラつきがある
- EUの法規制によって、多くの企業が導入を進めざるを得ない流れになる
- SBOMで脆弱性検知の範囲は広がる一方、対応負荷が増える懸念も大きい
- 本質的には「脆弱性管理プロセスの再設計」とセットで導入を進める必要がある
繁田さんは「ガイドラインや他社事例を参照しつつ、自社のプロダクト特性に合わせて無理ない範囲から始めるのが重要」と述べ、最後にIPAなどで公開されている手引き資料も紹介しつつ発表を締めくくりました。
2. 「KTCにおけるSBOM導入事例と展望」
登壇者： KINTOテクノロジーズ株式会社 / 島村 純平 さん
2-1. SBOM導入のきっかけ：EOLライブラリ対策
続くセッションは、トヨタ自動車グループの一員として、車のサブスクリプションなどを手がけるKINTOテクノロジーズ株式会社の島村さんが担当。
同社では、自社開発している多彩なWebサービスにおいて、「EOL（End of Life）を迎えたライブラリを使わない」 という社内ルールを徹底するためにSBOMを導入したそうです。
ログ4j事件などを機に、ベースとなるコンテナイメージやOSライブラリを含め、メンテナンス終了済みのソフトウェアはセキュリティリスクが高いと判断。そこでCICDパイプライン内でSBOMを自動生成し、EOLライブラリの検知と共有を始めたといいます。
2-2. 実際の導入ステップと挙がった課題
島村さんのチームでは、GitHub ActionsのCICD上でOSSツール（Trivy、Syftなど）を利用しながら、ランタイムレベルのSBOMを作成。
そこから社内のCMDB（構成管理DB）と紐付けることで、担当者がどのイメージを使っているかを検索・確認できるしくみにしました。
しかし導入時には、次のような問題が発生したとのこと：
- リポジトリやイメージと担当者の紐付け
- 同じレポジトリから複数イメージをビルドするケースなどで「これは誰が管理しているSBOMか？」が分からなくなる。
- SBOMを「どう可視化するか」
- セキュリティ担当者は直接JSONファイルを見れば把握できるが、開発チームにも分かりやすいUIが必要。
- ツールのバージョン差分やフォーマット更新
- OSSツールが活発にアップデートされ、フォーマットが変わるとSBOMのパースが急に失敗するリスクがある。
これらに対しては、CMDB上に検索機能を実装したり、バージョン固定で一時的に運用を安定化させたり、最終的に可視化ダッシュボードを提供したりするなどの対応で解決を図ったそうです。
2-3. 得られた効果と今後の展望
現状、同社ではEOLライブラリ検知に関しては一定の成果を上げているものの、SBOMを活用した脆弱性管理はまだ運用しきれていないとのこと。
SBOMで見える化された情報をベースに、ライブラリアップグレードの具体的な手順提案まで自動化したいというビジョンもあるそうですが、ツールのフォーマット更新やライブラリの依存関係をどう機械的に判定するかなど、まだまだ乗り越えるべきハードルは高いといいます。
しかし島村さんは「最初から100点を狙うのではなく、スコープを制限してまずは回してみる。その上で課題を明確化して対処するほうが導入はスムーズ」とアドバイス。
半年ほどでCICDパイプラインへSBOM生成を組み込み、最低限の可視化を実現した同社の経験は、多くの参加者にとってもヒントになったのではないでしょうか。
全体を踏まえた感想
「まずは見える化」から一歩ずつ
今回のイベントを通して浮かび上がったのは、SBOMがもたらす恩恵の大きさと同時に、その運用には「予想以上のコストや手間」が発生するというリアルな課題感です。特に以下の3点が強く印象に残りました。
- ツールと精度の問題
- 同じコンテナイメージを走査しても、SBOMツールの差異やフォーマットの違いで検出結果が異なる。まだ“決定版”がない状態である。
- 運用負荷増大の懸念
- SBOMは脆弱性を可視化してくれる一方、「可視化された課題への対応」が追いつかないと本質的なセキュリティ強化につながらない。
- 対応プロセスを自動化・効率化する仕組み（脆弱性の優先度付け、チケット連携など）が求められる。
- 導入は徐々に、しかし取り組まない選択肢はない
- EUや米国の法令をはじめ、世界的にSBOMの要求は強まっている。多少スコープを絞った形でも、早期に着手して慣れながら拡大していくのが得策。
同時に、スピーカーのお二人はいずれも「会社やサービスの置かれた状況によって最適解は変わる」と強調していました。自社のセキュリティ要件やツール選定の基準、法律対応などを踏まえつつ、まずは小さく導入して継続的にアップデートしていく。
そうした“スモールスタート”の考え方こそが、急ピッチで変化する国際動向にうまく適応する鍵だと感じられます。
今回のイベントを振り返って
「セキュリティのためのSBOM」から「活かすためのSBOM」へ
SBOMは単なるドキュメントではなく、ソフトウェア全体を俯瞰する“地図”のようなものです。その地図を使えば、ライブラリのライフサイクルや脆弱性をリアルタイムに把握でき、問題が起きたときも素早く動けるでしょう。
一方、地図を持つだけでは安全にはならず、そこからアクションを起こしてこそ意味があるのも事実。
今回登壇いただいた東京ガスｉネット株式会社の繁田さん、KINTOテクノロジーズ株式会社の島村さんの事例は、それぞれ“セキュリティ担当者目線”と“プラットフォーム（生産性）支援チーム目線”という対照的な立場から、SBOMの導入が進むリアルを示してくれました。両者に共通していたのは「小さな成功体験を積みながら、運用負荷を最小限に抑えて拡大する」というアプローチ。
大がかりな仕組みを最初から整えようとすると導入ハードルが高くなりがちですが、OSSツールを使ったり一部のプロジェクトから始めたりすることで、徐々に知見を貯めていく姿勢は多くの企業にも参考になるはずです。
「ソフトウェアのサプライチェーンを守る」――それは今や開発者だけでなく、ビジネス全体にとって避けられないテーマとなりました。SBOMを入り口に、社内でのセキュリティ意識が高まり、開発プロセスと運用体制がより洗練されていく未来も十分にありえます。
今回のセミナーは、まさに“SBOMをどう使いこなし、どう運用するか”にフォーカスした内容で、参加者それぞれが明日から自社で進める一歩をイメージできる充実した時間になったのではないでしょうか。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
