ソフトウェアサプライチェーンセキュリティを「品質」で読み解く：ソフトウェアサプライチェーンの守り方（3）（1/4 ページ）

米国と欧州を中心に法整備が進みつつある「ソフトウェアサプライチェーン」のセキュリティについて解説する本連載。最終回となる第3回は、SBOMの流通によってどんな「良いこと」と「悪いこと」が起こるかを整理しつつ、品質保証の枠組みへの取り込みについても考察する。

[松岡 正人，MONOist]

　前回の記事では、日本でも先行してソフトウェアサプライチェーンセキュリティ向上のため、医療、自動車などの規制業種や政府調達でSBOM（ソフトウェア部品表）の導入が始まりつつあることについて述べた。

　今回は本連載の最終回として、どのようにSBOMが流通することが想定され、ソフトウェア開発者と運用者、利用者にとってどんな「良いこと」があるのか、またどのような「具合の悪いこと」が想定されるのかについても整理しつつ、最後に「品質」という観点からどのように従来の品質保証の枠組みに取り込むことができるかについても考察したいと思う。

⇒連載「ソフトウェアサプライチェーンの守り方」バックナンバー

SBOMで変わるソフトウェアの流通モデル

　まず、SBOMの流通モデルを簡単な図に落としてみよう。

　みなさんの利用しているソフトウェアは、PCの中で動作しているソフトウェアではなく、自宅にあるエアコンやテレビを動かすためのソフトウェアかもしれないし、銀行のATMや、ハンバーガーショップのPOS端末、配送業者の配達員が持つ携帯端末といった業務用のソフトウェア、はたまたスマートフォンにインストールするEコマースやフードデリバリーの専用アプリかもしれない。これらの品質やセキュリティの良しあしの影響を被るのは、利用者や、それらのソフトウェアを使ってサービスを提供する企業や組織ということになるだろう。

　それでは、SBOMを用いたサプライチェーンセキュリティの導入によって、どのようにソフトウェアの扱いが変わるのだろうか。従来のソフトウェアの流通モデルは図1のようなものだった。

図1　従来のソフトウェアの流通モデル

　まず、開発者は自分が利用する商用ソフトウェアにどんなソフトウェアが含まれているのかが分からないし、開発されたソフトウェアの利用者は、提供されるソフトウェアに何が含まれているのかが全く分からない。

　従って、開発者はオープンソースソフトウェア（OSS）や、使用している商用ソフトウェアの脆弱性情報を個別に取得し、あるいは自前のコードに脆弱性を発見してこれらを修正するため、自分達が開発／提供しているソフトウェアのためのセキュリティアップデートを開発、検証して提供することになる（図2）。しかし、運用者や利用者は、開発者からセキュリティアップデートやパッチが提供されるまで、利用中のソフトウェアにどんな脆弱性が発見されたのかが分からないことに変わりはない。

図2　従来のソフトウェアの流通モデルで脆弱性が発見され、パッチが提供された場合

　つまり、従来のITおよびソフトウェアの調達では、「開発者が脆弱性とその影響に対する対処を一手に担っている」ということになる。

　しかし、SBOMを流通させることで脆弱性の情報を利用者も速やかに得ることが可能になり、また、開発者もサードパーティーが開発した商用ソフトウェアのSBOMを入手することができるようになるので、サプライチェーン全体での可視性が高まるというわけだ（図3）。

図3　SBOMを用いることで、脆弱性情報を運用者や利用者も速やかに得られる

　一方で、従来のITおよびソフトウェアの調達と異なり、運用者や利用者（サードパーティーの商用ソフトウェアなどを使用している開発者も同様）も脆弱性とその影響に対する対処に対して責務を追うことになる。これはSBOMを流通させることによって脆弱性に対するサプライチェーン全体での「感度」が上がるという「良いこと」とセットで起こる、「具合の悪いこと」といえるだろう。