Google の視点:SBOM を適切に機能させるには脆弱性情報とのマッピングが不可欠

Google: SBOMs Effective Only if They Map to Known Vulns

2022/06/15 DarkReading — Software bills of materials (SBOMs) は、製品を構築するために使用されるコンポーネント/モジュール/ライブラリの詳細なリストであり、消費者のためのサプライチェーンにおけるサイバー・セキュリティ・リスクを低減する方法として、National Institute of Standards and Technology (NIST) や米国の規制当局により支持されている

しかし、Google の Open Source Security Team は、SBOM を使用するだけでは弱点の露出を評価するための有効なツールにはならないと、今日のブログ投稿で指摘している。むしろ、既知のソフトウェアの欠陥を特定するためには、既知の脆弱性に関するデータベースとドキュメントを比較する必要がある。この研究チームは、「この2つの情報源を結びつけることで、消費者は自分のソフトウェアに何が入っているかだけではなく、そのリスクや問題を修正する必要があるかどうかも知ることができる」と説明している。


Google のアナリストたちは、Open Source Vulnerabilities (OSV) データベースを用いて、Kubernetes SBOM ドキュメントをマッピングした方法を詳述している。OSV データベースは、Github Advisory Database (GHSA) や Global Security Database (GSD) を含む、複数のデータベース間での比較の標準化されたフォーマットと、Python/Golang/Rust といった複数のエコシステムにまたがる、集約されたデータの両方を提供していると述べている。

彼らは、「私たちの事例では OSV データベースを照会したが、近いうちに SBOM データと脆弱性データベースにマッピングし、さらには対象となるソフトウェアの脆弱性の緩和などに関する追加のコンテキストを、提供する VEX (Vulnerability-Exploitability eXchange) などの新しい標準を用いて、同様の成功を収めるだろう」とブログに書いている。

Google の研究者たちは、「セキュリティ・チームがリスクの全体像を評価しやすくするために、SBOM の作成者がソフトウェアのサプライチェーン内の全てのパッケージに対して、Purl URL のような命名規則によるリファレンスを取り込むよう推奨する。このタイプの識別スキームは、エコシステムを特定すると同時に、パッケージの識別を容易にする」と述べている。

SBOM の進化

Google のセキュリティ・ブログには、「ソフトウェア・コンポーネントと既知の欠陥を結合するステップにおいて、SBOM の本来の目的である、サイバー攻撃の可能性の管理が推進される。SBOM の普及とツールの改良という道を歩み続けることで、近い将来には、あらゆるソフトウェアの SBOM を要求してダウンロードできるようになる。それに加えて、消費者が使用する、あらゆるソフトウェアに影響を及ぼす脆弱性を理解するために、SBOM を利用できるようになることを期待している」と述べている。

現時点において、SBOM に対して、一番熱心に取り組んでいるのは Google かもしれません。この記事にあるように、SBOM だけで問題が解決するものではありません。それそれのソフトウェア・コンポーネントが、SBOM 部品表を持っていたとしても、対象となるコンポーネントのロケーションが不明では、何も前進しません。よろしければ、2022年1月の、「Log4j が明らかにしたもの:ソフトウェアの依存関係と SBoM のすすめ」を、ご参照ください。

%d bloggers like this: