Google Developers Japan

次の手順では、SPDX の spdx-to-osv ãƒ„ールを使って Kubernetes の SBOM と OSV データベースを結びつけます。

# SPDX SBOM æƒ å ±ã‚’å—ã‘å–ã‚Š、それを OSV 脆弱性にマッピングする spdx-to-osv ツールを実行する $ 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 # 出力された spdx-to-osv ツールの OSV 脆弱性を表示する $ 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 ツールの改善提案

spdx-to-osv ツールを動作させるには、いくつかの小さな変更を行い、SBOM が提供する情報のあいまいさを排除する必要がありました。

• 現在の bom ツールの実装では、バージョンがパッケージ名の中に含まれています（gopkg.in/square/[email protected]）。SPDX 形式ではバージョン番号が別のフィールドに格納されているため、この接尾辞を取り除かないと、照合させることができませんでした。

• この bom ツールで作成した SBOM では、エコシステムが特定できません。エコシステムがないと、どのライブラリやパッケージが影響を受けるかを確実に自動判定することはできません。エコシステムによって影響の有無が異なる場合、脆弱性スキャナが誤判定を引き起こす可能性があります。SBOM でライブラリやパッケージのバージョンが区別されていれば、利便性がさらに高まります。

ただし、これらは比較的小さなハードルで、手動で多少の調整をするだけで、うまくツールを実行できました。今後、このプロセスを簡単に実行できるように、次の提案により SBOM 生成ツールを改善したいと考えています。

• SBOM ツールの作成者は、ソフトウェアに含まれるすべてのパッケージについて、Purl ãªã©ã®è­˜åˆ¥ã‚¹ã‚­ãƒ¼ãƒ ã«ã‚ˆã‚‹å‚照を追加すべきです。この種の識別スキームがあれば、エコシステムを特定できるとともに、前述の接尾辞のようなパッケージ記述子の小さな揺れに対するスキームの柔軟性が向上するので、パッケージの識別も容易になります。SPDX ではこれをサポートするために、Purl の外部参照やその他のパッケージ識別スキーマの外部参照を使用しています。

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