本内容と同様のセミナーを実施しておりますので、ご興味ある方はぜひセミナーページからお申し込みください。

昨今、「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 の特徴＞

（1）ワンストップで可視化・一元管理
（2）間接依存の脆弱性を検知

＜SBOM や脆弱性管理における活用シーン＞

一企業内で、SBOM 運用を開始する

yamory は下記機能を有しているため、まず一企業内で SBOM の管理運用が開始できます。

• ソフトウェアの自動検出（依存関係も含め）
• SBOM のデータベース管理と横断検索
• SBOM のファイル出力
• 脆弱性管理
• オープンソースライセンス違反リスクの検出

【事例】log4j の脆弱性対応がたった“7 時間”で完了（Visional）。

「日常的にソフトウェアの状態を把握していたことで、時間を短縮できました。脆弱性の発見からどのような問題があるのかを確認するまでに約 50 分、その後、実際に脆弱性が社内にあるかを yamory などのスキャンツールを使って確認するのに約 45 分、プロダクトに連絡し本当に問題があるのか最終確認をするのに約 5 時間で完了しています」（Visional IT プラットフォーム本部本部長若井氏）

出典：Visional の「セキュリティ」戦略、脆弱性管理の自動化で得た“驚きの成果”とは ｜ビジネス+IT

グループ企業内で SBOM 運用を開始する

yamory では、グループ企業内で yamory を活用できるプランを用意しています。グループ企業内で複数のチームを作成し、グループ全体で利用することで、SBOM データベースの横断検索が可能となります。

今後、お客様の要望に応じて、SBOM 関連機能もアップデートしていきます。
yamory を用いた SBOM 対応、脆弱性管理にご興味をお持ちの方は、ぜひお問い合わせください。