「Kubernetes」の脆弱性をSBOMで特定、Googleが詳細な手法を公開：利用中のOSSの脆弱性を調べるには

GoogleがSBOMの活用事例を公開した。オープンソースツールを使って、「Kubernetes」のSBOMを「Open Source Vulnerabilities」データベースと照合し、Kubernetesの構成要素に含まれる脆弱性を特定したプロセスを紹介した。

[＠IT]

　Googleは2022年6月14日（米国時間）に公開したブログ記事で、SBOM（Software Bill of Materials：ソフトウェア部品表）の活用事例を発表した。オープンソースツールを使って、「Kubernetes」のSBOMをオープンソースプロジェクトの脆弱（ぜいじゃく）性データベース「Open Source Vulnerabilities」（OSV）と照合し、Kubernetesの構成要素に含まれる脆弱性を特定したプロセスを紹介している。

　米国では、2021年の米国大統領令「国家のサイバーセキュリティの向上」の発令や、米国標準技術局（NIST）による「Secure Software Development Framework」（安全なソフトウェア開発フレームワーク）の発表を受け、SBOMの導入機運が高まっている。

　SBOMは、「特定のソフトウェアのリスクを判断するには、他社が作成したものも含めて、そのソフトウェアの全ての構成要素を把握することが不可欠だ」という考え方に基づいている。ソフトウェアの脆弱性リスクの管理に役立つことが目的だ。

　SBOMを活用してこのようなリスク管理に役立てるには、あるソフトウェアのSBOMが利用可能になった時点で、既知の脆弱性のリストにマッピングすればよい。そのソフトウェアの構成要素の中に、脅威をもたらすものがあるかどうか、そのリスクや問題を修正する必要があるかどうかが分かるからだ。

　SBOMを一般的な脆弱性データベースと照合する際には、まだ制限があるが、それは比較的小さなものであり、SBOM作成者がそうした制限に対処する措置を取れば、平均的なソフトウェア利用者がSBOMを容易に活用できるようになると、Googleは述べている。

どうやってKubernetesのSBOMから脆弱性をあぶり出したのか

　Kubernetesプロジェクトは、SBOM情報を伝達するための国際オープン標準（ISO/IEC JTC1標準）であるSPDX（Software Package Data Exchange）形式を使って、SBOMを公開している。

　以下で紹介するGoogleによるKubernetesのSBOM活用の考え方は、SBOMを公開しているどのプロジェクトにも当てはまる。また、そうでないプロジェクトについても、Kubernetesプロジェクトが作成したオープンソースのSPDX互換BOM（Bill of Materials）生成ツール「bom」を使って、独自のSBOMを生成できる。

　GoogleがKubernetesのSBOMをマッピングしたOSVデータベースは、オープンソースのパッケージバージョンまたはコミットハッシュにマッピングできるように設計されたフォーマットで、脆弱性を記述している。標準化されたフォーマットを提供し、複数のエコシステム（Python、Golang、Rustなど）およびデータベース（GitHub Advisory Database《GHSA》、Global Security Database《GSD》など）にわたる情報を集約している。

　GoogleはSBOMをOSVデータベースに接続するために、オープンソースの「spdx-to-osv」ツールを使用した。このツールは、SPDX SBOMドキュメントを取り込み、OSVデータベースと照会し、ソフトウェアの宣言されたコンポーネントに存在する脆弱性の列挙を返す。

　Googleはまず、次のように、簡単なcurlコマンドでKubernetesのSBOMをダウンロードした。このSBOMは前述の通り公開されており、プロジェクトや依存関係、バージョン、ライセンスに関する情報を含んでいる。誰でもダウンロードすることが可能だ。

# Download the Kubernetes SPDX source document
$ curl -L https://sbom.k8s.io/v1.21.3/source > k8s-1.21.3-source.spdx

　次に、spdx-to-osvツールを使って、KubernetesのSBOMをOSVデータベースに接続した。

# Run the spdx-to-osv tool, taking the information from the SPDX SBOM and mapping it to OSV vulnerabilities
$ java -jar ./target/spdx-to-osv-0.0.4-SNAPSHOT-jar-with-dependencies.jar -I k8s-1.21.3-source.spdx -O out-k8s.1.21.3.json
# Show the output OSV vulnerabilities of the spdx-to-osv tool
$ cat out-k8s.1.21.3.json
…
{
  "id": "GHSA-w73w-5m7g-f7qc",
  "published": "2021-05-18T21:08:21Z",
  "modified": "2021-06-28T21:32:34Z",
  "aliases": [
    "CVE-2020-26160"
  ],
  "summary": "Authorization bypass in github.com/dgrijalva/jwt-go",
  "details": "jwt-go allows attackers to bypass intended access restrictions in situations with []string{} for m[\"aud\"] (which is allowed by the specification). Because the type assertion fails, \"\" is the value of aud. This is a security problem if the JWT token is presented to a service that lacks its own audience check. There is no patch available and users of jwt-go are advised to migrate to [golang-jwt](https://github.com/golang-jwt/jwt) at version 3.2.1",
  "affected": [
    {
      "package": {
        "name": "github.com/dgrijalva/jwt-go",
        "ecosystem": "Go",
        "purl": "pkg:golang/github.com/dgrijalva/jwt-go"
      },
…

　ツールの出力は、Kubernetes v1.21.3がCVE-2020-26160の脆弱性を含んでいることを示している。

　この情報は、ソフトウェアの運用リスクを管理するために、何らかの追加措置が必要かどうかを判断するのに役立つ。例えば、組織がKubernetes v1.21.3を使用している場合、会社のポリシーをトリガーにして展開を更新する措置を取ることができ、これによって、この脆弱性を悪用した攻撃から組織を保護できる。

SBOMツールの改善提案

　Googleは、spdx-to-osvツールを動作させるために、幾つかのマイナーな変更を行い、SBOMで提供される情報を明確化する必要があったと説明している。

・現在のbomツールの実装では、バージョンはパッケージ名の一部として含まれていた（gopkg.in/square/go-jose.v2@v2.2.2）
　このため、バージョン番号のフィールドが異なるSPDXフォーマットに合わせて、接尾辞を切り詰める必要があった

・bomツールで作成されるSBOMは、エコシステムを指定していない
　エコシステムの指定がないと、どのライブラリやパッケージが影響を受けるのかを、自動的な方法で確実に明示することができない

　ただし、これらは比較的小さなハードルであり、Googleはわずかな手動調整だけで、spdx-to-osvツールを正常に実行できたと述べている。

　さらにGoogleは、このプロセスが今後、より容易になるように、「SBOMツールの作成者が、ソフトウェアに含まれる全てのパッケージについて、『Purl』のような識別スキームを使用したレファレンスを追加する」ことを提言している。

SBOMの将来は明るい

　SBOMを本来の目的通り、ソフトウェアの脆弱性リスクの管理に役立てることが、間もなく広く可能になることは明らかだと、Googleは述べている。

　今回紹介した例ではSBOMをOSVデータベースに照合した。だが、近い将来、SBOMデータを他の脆弱性データベースにマッピングすることや、ソフトウェアの脆弱性が緩和されているかどうかに関する追加情報を提供する「VEX」のような新しい標準と併用することに関しても、同様の成功例が出てくるだろうとの見通しを示している。