fix(SBOM): normalize terminology (Bill of Materials, lifecycle phases)

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 

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.
 

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

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.

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