SBOM（ソフトウェア部品表）の重要性と効率的な対応方法～オンラインセミナー開催レポート～
本内容と同様のセミナーを実施しておりますので、ご興味ある方はぜひセミナーページからお申し込みください。
昨今、「SBOM（ソフトウェア部品表）」が急速に注目を集めており、運用に向けて情報収集をされている方も多いのではないでしょうか。
yamoryでは、7月27日に「SBOMの重要性と効率的な対応方法」に関するオンラインセミナーを開催しました。
SBOMの必要性が増している背景や国内外の状況、具体的なSBOMの仕様のほか、脆弱性管理クラウド「yamory」を利用したSBOM対応についてお伝えしました。
今回は、セミナーの内容を抜粋してレポートします。
登壇者
鈴木康弘 yamoryプロダクトオーナー
東京工業大学大学院修士課程修了後、ITコンサルティング会社を経て、2010年9月にビズリーチへ入社。ビズリーチの立ち上げ初期から携わり、キャリトレなど4つのサービスや開発部門を立ち上げてきた。現在は自身が起案した「yamory」のプロダクトオーナーとして、プロジェクト全体のディレクションや組織マネジメントを行っている。
SBOMとは？
SBOM（Software Bill of Material）は、ソフトウェア部品表のことで、ソフトウェアサプライチェーンのなかで利用されているソフトウェア部品を正確に把握するための手法です。
SBOMの必要性が増している背景
（1）ソフトウェアの依存関係とシステムレイヤーの複雑化
ソフトウェア開発において、Open Source Software（OSS）などのソフトウェア部品を利用する事が当たり前になりました。ソフトウェアは、何階層にも依存関係をもつ複雑な構造を持ちます。通常のIT資産管理の対象では、一番上位のソフトウェア部品のみを管理しており、内部でどのようなソフトウェアが利用されているかは見えません。よって、内部で利用しているソフトウェア部品に脆弱性があっても、そのリスクを管理することは難しくなっています。
また、ITシステムは複数のシステムレイヤーが連動して動作するため、各システムレイヤーでどのようなソフトウェア部品が利用されているか正確に把握する必要があります。
システムレイヤーの全体像
さらに、Dockerなどのコンテナ技術の普及も進んでいます。システムレイヤーの構成がまとまったコンテナイメージは一見便利ですが、内部で利用されているソフトウェア部品の管理という視点においては、正確に把握することが難しくなっています。
（2）ソフトウェアサプライチェーンの複雑化
エンドユーザーがサービスや製品を利用するまでには、さまざまなサプライチェーンを経由します。ソフトウェアに関しても同様で、さまざまなサプライヤーが作成したソフトウェア（OSSを含む）を部品として利用しながら、それが最終的なサービスや製品に組み込まれていきます。ソフトウェアの場合、物理的な部品ではないので、最終サービスや製品を管理しているメーカーは、内部で利用されているソフトウェア部品を把握することが困難です。しかし、ソフトウェア部品を把握できていなければ、セキュリティリスクに対処できません。
SBOMの目的
- ソフトウェア部品の資産管理
- セキュリティリスク管理
- 脆弱性管理
- マリシャスパッケージ、改竄
- ライセンスリスク管理
SBOMをしっかりと管理できていない状態でサービス・製品を販売するということは、内部で抱えているリスクを把握しないまま販売していることになります。リスクが顕在化した場合、その責任を問われることになります。
近年、SBOMが注目を集めている理由は、実際に利用しているソフトウェア部品によるセキュリティリスクが高まっているためです。
実際に起きたインシデント例
出典：経済産業省「サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理⼿法等検討タスクフォースの検討の⽅向性」
記憶に新しい昨年12月のLog4Shellの問題は、ソフトウェアのどこで使われているかわからず、すべてのシステム、サーバーを網羅的に確認するという莫大な労力とコストを多くの企業が払うことになりました。
米国の状況と大統領令
米国では、サイバーセキュリティリスクの高まりや多発するインシデントを受け、SBOM に関連する大統領令が発令されました。
大統領令のポイント
- ソフトウェア・サプライチェーンの確保に向け、NIST（米国国立標準技術研究所）が中心となりガイドラインを策定する旨を指示しており、このガイドラインには製品購入者に対するSBOM提供に関する項目も含まれる
- NISTに対して、NTIA（米国商務省電気通信情報局）と連携してSBOMの最小要素を公開することを指示
- 将来的には、公開されたソフトウェア・サプライチェーンに関するガイダンスの要求事項に基づき、連邦政府のソフトウェア調達に関するFAR（連邦調達規則）が改正される予定
国内の状況
日本国内でも経済産業省を中心に、サイバー・フィジカルセキュリティ対策フレームワーク実現のため、ソフトウェア管理手法を検討するタスクフォースが動いています。SBOM活用促進のための実証事業（PoC）を実施中です。
出典：経済産業省「サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理⼿法等検討タスクフォースの検討の⽅向性」
SBOMのデータフォーマット
大統領令とSBOMの最小要素
大統領令によりSBOMは米国連邦政府の取り組みとなりました。この大統領令に従い、同年7月12日にNTIAがSBOMの最小要素を定めた「The Minimum Elements For a Software Bill of Materials」を公開しました。
SPDX
SPDXは、"The Software Package Data Exchange"の略称で、SBOMの表現するデータフォーマットの1つです。SBOMに関連するデータフォーマット形式はさまざまありますが、2021年9月にSPDXがSBOMに関連するISO標準（ISO/IEC 5962:2021）として認められたため、今後SPDXがSBOMの業界標準のデータフォーマットになることが予想されます。
SBOMデータフォーマットの課題
（1）「セキュリティリスク管理」は企業に任せられる
SBOMを作成するだけでは、「ソフトウェア部品の資産管理」と「ライセンスリスク管理」という目的しか達成できません。サイバーセキュリティリスクの高まりにより、サプライチェーンの「セキュリティリスク管理」も大きな目的になっていますが、その部分はSBOMを活用する企業に任されています。現実的には何らかの脆弱性データベースなどと突き合わせる必要性が出てきます。
（2）SBOMと既存の脆弱性データベースとの自動マッチングは難しい
SBOMと脆弱性DBとの突き合わせを考えた時に、前述した2つのSBOMのデータフォーマットの自由度の高さが大きな問題となります。たとえば一番代表的な脆弱性データベースにNVDがありますが、NVDの情報と、SPDX examplesのSBOMのソフトウェア情報を自動でマッチングすることはできず、手動で確認することになります。
同様に、あるツールで生成したSBOMのファイルを、他のツールで読み込んで脆弱性管理することも現状では困難です。
SBOMのデータベース化、自動の脆弱性データベースとのマッチングができなければ、SBOMを活用できない事態になりかねません。SBOMを利用したサプライチェーンのセキュリティリスク管理を実現するためには、この課題を業会全体で乗り越える必要があります。
脆弱性管理クラウド「yamory」を用いたSBOM対応
脆弱性管理クラウド「yamory」は、OS、ミドルウェア、アプリケーションの脆弱性対策とOSSライセンス違反リスクの検知ができる国産のクラウドサービスです。
yamoryの特徴
- ワンストップで可視化・一元管理
- 間接依存の脆弱性を検知
SBOMや脆弱性管理における活用シーン
一企業内で、SBOM運用を開始する
yamoryは下記機能を有しているため、まず一企業内でSBOMの管理運用が開始できます。
- ソフトウェアの自動検出（依存関係も含め）
- SBOMのデータベース管理と横断検索
- SBOMのファイル出力
- 脆弱性管理
- オープンソースライセンス違反リスクの検出
【事例】log4jの脆弱性対応がたった“7時間”で完了（Visional）。
「日常的にソフトウェアの状態を把握していたことで、時間を短縮できました。脆弱性の発見からどのような問題があるのかを確認するまでに約50分、その後、実際に脆弱性が社内にあるかをyamoryなどのスキャンツールを使って確認するのに約45分、プロダクトに連絡し本当に問題があるのか最終確認をするのに約5時間で完了しています」（Visional ITプラットフォーム本部本部長若井氏）
グループ企業内でSBOM運用を開始する
yamoryでは、グループ企業内でyamoryを活用できるプランを用意しています。グループ企業内で複数のチームを作成し、グループ全体で利用することで、SBOMデータベースの横断検索が可能となります。
今後、お客様の要望に応じて、SBOM関連機能もアップデートしていきます。
yamoryを用いたSBOM対応、脆弱性管理にご興味をお持ちの方は、ぜひお問い合わせください。
