no extension

拙作の depm で利用している github.com/google/licenseclassifier パッケージの v2 系モジュールがいい感じにバージョンが上がってきたので,どのくらい使えるようになったのか試してみた記事がこれ。

で,この記事について有り難くも「SPDX License identifier にも触れて欲しい」というリクエストを頂いたので SPDX (Software Package Data Exchange) についてちょろんと紹介する文章を追記した。 これを書くためにサイトを眺めて初めて気がついたのだが SPDXISO/IEC 5962:2021 として標準化されていたらしい。

Between eighty and ninety percent (80%-90%) of a modern application is assembled from open source software components. An SBOM accounts for the software components contained in an application — open source, proprietary, or third-party — and details their provenance, license, and security attributes. SBOMs are used as a part of a foundational practice to track and trace components across software supply chains. SBOMs also help to proactively identify software issues and risks and establish a starting point for their remediation.

ISO/IEC 5962:2021 がリリースされたのが2021年8月。 その年の年末に例の Apache Log4j の脆弱性に端を発したソフトウェア・サプライチェーン脆弱性の問題が大きく取り上げられることになった。

どーりで今年(2022年)に入ってやたらと「ソフトウェア部品表(Software Bill of Materials; SBOM)」の話を聞くようになったわけだ。

更にタイミングのいいことに7月下旬に以下の記事が公開されていたのを yomoyomo さんの記事で知った。

Importantly, the culprit was not the developers of the code but the company that failed to implement a patch that promised to prevent the very thing that happened. Many observers complain that Equifax has suffered little consequence for its negligence, highlighting weak oversight and accountability structures.
これに対し、最近では連邦取引委員会が Log4Shell の対応パッチの適用が遅い企業を強制措置をかますなど、政府がオープンソースのセキュリティ問題に介入する姿勢を見せつつある。著者はその一環としての SBOM(Software Bill Of Materials:ソフトウェア部品表)を評価するが、それだけでは不十分と断じる。

An SBOM is simply a list of the ingredients, or codebases, that comprise software you purchased. It does not provide a list of vulnerabilities nor does it impose any minimum security requirements on the vendor generating the SBOM. Comparable to a list of ingredients on a snack or medication you purchase, the information is only as useful as your ability to parse it.

To operationalize an SBOM, a company must be able to read it, which is a challenge as there is no mandated standard format for an SBOM, and actually use it to check databases such as the National Vulnerability Database (NVD) for new vulnerabilities found in the software components the SBOM lists. These activities are costly and cumbersome. While Google and Intel might have the resources and security maturity to demand machine-readable SBOMs and regularly scan databases for new vulnerabilities that impact their systems, there are countless small businesses using open source that cannot.


個人的には FOSS 製品を「公共財」と見なす向きには違和感や危うさを感じてしまうのだが,もはや四の五の言ってられねー,って感じなのだろう。 せめて SPDX が SBOM の標準としてセキュリティ・リスク管理に上手く組み込まれることを期待したい。

報告される脆弱性の量的評価としての CVSS,ソフトウェア・サプライチェーンの構成を可視化する SPDX/SBOM,脆弱性が報告された際のアクションを支援する SSVC1 といった道具・手段を組み合わせて,脆弱性報告から対応までのワークフローがスムーズに流れるようになるといいなぁ,と思ったり。 まぁ,そのワークフロー自体がソフトウェア・サプライチェーンだったりするのだが(笑)


Synk と SBOM

開発者向けのセキュリティ関連サービスを提供している SynkSPDX/SBOM について以下のように述べている。

Snyk integrates with a wide range of different package managers and developer tools to help identify vulnerabilities in the software components used. In doing that we need to build up a SBOM under the hood, normalising the list of software and augmenting that list with additional metadata from other sources. The Snyk tooling mainly focuses on presenting that information alongside information about vulnerabilities, but Snyk customers can access that raw SBOM via our built-in reporting or powerful API.

In fact, you can think of Snyk client tools like the CLI and CI/CD plugins as generating an SBOM, while Snyk’s backend takes an SBOM and returns vulnerability data, or provides automation around that data to help you fix issues. It’s this extensive experience that leads to our interest in emerging standards in this space.

Microsoft と SBOM

忘れていたが Microsoft も SBOM を自動生成するツールを OSS で出してたんだっけ。

具体的には、ソフトウェア名やライセンス、作成者、バージョン、個々のファイルのハッシュ値などの情報を、SBOMのフォーマットとしての標準の1つである「SPDX」(Software Package Data Exchange)形式で出力してくれます。


まぁ,メインの文章でも紹介したように「SBOM をどう使うか」が重要なんだけどね。



ブルース・シュナイアー (著), 井口 耕二 (翻訳)
日経BP 2007-02-15
4822283100 (ASIN), 9784822283100 (EAN), 4822283100 (ISBN)

原書のタイトルが “Beyond Fear: Thinking Sensibly About Security in an Uncertain World” なのに対して日本語タイトルがどうしようもなくヘボいが中身は名著。とりあえず読んどきなはれ。ゼロ年代当時 9.11 およびその後の米国のセキュリティ政策と深く関連している内容なので,そのへんを加味して読むとよい。

reviewed by Spiegel on 2019-02-11 (powered by PA-APIv5)

  1. SSVC (Stakeholder-Specific Vulnerability Categorization) については “Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (Version 2.0) ” あたりを参照のこと。 ↩︎