ベリサーブ、SBOM構築・運用サービス「SBOM.JP」を発表–製造業向けに
今回は「ベリサーブ、SBOM構築・運用サービス「SBOM.JP」を発表–製造業向けに」についてご紹介します。
関連ワード （製造 x IT等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
ベリサーブは9月6日、ソフトウェア部品表（SBOM）の構築や運用を行うSaaS「SBOM.JP」を10月から製造業向けに提供すると発表した。サプライチェーンのセキュリティ強化を支援する。
SBOMは、ソフトウェア製品で使用しているコードやライブラリー、コンポーネントなどの種類やバージョン、提供元、依存関係といった構成の状態を記録したもの。近年は、ソフトウェアを構成するこれらの要素に含まれる脆弱（ぜいじゃく）性などを悪用するサイバー攻撃が増加し、ソフトウェア製品を利用しているさまざまな企業や組織にとってリスクとなっている。
現在のソフトウェア製品の構成は非常に複雑で、開発元では有償、無償、オープンソースといった多様なコードやライブラリー、コンポーネントなどを組み合わせて製品として開発しているが、セキュリティリスクの高まりを背景に、その構成状態をSBOMで管理することが要請されている。SBOMを活用すれば、突発的な脆弱性問題などが発覚しても、開発元がSBOMを確認して自社製品に影響が及ぶのかどうかや、影響が及ぶ場合の対応計画などを迅速的、適切に実施できることが期待される。
ベリサーブは、20年以上にわたってソフトウェア製品のテストや品質保証のサービスを手掛ける。SBOM.JPの発表に合わせて開催したセミナーで、執行役員 サイバーセキュリティ事業部長の桑野修氏は、「特に自動車や医療機器などの製造業では、国内外でサイバーセキュリティやレジリエンスの強化がテーマとなっている。当社は、製品のセキュリティ課題に対応するP-SIRT（製品セキュリティ対応チーム）活動にも長年取り組んでおり、これまでの経験を生かして新たなセキュリティサービスを展開する」と述べた。
セミナーでは、大阪大学の最高情報セキュリティ責任者（CISO）など務める大学院情報科学研究科の猪俣敦夫教授がゲストとして登壇し、SBOMが必要とされる背景などを講演。また、ベリサーブ サイバーセキュリティ事業部 脆弱性マネジメント課の藤原洋平氏がSBOMの国内外の動向を紹介した。
猪俣教授は、SBOMの意義について、食料品の原材料表示を例に説明している。原材料表示には、その食料品の製造に使用された原材料の種類や名称などのほか、使用状況や健康への影響なども記載され、消費者は購入前に確認することできる。
SBOMも同様で、ソフトウェア製品の開発元が自社製品の状態を把握、管理することに加え、ソフトウェア製品を利用する側もSBOMの情報が共有されていれば、脆弱性問題などが発生した場合に、自組織への影響や開発元の対応状況などを迅速に確認できるようになるとした。
藤原氏によれば、海外では、米国の大統領令や欧州連合（EU）の「サイバーセキュリティ法」などでソフトウェア開発元にSBOMの対応が義務化される流れにあり、各種の標準や規則の整備が進む。国内では、経済産業省が2023年7月にSBOM導入のガイドラインを公開し、2024年8月にはその改訂版でSBOMを活用する内容が追加された。また、厚生労働省でも医療機器におけるSBOM対応のガイドラインの整備を推進しており、それらを踏まえて自動車や医療、通信といった分野でSBOMの普及に向けた活動が展開されている状況だ。
猪俣教授は、「ソフトウェア製品の構成情報は開発元の機密事項で、これまで共有されることはなかった。SBOMの重要性が高まり活用に向けた環境整備が進むのは大きな前進。SBOMは技術情報という以上に、デューデリジェンスや品質保証として信頼につながる存在になる」と指摘した。
新サービスのSBOM.JPについて、ベリサーブ サイバーセキュリティ事業部 技術開発課の平山雅弘氏は、特にソフトウェア製品のサプライチェーンにおける脆弱性管理に焦点を当てていると説明した。
上述のようにソフトウェア製品の内部は、さまざまなコードやライブラリー、コンポーネントなどが複雑に構成され、開発元ではそれらの多くを外部からも調達している。外部調達したそれらの構成品に脆弱性が見つかれば、調達元の対応状況を確認しなければならず、調達元が修正などのサポートを行わない事態もある。さらに自社が開発したソフトウェアを別のソフトウェアベンダーに供給していれば、脆弱性などの問題の影響はさらに広がりかねない。
手作業で後から複雑な構成のソフトウェア内部状態を正確かつ迅速に把握することは非常に困難なため、開発段階からSBOMを活用していくことが望ましいとされる。脆弱性などの問題は、製品リリース後にも起こり得るため、ソフトウェア製品のライフサイクル全体でSBOMを利用できる体制が必要になる。
平山氏は、「ソフトウェアの構成要素が複雑であるだけでなく、同じ構成要素であっても多数のバージョンが存在するなど、その管理がとても難しい」とし、SBOMでは、ソフトウェアに使用した構成要素の種類だけでなく、いつの時点のバージョンを使用したのかなど時間軸の記録も含めて開発の過程をトレースできるようにしておくことが肝心だという。
このためSBOM.JPでは、APIも活用して、ソフトウェア開発元のSBOMや外部開発のSBOM、脆弱性情報データベースと連携し、ソフトウェア内部の構成要素のバージョンアップいった情報を更新しながら管理していける。脆弱性問題などが発生した場合は、SBOMの情報をトレースして、構成要素を横断した影響範囲の把握や過去の履歴などを迅速に確認できるという。また、生成AI機能を搭載し、日々更新される最新の脆弱性情報を基に自社SBOMとの照合作業を効率化したり、特殊な用語などを管理者が分かりやすい形に表現したりするなど、ユーザーを支援する。
SBOMの作成については、標準フォーマットとして「SPDX」や「CycloneDX」などがあり、GitHubがリポジトリーからワンクリック操作でSBOMを生成できる「Export SBOM」機能を提供するなど容易に対応できる環境が整ってきている。
平山氏は、「現在のソリューションでは、SBOMの構築を主眼にしたものや脆弱性管理にSBOM作成機能を付加したものが多く、SBOM.JPはSBOMの運用をメインにしている。当社の経験を生かして顧客が運用で使いやすい機能を実現している」と説明した。