FEAT: 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

one case, as @nscuro pointed out:
CLI switch --use-lockfile-only causes not to inspect any evidence of actually installed packages, but use the lockfile instead. the lockfile be outdated/ahead/modified for several reasons.
if CLI switch --use-lockfile-only was used, then the resulting SBOM is done in a certain pre-build stage.
this should be made clear in the resulting SBOM, by populating metadata.lifecycles

Describe the solution you'd like

populate bom.metadata.lifecycles:
📣 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/

Option A -- single value:

• have a CLI switch for the lifecycle:
• default value for metadata.lifecycles is determined as below
  • if CLI switch --use-lockfile-only was used: pre-build
  • else:
    • if CLI switch --omit dev was used: build
    • else: post-build

Option B -- multiple values:

• have a CLI switch for the lifecycles:
• default values for metadata.lifecycles: empty list
• if CLI switch --use-lockfile-only was used: add pre-build to the list
• if CLI switch --omit dev was used: ass build to the list
  else: add post-build to the list

Option C:

one of (A or B ), but no CLI option, only auto-added values

Option D:

one of (A or B ), but no defaults nor auto-added values whatsoever (empty list/ omit metadata.lifecycle per default)

Describe alternatives you've considered

❗ to be discussed which solution to use, based on expectations of users

Additional context

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

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.