Add support for lifecycle

[stevespringett]

In the BOM metadata, add support for lifecycle which describes each lifecycle phase involved in the creation of the BOM. This should be an enum of allowable choices.

"lifecycle": [
  "procurement", "build", "testing", "release"
]

[stevespringett]

Word choice is important as lifecycle must be applicable to all component types.

[stevespringett]

Possible solution is to use the cdx property namespace rather than introducing a new field.

[mrutkows]

Possible solution is to use the cdx property namespace rather than introducing a new field.

+1

[jkowalleck]

@stevespringett, could you elaborate on the stages and what they are and what they imply? as a comment might be also important, just like

Word choice is important as lifecycle must be applicable to all component types.

[stevespringett]

could you elaborate on the stages and what they are and what they imply?

We might be able to leverage this document that the CISA SBOM group is working on https://docs.google.com/document/d/1PsUhUQ_L-lNymD9p613zP0_MiT1Boag68TP3aiwZ4R8/edit

[stevespringett]

We might be able to leverage this document that the CISA SBOM group is working on https://docs.google.com/document/d/1PsUhUQ_L-lNymD9p613zP0_MiT1Boag68TP3aiwZ4R8/edit

Unfortunately, the CISA work resulted in SBOM "types" which include a combination of lifecycle (e.g. design, build) and overall approach (e.g. analyze, runtime). CycloneDX needs support for pure lifecycle. We have much more granular ways to describe the precise approach and techniques used. So the CISA doc wasn't overly useful.

[oej]

The CISA types are good, but I wonder how useful they are in this context. What I am missing in their list is the "final" SBOM, the external one that I have signed off on as a publisher. The one customers can import.

I think that status is important to signal within the SBOM.

[jkowalleck]

Each BOM might be final with a different use case in mind. So I could have an SBOM that includes all my testing frameworks. As an in-house security person, I would love to have this, so I know that my testing environments are safe. My testing environments are not hardened like my out-facing production environment, so I need to take special care.

And so the other types come in handy, to display the stage or purpose the BOM represents.

If I'd ship a final product, I would use "release". Would you agree, @oej ?

[oej]

Ok, so marking the status of an SBOM is a separate issue.

I may be looking for something like "generated", "audited", "published" to indicate the readiness level. I do agree that it's out of scope and that "release" and metadata may solve it. Thanks for the feedback.

[stevespringett]

The PR which adds support for lifecycles tries to align with SDLC and SAM. It specifically adds support for:

• 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 retried 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 make 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.

These are the enums that can be used. In addition, it allows the 'name' of a custom lifecycle to be used as well.

I would expect a "release" SBOM to include build and/or post-build lifecycles. But there is not a specific release enum as of now.

Also, I have omitted testing because it doesn't make sense. Testing could be unit tests, integration test, performance test, functional tests, etc, and each of those could be performed at various parts of the lifecycle. Unit tests are usually performed during a build, which integration tests typically are performed post-build.

The CISA SBOM types paper doesn't make a lot of sense. I know what they tried to capture, but feel like they failed in making anything useful. For example, CISA declares that analyzed is an SBOM type. Its not. Its what you do to identify components, and that type of analysis can be performed at various lifecycle stages. The CISA approach also doesn't acknowledge that SBOM generation is a process, not a one-time event. In reality, it is common to see manifest, binary, and other types of techniques using in the creation of a BOM. CycloneDX v1.5 captures this, on a per-component basis, through the use of component evidence.

[puerco]

I didn't participate in the CISA group defining the SBOM types, but as a tool writer I find it frustrating to see you chose to diverge CDX again after the SBOM community spent so many months working to build consensus on a common vocabulary :disappointed:

I don't pretend to have a voice over here but I would like to appeal to the principle of common interest and ask you to reconsider.

[stevespringett]

I don't pretend to have a voice over here...

Nice to hear from you @puerco. The beautiful thing about OWASP projects is that everyone has an equal seat at the table.

frustrating to see you chose to diverge CDX again

CycloneDX is closely aligned to SDLC and SAM lifecycles. This allows us to meet a number of enterprise use cases that would not be possible with the CISA SBOM types. Use cases drive our requirements, not CISA documents. It's unfortunate that CISA did not adopt these well established lifecycles, and chose to ignore the work that the CycloneDX community has been doing for over a year in supporting component evidence.

For example, CISA SBOM type Analyzed and Runtime are achieved in CycloneDX in a much more granular way, at the component level. This was the consensus of the CycloneDX Industry Working Group, Core Working Group, representatives of multiple commercial security vendors, and the community. Both binary-analysis and instrumentation are supported on a per-component basis and align to these two CISA SBOM types. Many other techniques are supported as well. There are many use cases where a variety of methods and techniques will be leveraged in the analysis of components. CycloneDX tries to capture as much of this as possible.

as a tool writer...

There are a number of new possibilities that are unlocked with v1.5 that will lead to the creation of new open source and commercial tools. Some vendors are already working to implement them in their products.