From 853bc21e24c05887c74d782ca5a6a238109363d6 Mon Sep 17 00:00:00 2001 From: Andreas Fehlner Date: Sun, 8 Nov 2026 09:57:53 +0100 Subject: [PATCH] fix(SBOM): normalize terminology (Bill of Materials, lifecycle phases) - 'Cryptographic Bill of Material (CBOM)' -> 'Cryptography Bill of Materials (CBOM)', matching the CBOM guide and the ecosystem overview in 0x10-Introduction. - 'Manufacturing Bill of Material (MBOM)' and 'Hardware Bill of Material (HBOM)' -> 'Bill of Materials'. - 'Pre Build'/'Post Build'/'pre build' -> 'Pre-build'/'Post-build'/ 'pre-build', matching the defined phase names in 0x20-Lifecycle_Phases. - 'Software Development Life Cycle' -> 'Software Development Lifecycle' for consistency with guide-wide 'lifecycle' spelling; also fixed the adjacent grammar error (its' -> its). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Andreas Fehlner --- SBOM/en/0x20-Lifecycle_Phases.md | 4 ++-- SBOM/en/0x30-Use_Cases.md | 2 +- SBOM/en/0x41-Generation.md | 8 ++++---- SBOM/en/0x45-Cryptographic_Components.md | 2 +- SBOM/en/0x52-Linking.md | 2 +- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/SBOM/en/0x20-Lifecycle_Phases.md b/SBOM/en/0x20-Lifecycle_Phases.md index 910ee1d8..861753c8 100644 --- a/SBOM/en/0x20-Lifecycle_Phases.md +++ b/SBOM/en/0x20-Lifecycle_Phases.md @@ -1,10 +1,10 @@ # Lifecycle Phases -The Software Development Life Cycle (SDLC) is a process that outlines the phases involved in software development from +The Software Development Lifecycle (SDLC) is a process that outlines the phases involved in software development from conception to deployment and maintenance. It typically includes planning, analysis, design, implementation, testing, deployment, and maintenance; each phase has its own activities and deliverables. The purpose of the SDLC is to provide a structured and systematic approach to software development that ensures the final product meets the customer's requirements, is of high quality, is delivered on time and within budget, and can be maintained and supported throughout -its' lifecycle. +its lifecycle. Lifecycle phases communicate the stage in which data in the BOM was captured. This support extends beyond software to capture hardware, IoT, and cloud-native use cases. Different types of data may be available at various phases of a diff --git a/SBOM/en/0x30-Use_Cases.md b/SBOM/en/0x30-Use_Cases.md index 7f68da19..2a28d732 100644 --- a/SBOM/en/0x30-Use_Cases.md +++ b/SBOM/en/0x30-Use_Cases.md @@ -445,7 +445,7 @@ The following example illustrates the reliance on libcurl, provided externally: CycloneDX can describe declared and observed formulations for reproducibility throughout the product lifecycle of components and services. This advanced capability provides transparency into how components were made, how a model was trained, or how a service was created or deployed. Generally, the formulation is externalized from the SBOM into a dedicated Manufacturing -Bill of Material (MBOM). The SBOM references the MBOM that describes the environment, configuration, tools, and +Bill of Materials (MBOM). The SBOM references the MBOM that describes the environment, configuration, tools, and all other considerations necessary to replicate a build with utmost precision. This capability allows other parties to independently verify inputs and outputs from a build which can increase the software's assurance. diff --git a/SBOM/en/0x41-Generation.md b/SBOM/en/0x41-Generation.md index d3cda64d..70b63b97 100644 --- a/SBOM/en/0x41-Generation.md +++ b/SBOM/en/0x41-Generation.md @@ -69,9 +69,9 @@ approaches are listed below along with the lifecycles they could be executed in. | Approach | Lifecycles | Description | |------------------|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Build Plugin | Build | Specialized tool that integrates directly into native build systems | -| Software Factory | Pre Build, Build, Post Build | An approach whereby the system that orchestrates builds directly generates SBOMs | -| SCA | Pre Build, Build, Post Build | Software Composition Analysis, which may inspect manifests in version control pre-build, be integrated into builds, or perform analysis of built artifacts post-build | -| IAST/RASP | Post Build, Operations | Specialized tool that often involves instrumentation against running systems | +| Software Factory | Pre-build, Build, Post-build | An approach whereby the system that orchestrates builds directly generates SBOMs | +| SCA | Pre-build, Build, Post-build | Software Composition Analysis, which may inspect manifests in version control pre-build, be integrated into builds, or perform analysis of built artifacts post-build | +| IAST/RASP | Post-build, Operations | Specialized tool that often involves instrumentation against running systems | Each approach may use multiple methods and techniques to identify components and other relevant data. The techniques used, the confidence, and call stack reachability can all be described granularly at the component level in CycloneDX. @@ -82,7 +82,7 @@ SBOMs may describe individual source files and other digital assets in a directo of SBOMs typically include file components, file hashes, and evidence of license and copyright statements. The primary purpose of this type of BOM is for license compliance and intellectual property use cases. They may also be used as an OpenChain Compliance Artifact. Oftentimes, license attribution reports can be derived from source SBOMs. Generating -SBOMs from source files typically occur in the "pre build" lifecycle. +SBOMs from source files typically occur in the "pre-build" lifecycle. ## Integrating CycloneDX Into The Build Process Integrating SBOM generation into the software's build system is the preferred starting point for producing SBOMs for diff --git a/SBOM/en/0x45-Cryptographic_Components.md b/SBOM/en/0x45-Cryptographic_Components.md index 500fa0d3..d7ce662d 100644 --- a/SBOM/en/0x45-Cryptographic_Components.md +++ b/SBOM/en/0x45-Cryptographic_Components.md @@ -23,7 +23,7 @@ The following is a high-level architecture illustrating how cryptographic assets ![CBOM Component Architecture](../../CBOM/en/images/CBOM-Component-Architecture.svg) Organizations should consider including cryptographic assets in their SBOMs and optionally producing a BOM specific for -cryptographic material, otherwise known as a Cryptographic Bill of Material (CBOM). +cryptographic material, otherwise known as a Cryptography Bill of Materials (CBOM). Refer to the [Authoritative Guide to CBOM](https://cyclonedx.org/guides/) for in-depth information about leveraging CycloneDX for cryptographic use cases. diff --git a/SBOM/en/0x52-Linking.md b/SBOM/en/0x52-Linking.md index ff625053..d7588a68 100644 --- a/SBOM/en/0x52-Linking.md +++ b/SBOM/en/0x52-Linking.md @@ -96,7 +96,7 @@ The following example helps to illustrate what Component F may look like when re Another common case involves individual BOMs, per layer, in a deployed stack. For example, a BOM may contain multiple components, each with external references to its own individual BOMs. A hardware component could link to the -corresponding Hardware Bill of Material (HBOM), the operating system component could link to its corresponding SBOM, +corresponding Hardware Bill of Materials (HBOM), the operating system component could link to its corresponding SBOM, and an application component could do the same. A third case involves a service defined in a BOM where the provider of the service has published a SaaSBOM containing