重要
年末年始休業 2023年12月29日～2024年1月3日
2023年7月、経済産業省がニュースリリースを発表しました。
経済産業省では、年々高まるサプライチェーンのセキュリティリスクに対応するため、サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォースを発足させ、その中でSBOMの導入を見据えた産業分野毎の実証実験を進めるなどの施策を行っていましたが、その成果が公開された、といえます。
今後、SBOMは企業のリスク管理に広く関わってくる可能性がありますが、どのようなものか、どのように使うとよいのか、といったことに関しては様々な見解があり、セキュリティリスクに対応するべき部門には混乱も見受けられます。
そこで今回は、SBOMがなぜいま注目されているのか、そしてSBOMがどのようなものなのかを考察したのち、SBOMの効果として一部で期待されているリスク管理は、本来どのようなものかを解説してみることにします。
SBOM（Software Bill of Materials）は「ソフトウェア部品表」とも言われ、あるシステムに含まれるソフトウェアコンポーネントと、それらの依存関係の情報も含めた機械処理可能な一覧データを指します。詳しくは、経済産業省『ソフトウェア管理に向けた SBOM（Software Bill of Materials）の導入に関する 手引 Ver. 1.0』8ページ〜10ページにおいて簡易的なシナリオと図解を用いて説明されていますのでご覧ください。
さて、SBOMが注目される背景にはいくつかありますが、大きく分けると以下の2つが挙げられます。
オープンソースソフトウェア（OSS）が普及し、ソフトウェアの依存関係が膨大かつ複雑になったことで、システムに含まれるソフトウェアのすべてを把握することは困難になりました。
そこで、機械処理可能な共通規格としてのソフトウェアコンポーネント管理が求められるようになりました。
ソフトウェアサプライチェーンが巨大化したということは、システムの中に脆弱なソフトウェアコンポーネントが含まれる確率も上がったということです。これにより、サイバー攻撃が成功する確率も上がり、サイバー攻撃がビジネスとして成立する要因のひとつとなりました。
システムの中に含まれる脆弱なソフトウェアコンポーネントへの攻撃は、年々増加しています。IPA（独立行政法人 情報処理推進機構）が毎年発表している『情報セキュリティ10大脅威』によると、「脆弱性対策の公開に伴う悪用増加」は2021年から登場し、2021年は10位、2022年は6位、2023年は8位と、定番の脅威として定着しつつあります。
国内外のセキュリティ基準にも、このような世の趨勢は反映されるようになりました。
まず、重要な転機となったのは、アメリカで2021年5月に発出された大統領令EO14028です。大統領令EO14028では、連邦政府と契約する情報通信サービス企業に対する情報共有の内容が示されていて、その中にはサプライチェーンのセキュリティのためにソフトウエアに関して事業者が順守すべき事項としてソフトウエアの構成要素に関する詳細を提供することが含まれていますが、これはSBOM（Software Bill of Materials）の提供を指します。
また、2022年にリリースされ、近い将来に対応各社の移行が必須となるクレジットカード業界のグローバルセキュリティ基準PCI DSS v4.0では「特注ソフトウェア及びカスタムソフトウェアのリスト（インベントリ）維持」という要件が新設されました。これはソフトウェアコンポーネント管理の義務化を意味しています。そして、共通規格に則ることで審査対応を省力化・迅速化する手段として、SBOMが注目されているのです。
このほかにも、国際的には、たとえばQUAD（日米豪印戦略対話）の共同原則で「デジタル対応の製品・サービスのサプライチェーンにおける潜在的リスクを特定・評価すること」が求められるようになる、国内ではQUADの共同原則を受ける形で経済産業省が「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を発表するなど、共通規格に準拠したソフトウェアコンポーネント管理がサービスの調達基準に組み込まれつつあります。
SBOMはどのようなもので、どんなことに使えるのでしょうか。
NTIA（米国商務省電気通信情報局）が『The Minimum Elements For a Software Bill of Materials (SBOM)』で明示したSBOMの最小構成要素は、Data Fields（提供元・名称・バージョン・依存関係・脆弱性・ライセンスなど）・Automation Support（自動化対応）・Practices and Processes（運用）です。
したがって、コンポーネントの開発元・名称・バージョン・依存関係・脆弱性・ライセンス等の情報が含まれ、組織を越えて相互共有できるようにするための機械処理・運用が可能であるデータであることが、SBOMの一般的な要件です。
そこで、リスク管理の観点からSBOMの用途を考えたとき、以下の2つが有望といえます。
しかし、SBOMは「ソフトウェア部品表」というだけあって、その取り扱いには相当の注意を要します。なぜなら、SBOMが他者の手に渡れば、対象のソフトウェアについての情報が丸わかりだからです。SBOMは、それ自体の機密性が高いのです。
また、SBOMは、その内容を作成する提供側と、その内容を評価する評価側がいます。そして、提供側がどのようなソフトウェアを作っているかによっても、SBOMというものの捉え方は異なります。
そのため、サプライチェーン全体でSBOMの活用を考えようとすると、提供側と評価側、それぞれの立ち位置によって、開示の重要度や対応難易度に差が生まれることが想像できます。例えばSIerのように特定の顧客に特化したシステムを納入する立場の場合はSBOM提供への抵抗感が薄いのに対し、クラウドサービス事業者にとってのSBOM提供は、営業秘密をまるごと提供することにも相当しますから、積極的に対応しないこともあるでしょう。
また、サプライチェーンのリスク管理に活用すべくSBOMを提供してもらえたとしても、クラウドサービスのように頻繁に更新が行われるようなソフトウェアでは、チェックすること自体が非常に手間になります。しかも、前述の通り、SBOMはライセンス違反や脆弱性を検出することはできますが、たとえば検出されたリスク群を、どれから、どのように、いつまでに対応するのかといったことの判断に直接使うことはできません。ですから、SBOMの提供は受けたものの活用されないということはあり得ますし、逆に、SBOMで検出されたリスク群すべてに対応しようとした場合、コンポーネント間の不整合による不具合が発生した結果品質低下を招く、という別のリスクを招くことにもつながりかねません。
PCI DSS対応が必要な金融関連の企業や、一度リリースするとあとからの修正が極めて困難なIoT製品を扱う業界、脆弱性によるシステムダウンがサプライチェーンに大きな損失を与える企業の場合、業界や企業としてSBOM対応が必要、あるいはこれから必要となる確率が高い企業群はあります。しかし、弊社で見聞きした範囲内でも、そのような企業でもSBOMの扱い方については情報も関連ソリューションも不足している、といった声を聞くことがあります。
SBOMを取り巻く現状は、前述の通り、SBOMが関連する国内外の要求事項はある程度出てきましたが、SBOMの扱い方については情報も関連ソリューションも不足している、といったところです。おそらく、今後数年かけて、ベストプラクティスや関連ソリューションが出揃う段階になるでしょう。直近では、PCI DSS v4.0対応の一環として2025年3月までのSBOM対応が必要になります。将来的にはSBOMのやりとりがサプライチェーンで当たり前になる時代が来るかもしれません。しかし、それはいまこの瞬間では少し先の未来です。その前にできることとして、リスク管理の設計と運用の見直しが課題となるはずです。
リスク管理体制がしっかりと定まっていない場合もあれば、体制はあっても運用が回っていない場合もあります。手作業中心のワークフローで、担当者の頑張りで運用が回ってはいるものの、PDCAサイクルを回すまでには至っていないというケースもあります。
幸いにして、リスク管理体制の設計・運用を支援するソリューションは、弊社のConorisを含めていくつかあります。
リスク管理の設計と運用の見直しという課題を解決する中で、収集したSBOMをどのようにリスク管理に使うのかという疑問が湧いてくるかもしれません。しかし、リスク管理が目指すところは、ソフトウェアの一覧があるかどうかではなく、リスクの一覧があって、それぞれのリスクに対して適切な対策が施されているかどうかが見える状態です。
また、業界や国内外の行政からの要求がない場合、クラウドサービス事業者のように営業秘密をまるごと提供することにも相当するSBOMの提供は受け入れ難い、と考える取引先があらわれるかもしれません。
リスク管理の一環としてのソフトウェアセキュリティ対応で本当に必要なのは、ソフトウェアの脆弱性の管理と対応ができているかどうかを確かめることです。そして、そのエビデンスを作るベストプラクティスやソリューションはすでに多数あります。先月紹介したSSVCのブログ記事も、ソフトウェアの脆弱性の管理と対応を示す方法として使えます。また、Snykなどのソリューションを活用することも有効です。
近い将来、SBOMのベストプラクティスやSBOMを扱うソリューションが出揃うことが想定されます。そのときに改めて、リスク管理の一環としてのSBOM活用のコスト対メリットを計算することはできます。SBOMは非常に機密性の高いデータであるため、セキュリティ面も含めて、慎重にコストを計算する必要があります。その上で、十分にメリットがあると判断できるならば、SBOMを活用するフェーズに入れるということになります。
弊社で提供をしているベンダーリスクマネジメントツール「Conoris」の場合、クラウドサービスやそれ以外のシステムの提供事業者・委託先など幅広いステークホルダーに対して、指定のワークフローでの情報の回収・管理が可能です。
回収データを用いて、自社で利用しているプロダクトやサービスのマスタ管理やシステム開発を外注している委託先・再委託先などの一覧化することもできるので、SBOM対応の前段として必要となる、提出対象の管理と承認ワークフローの整備ができますので、ご興味がありましたら、是非お問い合わせください。
SBOMは、ソフトウェアサプライチェーンの巨大化と国内外のセキュリティ基準による要求の高まりから、現在注目が集まっています。また、一部の業界ではリスク管理の一環としてSBOMによるリスク検出が必要になりつつあります。
一方で、SBOMを活用するベストプラクティスやソリューションは未発展です。また、SBOMは非常に多くの秘匿情報をかかえるデータとなることから、無秩序にSBOMを活用することで運用コストの不必要な増大や機密性の欠如につながるなど別のリスクもあります。
近い将来、SBOMに関するベストプラクティスや関連ソリューションが出揃うことや、SBOM対応が義務になることは予想されますが、リスク管理の設計と運用を見直すこと自社のリスク管理をよりよいものにしていくことがその前段階として重要で、SBOMへの注目はそのためのよい機会としてとらえるとよいでしょう。
