なぜSBOMが必要か 　

食品のパッケージを手にとると、その裏に原料や成分について詳しく書かれた表を見ることが出来ます。これは多くの事件（偽食品事件、違法な添加物、原産地偽装事件など）を経て記載されるようになった経緯があります（図1）。

図1　消費者庁食品表示課「表示することとなった理由・経過について」

ソフトウェアも同様にいくつもの事件を経て、構成表つまりSBOMによる管理の有効性が検討されるようになりました。

OSS（オープンソースソフトウェア）

この動きの背景にはOSSの普及があります。OSSとはソフトウェアの開発や配布において、ソースコードが公開され、自由に利用、変更、再配布ができるライセンスの下で提供されるソフトウェアのことを指します。

インターネットが普及する以前では、ほとんどの商用ソフトウェアのソースコードは公開せず、自社または委託先で閉じており、新機能の追加や改良には組織内での対応が必要でした。

その後Webやネットワークの新しい技術が生まれ、次々と誰でも利用できるOSSとして公開されるようになり、下記のような点から急速に普及するようになりました。

• 新しい技術を多くの人に使ってもらえる。技術の標準化
• 公開することで多くの開発者が参加することが出来るため、開発コストの削減
• 誰かがいつも開発に参加しているので、開発速度が向上し、不具合の早期発見にも繋がる
• 活発なコミュニティが在れば、質問やマニュアルなどのサポートも受けることが出来る
　

当初は非商用ソフトウェアから普及しましたが、やがて商用ソフトウェアもOSSで公開されている機能が存在するならば、独自に作成するよりも積極的に利用する動きが生まれてきました。

現在では多くのソフトウェアや機器のファームウェアでOSSが使用されています。例えばGoogleやAmazonのサービス、LinuxではOS自身がOSSにより作成されています。

OSSのデメリット

様々なメリットがあるOSSですが、デメリットもあります。ソースコードが公開されているたため、致命的なセキュリティリスクが在る場合、それも広く知れ渡ってしまうということです。

OSSの脆弱性は比較的早く修正されますが、OSSを使用しているソフトウェアがすぐに更新されるわけではありません。悪意を持った攻撃者は、日々脆弱性をチェックし、それを使用していると思われるソフトウェアへの攻撃を試みます。昨今、ニュースになるランサムウェア、情報漏洩事件の多くで、人的な原因ではないものは既知の脆弱性が関係しているのがほとんどと言って良いでしょう。

OSSに起因する事件で話題になったものとして、OpenSSLの脆弱性Heartbleed、Apache Struts2の脆弱性、Javaの脆弱性Log4jがあげられます。いずれもかなりの被害が発生しました。

特にアメリカ政府を動かした事件として、2020年に起きたSolarWinds社のサプライチェーン攻撃があります。政府機関の使用しているソフトウェアも影響を受けており、ソフトウェアに使用されているOSSはなにか、またそれに脆弱性がないかを確認する方法が求められるようになりました。

また、OSSは一定のライセンスの下で管理されており、それに沿った利用が必要です。しかしながら、当初は無償であったものが有償や、商用利用が禁止に変わる場合もあります。ライセンス形態の変更にも注意が必要になります。

各国政府の動き

日本や各国の政府もSBOMによるソフトウェアの管理を求めるようになってきています。

　

• アメリカ ： 2021/5/12にバイデン米大統領が大統領令(EO)14028「国家のサイバーセキュリティの改善に関する大統領令」に署名。SBOMでの管理が記載。
• 日本 ： 2023/3/31に厚生労働省が「医療機関における医療機器のサイバーセキュリティ確保のための手引書」（図2）を発表。医療機器に使用されるソフトウェアのSBOMでの管理を求める。
• 日本 ： 2023/7/23に経済産業省が「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」（図3）を発表。
• EU ： 2024年施行の「欧州サイバーレジリエンス法（EU Cyber Resilience Act：CRA）」にSBOMの要求。

図2　「医療機関における医療機器のサイバーセキュリティ確保のための手引書」より抜粋

図3　「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」概要資料より抜粋

SBOMの作成と利用

SBOMは利用者が作成するものではなく、ソフトウェアの開発元が作成するものになります。SBOMは構成表と呼ばれていますが、一般的に人間が見て分かるような表形式ではなく、国際的に決められた書式に沿って記述されたXMLやJSON形式のファイルです。SBOM生成ツールなどを使用して、ソフトウェアのソースコードや構成ファイルから作成します。

代用的な書式として、SPDX、CycloneDX、SWIDなどがあります。それぞれ特徴がありますが、下記のような最小要素（図4）が求められています。重要な項目にコンポーネントやパッケージ情報、バージョン情報、作成者や公開元の情報、ライセンス情報があります。

図4　SBOMの最小要素

この情報を元に、国内外の脆弱性を取りまとめた脆弱性DB（NVDやJVN）を参照してSBOMに記載されているOSSに脆弱性があるか、すでに修正されているかを確認することが出来ます。

また、DBには脆弱性の内容や深刻度の値が記載されています。それに応じてソフトウェアの更新のタイミングを計画することが可能です。

フォーラムエイトの取り組み

フォーラムエイトの主製品であるUC-1シリーズは発売当初から自社開発を行っており、時代ともにWeb認証、UC-1 Cloudと進化を続けていますが、製品の中核的な機能にはOSSは使用されていません。しかし、Webに関する機能やCloudではOSSを使用している部品もあります。

そのため、フォーラムエイトではSBOMを作成し、脆弱性の確認、管理を行うツールを作成しました（図5）。このツールの作成にもOSSが使われています。作成したツールを使ってそのツールのSBOMを作成したところ、図5の例では5つの脆弱性があるという状態を確認することが出来ます。日々新しい脆弱性が発見されるため、定期的に確認し、それに基づいてソフトウェアの更新を計画して、脆弱性がない状態を維持するというサイクルが必要になります。

フォーラムエイトではこのような取り組みを行い安全なソフトウェアを提供できるように努めております。

図5　SBOM管理サイト