TOUCH THE SECURITY Powered by Security Service G

コラム

2024.02.19

【初心者向け】SBOM(Software Bill of Materials)を解説

皆さん、こんにちは。 PXT セキュリティ本部 ITSEC部 ITSEC Gの松本です。 今回は、最近話題になりつつある、SBOMについて、基本的な内容をまとめました。 今後の世の中で普及していくと想定される仕組みであるため、ぜひチェックしてみてください。

監修:大畑 健一(おおはた けんいち)

パーソルクロステクノロジー株式会社
採用・教育統括本部 ICT採用本部 キャリア採用部 2G
メーカーや教育、キャリア系を中心にネットワークエンジニアの経験を持つ。
2020年10月にパーソルクロステクノロジー(旧パーソルテクノロジースタッフ)に入社。
2022年4月から現在の部署にて中途採用エンジニア向けの広報を担当。

SBOMとは

まず、SBOMとは「Software Bill of Materials」の略称です。日本語に訳すと”ソフトウェア部品表”です。

ここでいう部品表とは、ソフトウェア製品を構成するコンポーネントの一覧の事です。 1つのソフトウェア製品を作るには、関わる様々な企業(=サプライチェーン)が関わり、各企業が開発/利用したOSSや製品が含まれており、それらを1つの部品表、つまりSBOMとして管理します。

イメージしやすい例として、食品表示を挙げます。 食品に含まれる原材料を可視化した表示を見ることで、アレルギーや食の禁忌などへの対応が可能となります。これは、製造、加工をサプライチェーン上で複数の企業が行っていても、その過程で含まれる原材料は全て食品表示に含まれることで可視化されるためです。

”SBOMの例え 食品表示”

同様にSBOMでは、ソフトウェアに含まれる部品を各企業が特定し、1つの部品表(=SBOM)として作成することで、脆弱性の早期発見・対応といったリスク管理を「サプライチェーン全体で」実施しやすくなります。

また、SBOMは、2018年からNTIA(米国の政府機関)によって実証が開始され、2021年5月の米国大統領令を1つの起点とし、世界的に普及を進めようとする動きがあります。

SBOMの必要性

そもそも、サプライチェーンリスクという言葉を聞いた方もいるでしょう。 調達から開発、販売、委託等、製品に関わる一連の商流において、製品のライフサイクルに関与するモノや人の繋がりを足掛かりとするサイバー攻撃が存在し、それによってセキュリティ事故や不正アクセス等の被害を受ける事件が起こっています。

例えば、IPAの「情報セキュリティ10大脅威」では、年々サプライチェーンへの攻撃の順位が上昇しています。

サプライチェーンの弱点を悪用した攻撃
2024年:2位
2023年:2位
2022年:3位
2021年:4位
”

図1 IPA 情報セキュリティ10大脅威(2024年)
https://www.ipa.go.jp/security/10threats/10threats2024.html

このように、製品を販売や提供するサプライヤーだけでなく、製品を構成するソフトウェアや部品などに携わる企業にもリスクが浮き彫りとなっており、これらを適切に管理し、リスクを低減し、脆弱性が発見された際は迅速に対応するために、SBOMを活用しよう、という動きが起こっています。

SBOM導入のメリット

SBOMを作成し、それを活用することで得られる主なメリットとしては、

  • 脆弱性管理
  • ライセンス管理
  • 開発生産性向上
の3点があります。

現状、最も注目を集めているのは、SBOMを作成・活用し、脆弱性管理を行うことです。 SBOMを活用、サプライチェーンのコンポーネントを管理することで、脆弱性がその製品に含まれるコンポーネントの一部で発生した場合、速やかに対応することを目指す企業が増えつつあります。

現在、サプライチェーンで1つのソフトウェア製品を作成する際、ソフトウェアのコンポーネントについて、作成に関わる各企業が独自の部品表や管理を行っているため、自社のコンポーネントに関する情報しか持っていません。 そうした場合、サプライチェーンの上流は、サプライチェーン各社のコンポーネントの中身(構成要素)を把握できず、それによって次のリスクが生じる可能性があります。

  • 脆弱性の発見が遅れ、初動対応が遅れてしまう
  • 脆弱性の発生に気付かず、脆弱性が残留してしまう
  • 部品表を手動で管理するため管理コストがかかる

例えば、以前話題になった「Log4Shell」という脆弱性がありました。 これは、Apacheのゼロデイ脆弱性を突くことで、任意のコードをリモートで実行できるものでした。

Apache Log4jが含まれる製品は非常に多く、またコンポーネント内に含まれていることが多いため、サプライチェーン各社でコンポーネントを管理している場合、影響範囲の特定に非常に時間がかかる場合がありました。

こういった脆弱性が発見された際、SBOMを導入することで先に上げたリスクを以下のように対処することができます。

SBOMを導入していない場合 SBOMを導入している場合
脆弱性の発見が遅れ、初動対応が遅れてしまう SBOMを管理するツールを用いて新たな脆弱性をリアルタイムで検出、初動対応期間を短縮する
脆弱性の発生に気付かず、脆弱性が残留してしまう ツールを用いて、脆弱性情報とSBOMの情報を突合し、脆弱性を検出することで脆弱性が残留するリスクを低減する
部品表を手動で管理するため管理コストがかかる ツールを用いた自動管理で管理コストを削減する

SBOMを導入することで上記のようなメリットがあるため、昨今では、サプライチェーン全体で脆弱性管理を行うために、SBOMを活用する動きが広がりつつあります。

SBOMツール

実際にSBOMを活用する場合、ツールによってSBOMの作成や更新、脆弱性の発見や管理を行うことが現状ではスタンダードです。ソフトウェア製品のコンポーネントを読み取り、自動で最新の情報を取得、脆弱性の管理を行うというものです。

ツールでは主に次のことができます。ただし、ツールによっては以下の機能をすべて備えていないものもあります。

機能 詳細
構成解析 主にOSSの検出などを機械的に(ファイルやバイナリ、スニペット解析等)行い、部品を特定します。 ツールによって対応している解析方法が異なり、性能が良い(金額も高価ですが)なものほどバイナリやスニペットなど難しい解析も可能です。
SBOMの生成、入出力 解析した部品をSBOMの各フォーマットへ出力します。 こちらも、ツールによって対応しているフォーマットが異なります。
脆弱性管理 SBOMの各部品について、定常監視、手動によるスキャニング、アラートとして通知などを行い、脆弱性をいち早く発見することが可能です。 もちろん、これらは脆弱性管理の運用体制を構築した上で、稼働させないと意味がありません。
ライセンス管理 SBOMの各部品に含まれるOSSのライセンス情報を特定し、ライセンスの有効期限が切れていれば通知するなどができます。

主に上記のことがSBOMツールによって対応出来ますが、ここで最も重要なことは「手動ではなく自動でできる」という点です。 今までコンポートネント(部品)管理の特定を手動でやっている場合、それらの脆弱性有無を定常的に監視し、発見した場合対応することは非常に困難でした。 ですが、SBOMが登場したことで、ツールによる管理、運用が可能となり、今まで以上にセキュアなソフトウェア開発・運用を行うことが可能となる道が見えてきています。

SBOMの課題

このように非常に便利そうに見えるSBOMですが、まだまだ課題も多く存在します。 ここでは、現状、SBOMを導入する上で考えられる課題を挙げます。

①導入工数やコスト

SBOMツールを導入する場合、ツール自体のコスト負担が新たに発生します。 それだけでなく、サプライチェーン全体での運用管理を考えなければいけません。 それらの運用設計、体制作りなど、サプライチェーンの規模が大きいほど複雑かつ、利害関係など調整要素も多く、コストがかかります。

さらに、見え辛い点として、学習コストがあります。 SBOMという新しい仕組みを理解し、活用するための勉強やPoCがかかります。 また、こういった仕組みを導入する際、サプライチェーン内の企業によっては、そもそもソフトウェアの構成管理自体きちんと行っていない可能性もあり、そういったところへ導入するには、そもそもである構成管理の学習も必要となります。

②ソフトウェア製品の部品をどこまでSBOMで管理すべきか明確な指標がない

冒頭で「SBOMは部品表」という説明をしましたが、製品に関わる全ての部品を100%網羅しようとすると、開発委託先含め、部品の全てをソースコードレベルでレビューすることが必要となってしまいます。 それを行うと、サプライチェーン全体で製品開発していたことを内製化して行うのとほとんど変わらず、莫大なコストがかかってしまいます。 従って、部品を100%完全網羅することは現実的でなく、ある程度の部品を特定する範囲を限定し、できるところから対応することが必要です。

一方、SBOMは新しい仕組みであるため、導入や運用に関するノウハウがなく、ソフトウェア製品の部品をどこまで分解し、SBOMとして管理するか明確な指標がなく、各企業、手探りの状況です。

③ツール性能が不十分

SBOMツールについても、現状では足りないところがあります。 例えば、該当のツールを利用してSBOMは作成できるが、同じフォーマットでも他所で作成したSBOMをそのツールでは読み込めないといった事があります。 そうなると、サプライチェーンでSBOMを管理することはできません。

また、部品の検出精度もツールによってまちまちであり、結局ツールが検出したものが正しいかどうか手動で確認しなければいけない、といった本末転倒な事が起こる可能性すらあり、ユーザ側としてはまだまだ扱い辛い部分が多いです。

普及について

正直、SBOMの普及についてはまだまだこれからと考えています。主に、以下のような状況が普及に至っていない理由だと私は考えています。

SBOMフォーマットがバラバラ

SBOMにはフォーマットが複数あり、それを採用しているところは業界や会社ごとに違っている場合があります。画一的な規格がないまま、複数のフォーマットを使おうとすると、SBOMツールの対応が追い付かない、会社同士でのSBOMのやり取りができない、といった事が起き、SBOMの普及促進の妨げになります。

ベストプラクティスや事例が少ない

やはり新しい領域ということで、まだ大手含めて手探りの状況です。中小企業ではSBOMという単語を知らない方も大勢いらっしゃるはずです。このあたりは、各社の取り組みを通じて事例やノウハウを蓄積し、導入しやすい環境整備が必要と考えます。

世界の普及状況

ちなみに、グローバルで見ると、やはり米国は国を挙げてSBOMを普及させるよう、政府機関がSBOMに関するガイダンス等をリリースし進めているようです。 日本も、日本政府や、各業界団体含めSBOMの普及促進に取り組めると良いと思います。

まとめ

いかがでしたでしょうか。SBOMの概要やメリット、そして現状の課題や普及に関して理解が進むと幸いです。

記事一覧に戻る