SBOMの作成・活用は目標・目的・手段の整理から始まる

　「日本のセキュリティは2極化している。（生命を預かる）病院がVPN（仮想私設網）機器の脆弱性を突かれランサムウェアによる被害を受けるなど、国内のセキュリティ水準はそのレベルにあるのが現実だ。だが、自動車や重要インフラの領域では高度なセキュリティへの対応が不可欠になってきている」――。ソフトウェア協会 理事の萩原 健太 氏は、こう指摘する（写真1）。同氏は、ソフトウェア協会が設立した「Software ISAC（Information Sharing and Analysis Center）」の共同代表も務める。

写真1：ソフトウェア協会 理事／Software ISAC 共同代表の萩原 健太 氏

　そうした中で期待が高まるのが「SBOM（Software Bill of Materials：ソフトウェア部品構成表）」の活用である。しかし萩原氏は、「SBOMの導入に向けては“目標”“目的”“手段”が入り交じっているのが現状だ」と指摘する。「SBOMを導入したいという声は増えているが、『なぜ作りたいのか』『どう作りたいのか』が全く見えてこないケースが多い」（同）という。

　例えばSBOMには複数のフォーマットがある。萩原氏によれば、「現状のフォーマットは、セキュリティ視点で作られた『CycloneDX』、ガバナンス視点で作られた『SPDX』などが存在し、目的や目標を考えれば形式の議論が深められる」。ただ実際は、「SBOM導入が目的化しており、最初から『どちらのフォーマットが良いですか』という話になりがちだ」と萩原氏は嘆息する。

直接的な利益を生まないSBOMへの経営者の理解が重要

　SBOMの導入に当たって萩原氏は、「“目標”“目的”“手段”をきちんと整理することが重要であり、それがスタートラインになる」と強調する。目標、目的、手段とは、例えば以下のようなものである。

目標 ：組織で利用しているソフトウェアをすべて継続的に管理する
目的 ：安全なソフトウェアを利用し、安心を提供する
手段 ：「PSIRC（Product Security Incident Response Capability）といったセキュリティ組織がSBOMなどのソフトウェア管理を運用する

　そのうえで萩原氏は、「SBOMを議論する際には、SBOMに対するモチベーションがどこにあるかの理解も重要だ」と付け加える。「インセンティブやモチベーションの持たせ方を明確にしないとSBOMは浸透しないと考えている。SBOM自体は、それを作っても利益が上がるわけではなく経営者の納得は得がたい」（同）からだ。

　経営者が納得しない状況では、上流の取引先から「SBOMを作ってくれ」と頼まれて対応するケースが多くなる。だが萩原氏は「現場任せでは対応が遅くなる」と指摘する。「現場は『NIST SP800-218（Secure Software Development Framework：SSDF）フレームワーク』を手元に置いて、組織の準備やソフトウェアの保護、安全なソフトウェアの開発、脆弱性への対応など、多くの準備が必要なことを経営者に働きかけなければならない」(同)のが、その理由である。

　SBOMは、「米国大統領令(Executive Order)」に端を発し、その導入が推進されてきた。欧州では現在、「欧州サイバーレジリエンス法案（EU Cyber Resilience Act：CRA）」を審議中で「CRAが成立すると欧州で事業展開している会社にとってはSBOMが死活問題になる」と萩原氏は強調する。

　日本では、経済産業省が2023年7月に『ソフトウェア管理に向けたSBOMの導入に関する手引きVer 1.0』を公開、厚生労働省は2023年4月に「医療機関における医療機器のサイバーセキュリティ確保のための手引書」を公開している。ただ萩原氏は、「欧米と比べ日本はガイドラインにとどまっている。SBOMの普及に向けては業界が団結して推進する必要もある」と指摘する。