Collecting Vocabulary Ideas for SBOM Document Quality Guide

[yum41]

Collecting Vocabulary Ideas for SBOM Document Quality Guide

2. Terms and Definitions

SBOM Document Quality Guideの2章に記載する用語を整理するためのディスカッション

OpenChain Telco SBOM Guideを基にした案

• Data Format
• Entity
• SBOM
• SBOM Type
• SPDX
• CycloneDX
• SWID
• OpenChain Specification ISO/IEC 5230:2020
• OpenChain Specification ISO/IEC 18974:2023
• Transitive dependencies
• Package URL(PURL)
• SBOM Document

[NorioKobota]

以下、前回考えがまとまっていませんでしたがやはり提案したいです。

• Source (Code) Distribution
• Binary (Code) Distribution

この項目をTermsに追加し、5章などで利用したいです。例えば、5.3 ソース情報の補完と透明性向上 では、まさにこの話が出てきます。
というのも、Binary Distributionの場合であっても所謂copyleft licenseで許諾されるOSSの場合は Complete Corresponding Source(CCS) の提供が必要になります。
CCSが提供されていたり Source Distribution の場合は、NTIA minimum elementなどの情報だけで情報が十分となる可能性があります。一方で、CCSの添付されない Binary Distribution の場合は、patchedBy, modifiedBy などの情報が必須になるのではないかと思います。(勿論、contactsに問い合わせる、という解決方法もありますが)

[NorioKobota]

#415 (comment)
@yoshi-i さんのコメントは、こちらへのReplyとなると考えていますが、
例えば、ソフトウェアの配布者しか知りえない情報を 必須記載事項 としたいと考えた場合、
Source Distributionにおいては、受領者側がそのソースコードを自分で用意したツールチェインで build することになると思います。一方で、 Binary Distributionにおいては、配布者がどのツールチェインで build したか、という情報は配布者しか知りえず、もしその情報がセキュリティ観点、ライセンスコンプライアンス観点で必要な情報であればその情報を SBOM Document に記載しておいてもらう方が品質が高い、と言えるのではないかと考えています。
ツールチェインの情報は必須なのかどうか、というのは議論の余地がありますが (別にツールチェインの情報は無くてよく、一方でツールチェインが知らないうちにlinkしてしまうようなlibgcc.soとかは別要素としてSBOM Documentに記載される等) 似たような話が無いかは気になっています。
また、

contact窓口とBinary Packageの厳密な製品名・バージョンが必要

という点に関しては、package name、package version の記載は元々NTIA minimumでも必須ですが、contacts(createdBy)とかは、
#415 (reply in thread)
をベースに考えると、v2系の時点から課題となっていると考えています。
https://spdx.github.io/spdx-spec/v2.3/document-creation-information/#681-description

"Person: person name" and optional "(email)"

と記載があった場合、optionalのemailが書かれていないと何か問題が起きたときであっても対応が出来ないと考えられます。こういった場合は、推奨事項としてemail addressは書かれているものの方が品質が高い、と言えるのではないでしょうか。
一方で source distribution であれば特に書かれていなかったとしても受領者側で対応が可能なので推奨しなくても良い、となると考えています。
こういった違いがあるため、Source Distribution と Binary Distribution をわけて考えた方が良いのではないか、と考えています。

[ftake]

先週の議論の転記と続きです

BSI TR-03183 には Source code と deployable form of the component という言葉の使い分けがあります。

バイナリ形式のコンポーネントはもちろんですが、スクリプト言語のコンポーネントであっても、何らかの加工が行われ、ソースコードリポジトリ上で管理されているものと、パッケージ（例えば npm）化され配布されている形式は必ずしもイコールではないので、区別しているところなのかなと解釈しています（BSI TR-03183の説明が言葉足らずなので…）。つまり、コンポーネントの中身がバイナリかは実は定義上は重要ではないのかもしれません。（実務上は別です）

source distribution にどの意味を持たせるか次第では、ソースコードと source distribution の区別できるような言葉の定義がいるのかもしれません。

[NorioKobota]

ソフトウェアサプライチェーンという単語も2種類ありそうに感じるので議論させてください。
開発に伴うソフトウェアサプライチェーンと、企業間で行われるソフトウェア配布の2種類です。

[no-ta]

External/Internal Software Supply Chain
https://sosscdeu2024.sched.com/event/1gb8a/exploring-a-risk-approach-to-software-supply-chain-security-abdullah-garcia-jp-morgan

[owada-k]

「開発に伴うソフトウェアサプライチェーン」は、「ソフトウェア開発フロー」の中の「コーディングからビルドのフロー」をイメージされているのではないでしょうか。
サプライチェーンというと、サプライヤーとコンシューマーが存在していることが前提になっていて、一人の人が開発（コーディングからビルドまで）を行っている場合には、サプライチェーンとは言わないと思います。
ソフトウェア開発フローの各パートを複数の人・企業で分担しているときに、前段パートの担当者から後段の人に受け渡しが起こるので、サプライチェーンとなるのだと思います。
そういった意味では、会社内でも複数の部署や人が分担しているのであれば、サプライチェーンになっていると思います。

[NorioKobota]

SBOM Document の品質とは?

この文書でフォーカスする "SBOM Document の品質" とは、ソフトウェアサプライチェーンにおいて、ソフトウェアの配布者から受領者へ、正確かつ十分な情報を伝える能力を示します。具体的には、以下の2点に注目します。

1. セキュリティ保証に必要な情報がそろっているか?
   • セキュリティに関連するリスクや脆弱性、対策など、ソフトウェアの安全性を確認するために必要な情報が含まれているかどうか。
2. 正しくライセンスコンプライアンスを行うために必要な情報がそろっているか?
   • ソフトウェアの各構成要素のライセンス情報や利用条件など、法令や規約に基づいた適切なコンプライアンスが実現できるための情報が含まれているか?

SBOM Documentの品質は、ソフトウェアの配布者が受領者へ必要なセキュリティ情報とライセンス情報を正確に伝達できているかどうかによって評価されます。

---

今回のガイドはこの観点で記載したいと考えています。更にソフトウェアの配布者は、コミュニティと企業を想定したいと考えています。
その為、例えば SLSA v1.2 の以下の図で言うと、

SBOM Document は、Hの部分でしか現れてこないと考えています。
SLSAなどではソフトウェアサプライチェーンという単語は、上図のA-Iまでの一連のフローを全て指しています。勿論、Eなどで依存関係から外部パッケージが引き込まれるので、ソフトウェアサプライチェーンが存在はするのですが、このガイド策定においては、ProducerからConsumerに渡されるソフトウェアについて、そのソフトウェアの構成要素を(セキュリティとライセンスコンプライアンス観点で)正しく把握するための情報が揃っているか、ということを言いたいです。

以上のような背景から、単にソフトウェアサプライチェーン、という単語で言い表せないと考えているため、何か良い分け方、言い方は無いか? というのがこのスレッドの質問です。

[yoshi-i]

Binary Distributionで、contactsへの問い合わせ、で逃げ切る場合には、contact窓口とBinary Packageの厳密な製品名・バージョンが必要で、かつ、VEX情報の側で用いられる製品名・バージョンと完全に一致させることができるか、もしくは、VEX情報で記載されている製品名・バージョン情報とパッケージがリリースされる際に用いられた(場合によっては古い命名ルールの)製品名・バージョン情報とのマッチングが可能なテーブルを参照可能にしておかねばならない、とかですかね