[FEATURE]: Add external reference type for support policy/lifecycle metadata

[ppkarwasz]

Describe the feature

While the work on CLE is progressing it would be useful to add an externalReference type to hold a link to a CLE, OpenEOX or other kind of document that describes the versioning/support policy of the project.

Possible solutions

Naming is certainly the most difficult problem, but the new type might be called support-lifecycle or simply lifecycle.

Currently there is no machine-readable format to describe EOS/EOL data, but the link could point to a human-readable page.

[jkowalleck]

could you open a PR targeting the 1.7-dev branch, and propose the needed changes you have in mind?

[jkowalleck]

could you open a PR targeting the 1.7-dev branch, and propose the needed changes you have in mind?

FYI: the topic is currently in stage "proposal". A working implementation/spec via pull-request would set it to "prototyp".
When you are happy with your prototype, you can request to have it moved to "draft" - at this stage the community is asked to vote/comment the feature/implementation - and after 4 weeks the votes are counted and future steps might happen.

See the process description here: https://cyclonedx.org/participate/standardization-process/

[jkowalleck]

similar/related scope and topics:

• Add properties required by FDA certification cyclonedx-property-taxonomy#104
• Where to add level of support and component's end-of-support date #598
• Request: Add project sustainability fields to CycloneDX #400
• Add Steward to the CycloneDX specficiation #503

[ppkarwasz]

could you open a PR targeting the 1.7-dev branch, and propose the needed changes you have in mind?

Sure, I'll send a PR by the end of the week. Can you assign me to the issue, so I don't forget?

[devashridatta-dotcom]

Adding practitioner review perspective from enterprise SBOM governance implementations.

The proposal to introduce a support-policy / lifecycle external reference addresses an important gap, particularly for consumers evaluating component risk, maintenance expectations, and exception handling.

One implementation consideration observed in practice is that lifecycle and support context is often not consumed in isolation. In large environments, this metadata is correlated across build systems, release pipelines, vulnerability tracking, and exception governance using internal identifiers that may not be globally resolvable but are operationally critical.

As a result, it may be useful to clarify whether the intent of the lifecycle external reference is:
• to act as a canonical, externally consumable source of lifecycle truth, or
• to serve as a flexible reference that can coexist with internal lifecycle, support, and governance metadata used for correlation across SBOM variants (design, build, analyzed, deployed).

This distinction has practical implications for conformance tooling and downstream consumers, particularly where SBOMs are generated at multiple lifecycle stages and interpreted under regulatory or enterprise governance constraints.

Related lifecycle governance and correlation patterns are described in a public SBOM governance framework:
https://github.com/devashridatta-dotcom/enterprise-sbom-public-domain1.git