render metadata.lifecycles

[jkowalleck]

📣 please discuss the options and expectations in the comments below

---

Is your feature request related to a problem? Please describe.

CycloneDX spec 1.5 brought metadata.lifecycles, with allowes to describe the ALM stage when the SBOM was created. see https://cyclonedx.org/docs/1.5/json/#tab-pane_metadata_lifecycles_items_oneOf_i0

Describe the solution you'd like

TO BE DISCUSSED

value could be CLI supplied, or auto-detected.
📣 to be discussed in the comments, see options below.

optional:in addition, non-well-known values are accepted, and shall result in "named" stages.

see example at : https://cyclonedx.org/guides/sbom/lifecycle_phases/

auto-detection:

• if lockfile-based analysis - use pre-build
  else, use build
• if dev is NOT omitted, then add post-build

🔍 see similar: CycloneDX/cyclonedx-node-npm#1026

Describe alternatives you've considered

none

Additional context

this feature is feasible since CycloneDX 1.5,
request for library: CycloneDX/cyclonedx-php-library#339

For additional information about lifecycles and evidence, refer to:

• https://cyclonedx.org/guides/sbom/lifecycle_phases/
• https://cyclonedx.org/guides/sbom/evidence/

This all ties into SBOM quality, which OWASP CycloneDX defines here:

• https://cyclonedx.org/guides/sbom/bom/#sbom-quality

see the available phase descriptions: https://cyclonedx.org/docs/1.5/json/#metadata_lifecycles_items_oneOf_i0_phase

• design = BOM produced early in the development lifecycle containing inventory of components and services that are proposed or planned to be used. The inventory may need to be procured, retrieved, or resourced prior to use.
• pre-build = BOM consisting of information obtained prior to a build process and may contain source files and development artifacts and manifests. The inventory may need to be resolved and retrieved prior to use.
• build = BOM consisting of information obtained during a build process where component inventory is available for use. The precise versions of resolved components are usually available at this time as well as the provenance of where the components were retrieved from.
• post-build = BOM consisting of information obtained after a build process has completed and the resulting components(s) are available for further analysis. Built components may exist as the result of a CI/CD process, may have been installed or deployed to a system or device, and may need to be retrieved or extracted from the system or device.
• operations = BOM produced that represents inventory that is running and operational. This may include staging or production environments and will generally encompass multiple SBOMs describing the applications and operating system, along with HBOMs describing the hardware that makes up the system. Operations Bill of Materials (OBOM) can provide full-stack inventory of runtime environments, configurations, and additional dependencies.
• discovery = BOM consisting of information observed through network discovery providing point-in-time enumeration of embedded, on-premise, and cloud-native services such as server applications, connected devices, microservices, and serverless functions.
• decommission = BOM containing inventory that will be, or has been retired from operations.