Integration of CLE

[oej]

          re: CLE usage, think its totally fine to use a mock version of CLE even if we're not done yet. Happy to see an effort to make it used! 

I haven't been keep up with TEA development. However, the CLE spec for a product will cover many different versions of a product? It could cover Bootstrap 2.x and 3.x. It could just cover a list of minor versions. So I think attaching a CLE to a specific version like a leaf version would be incorrect here if that is whats happening. CLE specifically should not be attached to version of something. It should live alongside or be attached to a product or a component if that makes sense, that can describe many or all versions of the product.

Originally posted by @noqcks in https://github.com/CycloneDX/transparency-exchange-api/issues/102#issuecomment-2733284914

[oej]

Interesting. We will have to review that. Either attach it to multiple versions as a single shared artefact, which is possible or look for something else.

A related question is if we could use CLE terminology in other parts.

[noqcks]

The latest work on the CLE specification can be found in this PR

[oej]

So CLE is an artefact in TEA and that will work. This artefact will be connected to multiple collections.

But can we steal some ENUM to indicate life-cycle state of a release?

[oej]

From CLE:

• released
• endOfDevelopment
• endOfSupport
• endOfGuaranteedSupport
• endOfLife
• endOfProduction
• endOfMarketing
• supersededBy

[oej]

They are looking into Security Status Changes - which is most important for this.

[ppkarwasz]

They are looking into Security Status Changes - which is most important for this.

Since we are mostly interested in the upgrade risk associated with a vulnerability in a software component, we could use a simplified lifecycle for TEA Component Releases. Each state indicates the expected stability and security support level:

1. PATCH

   Definition: The component release is actively maintained with security updates delivered as semantic PATCH updates.

   Upgrade Risk: Minimal. Upgrades are highly unlikely to introduce regressions or break functionality.

2. MINOR

   Definition: Security updates are no longer provided for this semantic minor version.

   Resolution: Users must upgrade to the next minor version, which is backward compatible but may introduce feature changes.

   Upgrade Risk: Low to Moderate. Compatibility is preserved, but minor functional differences may occur.

3. MAJOR

   Definition: The semantic major version no longer receives security updates.

   Resolution: Users must either upgrade to a newer major version or manually backport security patches.

   Upgrade Risk: High. Major version upgrades can include breaking changes.

4. EOL (End of Life)

   Definition: The publisher no longer accepts vulnerability reports or provides fixes for this release.

   Consequence: Users are effectively on their own and exposed to undisclosed security risks.

   Upgrade Risk: Severe. Immediate action is recommended.

[ppkarwasz]

@stevespringett, is there an existing OWASP metric that takes into account the risk of upgrading to the latest release of a software component?