Implement MVP support for CycloneDX Lifecycle

[msymons]

Current Behavior

Dependency-Track does not support Lifecycle phases, support for which was introduced in CycloneDX 1.5

Lifecycle Phases

The Software Development Life Cycle (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.

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 lifecycle, and thus a BOM may include data specific to or only obtainable in a given lifecycle. Incorporating lifecycle phases in a CycloneDX BOM provides additional context of when and how the BOM was created. It becomes an additional datapoint that may be useful in the overall analysis of the BOM.

CycloneDX defines the following phases:

Phase	Description
Design	BOM produced early in the development lifecycle containing an 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, 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 a 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.

In addition, CycloneDX provides a mechanism to supply user-defined lifecycle phases as well.

The following example illustrates a BOM that was produced in the build and post-build lifecycle phases. In addition, a custom phase (platform-integration-testing) was involved as well.

"metadata": {
  "lifecycles": [
    {
      "phase": "build"
    },
    {
      "phase": "post-build"
    },
    {
      "name": "platform-integration-testing",
      "description": "Integration testing specific to the runtime platform"
    }
  ]
}

For more information, see Lifecycles in SBOM guide

Proposed Behavior

As I am proposing an MVP here, initially the requirement is to display lifecycle phases in Dependency-Track, and to be able discover all the projects where the SBOM is in a given lifecycle.

Eventually, the aim will be to use lifecycles, techniques, confidence, breadth and depth as input for SBOM quality policy.

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this enhancement was already requested