From cd905554211bd8160a2f511b5998ddcb3a41d386 Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Fri, 24 Jan 2025 14:58:06 -0600 Subject: [PATCH] PEP 770: Move 'Selecting a single SBOM standard' to rejected ideas --- peps/pep-0770.rst | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/peps/pep-0770.rst b/peps/pep-0770.rst index 2880368fefc..c7f50a17381 100644 --- a/peps/pep-0770.rst +++ b/peps/pep-0770.rst @@ -409,6 +409,24 @@ is not constrained to select a single SBOM standard by its consumers and thus can allow tools creating SBOM documents for inclusion in Python packages to choose which SBOM standard works best for their use-case. +Rejected Ideas +============== + +Selecting a single SBOM standard +-------------------------------- + +There is no universally accepted SBOM standard and this area is still +rapidly evolving (for example, SPDX released a new major version of their +standard in April 2024). To avoid locking the Python ecosystem into a specific +standard ahead of when a clear winner emerges this PEP treats SBOM documents +as opaque and only makes recommendations to promote compatibility with +downstream consumers of SBOM document data. + +None of the decisions in this PEP restrict a future PEP to select +a single SBOM standard. Tools that use SBOM data today already need to support +multiple formats to handle this situation, so a future standard that updates to +require only one standard would have no effect on downstream SBOM tools. + Open Issues =========== @@ -417,13 +435,6 @@ Conditional project source SBOM files How can a project specify an SBOM file that is conditional? Under what circumstances would an SBOM document be conditional? -Selecting a single SBOM standard --------------------------------- - -Should this PEP select a single SBOM standard instead of supporting any -SBOM standard? Selecting a single standard would potentially limit the -evolution of SBOM standards which is an active area of development. - References ==========