From e20b3416470ea956560d2fd85aca8e336001c68b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20Prpi=C4=8D?= Date: Thu, 10 Oct 2024 14:35:41 -0400 Subject: [PATCH] Provide better definitions of what a complete manifest is --- docs/sbom.md | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/docs/sbom.md b/docs/sbom.md index 8130ca8..a193bc9 100644 --- a/docs/sbom.md +++ b/docs/sbom.md @@ -14,7 +14,17 @@ When talking about inventories of components, it's also important to describe wh comprehensive SBOM are: - Provide a complete and accurate listing of software components and their relationships to each other from a - supply chain perspective. + supply chain perspective: + + - For each software component, an SBOM must list its provenance. That is, if the (downstream) component is a + redistributed version of an open source project (upstream), the downstream component must be directly linked + to its upstream counterpart. If an upstream component is augmented in a mirrored repository before being used + in a build of a downstream component, this version of the component (also called a midstream component) must + be recorded as a separate package. + + - A manifest must list all components that are included in the final deliverable that can be deployed and run by an + end user. Any software dependencies that are used strictly during the build process must be listed as well, but + separate from the runtime dependencies. - Define an accurate identification of components and products usable across all published security data. @@ -484,8 +494,7 @@ relationship to architecture-specific RPMs can be represented with: ``` SRPMs are also linked to one or more upstream sources that were used to build the downstream RPMs. An upstream - -Upstream source: +source can be represented by a package object using the following data: === "SPDX 2.3"