SBOM を構築して活用する：そのための第一歩について考え始めよう

Building a Better SBOM

2023/04/25 DarkReading — この 2023年という年において、すべてのビジネスにおける重要な役割を、ソフトウェアは担っている。そして、ソフトウェアの構築／導入に携わる組織は、ソフトウェア・サプライチェーンの弱点について、潜在的な攻撃者よりも多くを知ることが絶対的に重要となる。将来における SBOM (software bills of materials) の有用性は、標準に準拠すること、コードベース全体を考慮することに加えて、企業規模での相互運用性を可能にする能力を高めることに掛かっている。

SBOM を作成することは、比較的に簡単なことである。しかし、標準仕様に準拠し、企業が大規模に相互運用できるような、包括的で正確な SBOM を生成することは困難である。そのため、私は、Full Monty SBOM という言葉を作り、セキュリティ／法律／運用の目的において、将来的に必要とされるコンテンツと相互運用性を提供する、包括的な SBOM ソリューションを表現するようにした。このような包括性を欠く SBOM は、無効なセキュリティや、運用上の曖昧な仮定につながる可能性がある。

標準化

SBOMを普遍的に交換し、自動的に読み取るためには、その交換形式が標準仕様に適合している必要がある。

業界では、SPDX と CycloneDX という２つの標準に収束し始めている。これらの標準の目的は、２つの異なる SBOM 生成ツールを用いて、同じソフトウェアの SBOM を生成した場合に、同じ結果を生成するよう、出力に統一性を確立することにある。これらのフォーマットは、ライセンス／著作権／脆弱性などの特定の情報を含む／含まない、または、リンクする／リンクしないとように、使用ケースや業界垂直ベクターに応じて調整できる。

SPDX と CycloneDX は、SBOMファイルの構造を記述する規格に過ぎないことに、注意することが重要となる。つまり、それらは正確性や包括性に対処するものではない。つまり、SBOM 生成プロセス／ツールが、ファイルにゴミを送り込むと、きれいにフォーマットされたゴミが出力される。

包括性

大半のソフトウェア・アプリケーションにおける最大の攻撃対象は、オープンソース・コンポーネントで構成されている。このようなケースは、平均的なソフトウェア・アプリケーションの 76％ を占め、それらのコンポーネントは、世界中に偏在する個人により開発されてい。Log4j は、単一のオープンソース・コンポーネントにおける、単一の脆弱性が、世界的に大きな影響を与える可能性があることを示す例である。ほとんどの組織にとって、ソフトウェア・サプライチェーンを保護し、情報インフラを守るための最優先事項の１つとして挙げられるのは、オープンソース・ソフトウェアの脆弱性を迅速に特定し修正することである。

SBOM は単なるオープンソース・ソフトウェア (OSS) のインベントリであるというのが、多くの人々の率直な感想である。ほとんどの SCA (Software Composition Analysis) ベンダーは、さまざまなレベルの相互依存関係を持つ OSS コンポーネントをリストアップした、ある種の SBOM を作成している。しかし、OSS のみの SBOM では、ソフトウェア・サプライチェーンを構成する他の種類のコードの脆弱性により、組織が危険にさらされる可能性を生み出す。

しかし、Full Monty SBOM で明らかになるアプリケーションの構成要素には、カスタム・コード／オープンソース・コンポーネント／サードパーティ非 OSS コンポーネントなどの、すべてが包含される。脆弱性はオープンソースだけではなく、あらゆる種類のコードに起因する可能性があるため、このことは極めて重要なことになる。

相互運用性

SBOM は静的なドキュメントである。したがって、ソフトウェア・サプライヤーから SBOM を入手しても、それを検査する以外に何もできないのであれば、その価値は限定的となる。本当の価値は、SBOM を使って何ができるのかと考えることだ。具体的に言うと、相互運用性を確保し、パッチ管理や配備リスクの評価といった、他のライフサイクルリスク管理プロセスに組み込むことが可能になることであり、その全てを企業規模で実現することにある。

ここでは、相互運用可能な SBOM を使って、一般的なチームとして実現できる３つのことについて、つまりマージ／クエリ／モニタリングについて見てみていこう。

マージ： 多くの自動車メーカーは、複数の異なるソフトウェア・ベンダーが、異なる標準フォーマットを用いて作成した複数の SBOM を、１つのシステム SBOM へと集約する必要があるだろう。

クエリ： 広く使われているソフトウェア・コンポーネントに、新しいゼロデイ脆弱性が発生したケースを考えてほしい。おそらく、すべての SBOM を照会して、多数のソフトウェア・アプリケーションの何処に、その特定の脆弱なソフトウェア・コンポーネントが含まれているのかを判断する必要が生じる。数千のアプリを抱えていて、１日あたり約 60件の新しい CVE を調べる必要がある場合だと、技術的な困難さが生じる。１つのインターフェイスから、何千もの SBOM を照会できることは、相互運用性と効果的なソフトウェア・リスク管理の重要な要素となる。

モニタリング： 新しいゼロデイ脆弱性が表面化した場合に、その脆弱性について既存の全 SBOM を自動的に検査できると効率が良くなる。続いて、製品ライフサイクル管理システムに対して、そのリスクを通知できるように、相互運用性を考慮した SBOM を使用すると、脅威情報／脆弱性管理システムとの統合が可能になる。

銀の弾丸ではない

Full Monty SBOM は、きわめて重要なものであるが、SSCRM (Software Supply Chain Risk Management) のほんの一部である。その他の要素として挙げられるのは、カスタム・コードや OSS に、セキュリティ上の弱点や既知の脆弱性がないことである。また、規制に準拠したソフトウェアや、安全で改ざんされ難い開発パイプラインなども挙げられる。たとえば、未知の成分を含むクッキーを、二次汚染の可能性がある工場で製造し、衛生規則に違反するような状況で食べることはあり得ないだろう。このように、ソフトウェア・サプライチェーンが、企業にとって安全であることを保証する必要がある。

クッキーであれソフトウェアであれ、製品が安全に消費されることを保証することは、単に SBOM を設置するだけではなく、製造中に行われる多くの安全およびセキュリティ・プロセスや定期的なテストの結果である。

SBOM と言われても、何処から手を付けたら良いのかと、考え込んでしまいますよね。この記事は、標準化／包括性／相互運用性という、３つの柱を建てるところから始めようと主張しています。いまのタイミングで考えられる項目として、分かりやすく整理されていると思えます。どれも簡単ではありませんが、一歩ずつ進めていく必要がありますね。よろしければ、SBOM で検索も、ご利用ください。