Skip to content

Commit 38f20fc

Browse files
authored
Merge pull request #36 from RedHatProductSecurity/add-complete-sbom-definitions
Add better complete SBOM definitions
2 parents 9909653 + e20b341 commit 38f20fc

File tree

1 file changed

+12
-3
lines changed

1 file changed

+12
-3
lines changed

docs/sbom.md

Lines changed: 12 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,17 @@ When talking about inventories of components, it's also important to describe wh
1414
comprehensive SBOM are:
1515

1616
- Provide a complete and accurate listing of software components and their relationships to each other from a
17-
supply chain perspective.
17+
supply chain perspective:
18+
19+
- For each software component, an SBOM must list its provenance. That is, if the (downstream) component is a
20+
redistributed version of an open source project (upstream), the downstream component must be directly linked
21+
to its upstream counterpart. If an upstream component is augmented in a mirrored repository before being used
22+
in a build of a downstream component, this version of the component (also called a midstream component) must
23+
be recorded as a separate package.
24+
25+
- A manifest must list all components that are included in the final deliverable that can be deployed and run by an
26+
end user. Any software dependencies that are used strictly during the build process must be listed as well, but
27+
separate from the runtime dependencies.
1828

1929
- Define an accurate identification of components and products usable across all published security data.
2030

@@ -485,8 +495,7 @@ relationship to architecture-specific RPMs can be represented with:
485495
```
486496

487497
SRPMs are also linked to one or more upstream sources that were used to build the downstream RPMs. An upstream
488-
489-
Upstream source:
498+
source can be represented by a package object using the following data:
490499

491500
=== "SPDX 2.3"
492501

0 commit comments

Comments
 (0)