SBOM in Action: 「ソフトウェア部品表」で脆弱性を見つける
2022年8月9日火曜日
この記事は Google オープンソース セキュリティ チーム、Brandon Lum、Oliver Chang による Google Security Blog の記事 "SBOM in Action: finding vulnerabilities with a Software Bill of Materials" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
昨年は、ソフトウェア部品表（Software Bills of Materials、SBOM）を採用しようという機運が業界全体で高まりました。SBOM とは、ソフトウェアをビルドするために必要なコンポーネント、ライブラリ、モジュールをすべて列挙したものです。2021 年のサイバーセキュリティに関する米国大統領令を受けて、私たちが使うソフトウェアが何でできているのかを理解する手段として、このソフトウェア部品表が注目されています。基本的な考え方は、他者が作ったものも含め、すべての部品について把握していなければ、特定のソフトウェアに含まれるリスクは判断できないというものです。SBOM への関心の高まりは、米国国立標準技術研究所（NIST）がソフトウェアの SBOM 情報の提供を必須としたセキュア ソフトウェア開発フレームワークを公開したことで、さらに押し上げられることになりました。しかし、業界で SBOM を生成して共有する手法が進展しつつある今、SBOM をどのように活用すればよいのでしょうか。
SBOM を生成するだけでは、まだ道半ばです。あるソフトウェアの SBOM が準備できたら、それを既知の脆弱性リストにマッピングして、脅威を及ぼしかねないのはどのコンポーネントかを確認する必要があります。この 2 つの情報源を結びつけることで、利用者はソフトウェアに含まれているものだけでなく、そのリスクや修正すべき問題があるかどうかも把握できます。
このブログ投稿では、大規模で重要なプロジェクトである Kubernetes から SBOM を取得し、オープンソースのツールを使ってそこに含まれる脆弱性を特定するプロセスを示します。私たちの例の成功は、完全な SBOM が作られるのを待たなくても、SBOM と一般的な脆弱性データベースとのマッピングを始められることを示しています。2 つのデータソースを結びつける際の現在の制限に対処するために SBOM 作成者が少しの更新を行うだけで、このプロセスは、平均的なソフトウェア利用者が簡単に使えるものになります。
OSV: SBOM と脆弱性を結びつける
以下の例では、Kubernetes を取り上げます。大規模プロジェクトである Kubernetes では、SBOM 情報を伝達するためのオープンな国際基準（ISO）である Software Package Data Exchange（SPDX）形式で SBOM が提供されています。SBOM を提供しているすべてのプロジェクトにも、同じ考え方が当てはまるはずです。SBOM を提供していないプロジェクトでは、Kubernetes が作成した同じ bom ツールを使って独自の SBOM を生成できます。
今回は、この SBOM を Open Source Vulnerabilities（OSV）データベースにマッピングすることにしました。このデータベースでは、オープンソース パッケージのバージョンやコミット ハッシュとマッピングできる形式で脆弱性が記述されています。OSV データベースはこの点でも優秀で、標準形式が提供され、複数のエコシステム（Python、Golang、Rust など）やデータベース（Github Advisory Database（GHSA）、Global Security Database（GSD）など）からの情報が集約されています。
SBOM とデータベースを結びつけるために、SPDX の spdx-to-osv ツールを使います。このオープンソース ツールは SPDX の SBOM ドキュメントを受け取り、OSV 脆弱性データベースに照会をし、ソフトウェアで宣言されているコンポーネントに含まれる脆弱性の一覧を返します。
例 : Kubernetes の SBOM
最初の手順は、Kubernetes の SBOM をダウンロードすることです。Kubernetes の SBOM は公開されており、プロジェクト、依存関係、バージョン、ライセンスについての情報が含まれています。次に示す簡単な curl コマンドで、誰でもダウンロードできます。
次の手順では、SPDX の spdx-to-osv ツールを使って Kubernetes の SBOM と OSV データベースを結びつけます。
ツールの出力から、Kubernetes の v1.21.3 には、脆弱性 CVE-2020-26160 があることがわかります。この情報は、このソフトウェアを運用するリスクを管理するために追加のアクションが必要かどうかを判断する際に役立つ可能性があります。たとえば、ある組織が Kubernetes の v1.21.3 を使っている場合、会社のポリシーに基づいてデプロイされたソフトウェアを更新するという対策をとることが考えられます。そうすれば、この脆弱性を悪用した攻撃から組織を守ることができます。
SBOM ツールの改善提案
spdx-to-osv ツールを動作させるには、いくつかの小さな変更を行い、SBOM が提供する情報のあいまいさを排除する必要がありました。
SBOM の当初の目的である「ソフトウェアの脆弱性リスク管理を支援する」が実現されつつあることは明らかです。今回の例では OSV データベースを照会しましたが、近いうちに、他の脆弱性データベースに SBOM データをマッピングしたり、VEX などの新しい標準を使ったりすることもできるようになるでしょう。VEX では、ソフトウェアの脆弱性が軽減されているかどうかについての追加情報が提供されます。
SBOM の採用が広がり、ツールの改善が続けば、そう遠くないうちに、すべてのソフトウェアで SBOM のリクエストやダウンロードができるようになるでしょう。さらに、利用するソフトウェアの脆弱性も把握できるようになるかもしれません。今回の例を通して、SBOM と脆弱性データベースを結びつけるうえでの問題が解消されたときに、SBOM で何が実現できるかを垣間見ることができました。それこそ、使うソフトウェアのリスクに関する不安が軽減された新たな日常です。
spdx-to-osv ツールの作成者で、このブログ投稿に貢献いただいた Source Auditor 社の Gary O'Neall 氏に深く感謝いたします。
Posted by Eiji Kitamura - Developer Relations Team
昨年は、ソフトウェア部品表（Software Bills of Materials、SBOM）を採用しようという機運が業界全体で高まりました。SBOM とは、ソフトウェアをビルドするために必要なコンポーネント、ライブラリ、モジュールをすべて列挙したものです。2021 年のサイバーセキュリティに関する米国大統領令を受けて、私たちが使うソフトウェアが何でできているのかを理解する手段として、このソフトウェア部品表が注目されています。基本的な考え方は、他者が作ったものも含め、すべての部品について把握していなければ、特定のソフトウェアに含まれるリスクは判断できないというものです。SBOM への関心の高まりは、米国国立標準技術研究所（NIST）がソフトウェアの SBOM 情報の提供を必須としたセキュア ソフトウェア開発フレームワークを公開したことで、さらに押し上げられることになりました。しかし、業界で SBOM を生成して共有する手法が進展しつつある今、SBOM をどのように活用すればよいのでしょうか。
SBOM を生成するだけでは、まだ道半ばです。あるソフトウェアの SBOM が準備できたら、それを既知の脆弱性リストにマッピングして、脅威を及ぼしかねないのはどのコンポーネントかを確認する必要があります。この 2 つの情報源を結びつけることで、利用者はソフトウェアに含まれているものだけでなく、そのリスクや修正すべき問題があるかどうかも把握できます。
このブログ投稿では、大規模で重要なプロジェクトである Kubernetes から SBOM を取得し、オープンソースのツールを使ってそこに含まれる脆弱性を特定するプロセスを示します。私たちの例の成功は、完全な SBOM が作られるのを待たなくても、SBOM と一般的な脆弱性データベースとのマッピングを始められることを示しています。2 つのデータソースを結びつける際の現在の制限に対処するために SBOM 作成者が少しの更新を行うだけで、このプロセスは、平均的なソフトウェア利用者が簡単に使えるものになります。
OSV: SBOM と脆弱性を結びつける
以下の例では、Kubernetes を取り上げます。大規模プロジェクトである Kubernetes では、SBOM 情報を伝達するためのオープンな国際基準（ISO）である Software Package Data Exchange（SPDX）形式で SBOM が提供されています。SBOM を提供しているすべてのプロジェクトにも、同じ考え方が当てはまるはずです。SBOM を提供していないプロジェクトでは、Kubernetes が作成した同じ bom ツールを使って独自の SBOM を生成できます。
今回は、この SBOM を Open Source Vulnerabilities（OSV）データベースにマッピングすることにしました。このデータベースでは、オープンソース パッケージのバージョンやコミット ハッシュとマッピングできる形式で脆弱性が記述されています。OSV データベースはこの点でも優秀で、標準形式が提供され、複数のエコシステム（Python、Golang、Rust など）やデータベース（Github Advisory Database（GHSA）、Global Security Database（GSD）など）からの情報が集約されています。
SBOM とデータベースを結びつけるために、SPDX の spdx-to-osv ツールを使います。このオープンソース ツールは SPDX の SBOM ドキュメントを受け取り、OSV 脆弱性データベースに照会をし、ソフトウェアで宣言されているコンポーネントに含まれる脆弱性の一覧を返します。
例 : Kubernetes の SBOM
最初の手順は、Kubernetes の SBOM をダウンロードすることです。Kubernetes の SBOM は公開されており、プロジェクト、依存関係、バージョン、ライセンスについての情報が含まれています。次に示す簡単な curl コマンドで、誰でもダウンロードできます。
次の手順では、SPDX の spdx-to-osv ツールを使って Kubernetes の SBOM と OSV データベースを結びつけます。
ツールの出力から、Kubernetes の v1.21.3 には、脆弱性 CVE-2020-26160 があることがわかります。この情報は、このソフトウェアを運用するリスクを管理するために追加のアクションが必要かどうかを判断する際に役立つ可能性があります。たとえば、ある組織が Kubernetes の v1.21.3 を使っている場合、会社のポリシーに基づいてデプロイされたソフトウェアを更新するという対策をとることが考えられます。そうすれば、この脆弱性を悪用した攻撃から組織を守ることができます。
SBOM ツールの改善提案
spdx-to-osv ツールを動作させるには、いくつかの小さな変更を行い、SBOM が提供する情報のあいまいさを排除する必要がありました。
- 現在の bom ツールの実装では、バージョンがパッケージ名の中に含まれています（gopkg.in/square/go-jose.v2@v2.2.2）。SPDX 形式ではバージョン番号が別のフィールドに格納されているため、この接尾辞を取り除かないと、照合させることができませんでした。
- この bom ツールで作成した SBOM では、エコシステムが特定できません。エコシステムがないと、どのライブラリやパッケージが影響を受けるかを確実に自動判定することはできません。エコシステムによって影響の有無が異なる場合、脆弱性スキャナが誤判定を引き起こす可能性があります。SBOM でライブラリやパッケージのバージョンが区別されていれば、利便性がさらに高まります。
- SBOM ツールの作成者は、ソフトウェアに含まれるすべてのパッケージについて、Purl などの識別スキームによる参照を追加すべきです。この種の識別スキームがあれば、エコシステムを特定できるとともに、前述の接尾辞のようなパッケージ記述子の小さな揺れに対するスキームの柔軟性が向上するので、パッケージの識別も容易になります。SPDX ではこれをサポートするために、Purl の外部参照やその他のパッケージ識別スキーマの外部参照を使用しています。
SBOM の当初の目的である「ソフトウェアの脆弱性リスク管理を支援する」が実現されつつあることは明らかです。今回の例では OSV データベースを照会しましたが、近いうちに、他の脆弱性データベースに SBOM データをマッピングしたり、VEX などの新しい標準を使ったりすることもできるようになるでしょう。VEX では、ソフトウェアの脆弱性が軽減されているかどうかについての追加情報が提供されます。
SBOM の採用が広がり、ツールの改善が続けば、そう遠くないうちに、すべてのソフトウェアで SBOM のリクエストやダウンロードができるようになるでしょう。さらに、利用するソフトウェアの脆弱性も把握できるようになるかもしれません。今回の例を通して、SBOM と脆弱性データベースを結びつけるうえでの問題が解消されたときに、SBOM で何が実現できるかを垣間見ることができました。それこそ、使うソフトウェアのリスクに関する不安が軽減された新たな日常です。
spdx-to-osv ツールの作成者で、このブログ投稿に貢献いただいた Source Auditor 社の Gary O'Neall 氏に深く感謝いたします。
Posted by Eiji Kitamura - Developer Relations Team