Consideration for new fields and scope expansion

[stevespringett]

I'd like to start off by saying, thank you for starting this project, and trying to gather the community to support it. I had a "todo" project called the Common Lifecycle Enumeration that had essentially the same mission, but haven't had a chance to even start working on it. Hopefully, this effort will succeed and I won't have to 😉

The CycloneDX community looked into supporting EOL/EOS data in our BOM format back in July 2021. However, the feedback from the CycloneDX Industry Working Group was:

1. The data is difficult to obtain, so why bother
2. The data is dynamic, subject to change, and therefore should not be in an SBOM.

We like hard problems, so the first point didn't bother us. But they were right about the second, so we dropped it.

However, these were the fields that were under consideration.

• generalAvailability: timestamp
• endOfLife: timestamp
• endOfDevelopment: timestamp
• endOfService: timestamp
• endOfSupport: timestamp
• extendedSupportAvailable: boolean
• extendedSupportProvider: array (organizationalEntity)

It would be great if OPLF would support these fields. However, more advanced use cases also need to be considered. For example, Bootstrap v3 was supported, then it wasn't, but v4 was still alpha, and later when v4 was available, they supported v3 again. So being able to capture these fields over time would be ideal.

The other mission that Common Lifecycle Enumeration was going to solve, was component aliasing over time. So for example, being able to track when the product gets renamed/rebranded, sold to another entity or the entity changes its name. All of this is part of the product lifecycle and should ideally be supported in the schema.

Anyway, these are some thoughts that myself and others in the SBOM Forum have discussed previously, and it would be great to have a project focused on these tough challenges.