aboutcode-org
Enhancement request: Track product "lifecycle"
It would be great to support lifecycle events at the product level.
For instance, when I have a portfolio of products and product releases:
- some products are end-of-life
- some versions may be end-of-support
... And so on.
This is important for vulnerability management: if a product is no longer supported, I will not want to manage vulnerabilities the same as for a supported product (or may ignore these entirely)
There is a project at CycloneDX for common lifecycle events that may be of interest for this domain.
Perhaps this can be addressed by enhancing the existing Product Status table, which has been under-utilized. See attached screenshot. DejaCode users are welcome to define and create Product Status values that are meaningful to their product lifecycle processes.
We could add a new indicator to each entry, something like no_vulnerability_tracking (defaulting to false/unchecked) to provide a control in the vulnerability setting process to skip a product with such a Status.
@pombredanne @DennisClark I'd like to revisit this one and work on an implementation design.
While working on DejaCode product inventories I realized that we should have a way to "freeze" a product from any inventory changes. For example, using the "Add to product", it does not make sense to list products that were already released and distributed. This makes the UI harder to work with and allows for selecting the wrong product by mistake.
A "released" product is unlikely to get an inventory update. A "lifecycle" field could help to lock a product from future modification. There would always be the possibility to change the direct product fields (in case an actual data mistake needs to be fixed) but this would lock the inventory and importing features, while also excluding the product from listing such as the "Add to product" feature.
Perhaps this can be addressed by enhancing the existing Product Status table, which has been under-utilized.
That could be a possibility, but we have to see the impact on queries since it needs to go through an FK to reach the no_vulnerability_tracking or inventory_changed_allowed potential futures fields.
Some ideas for lifecycle values:
- Planning
- Development
- Beta
- Released
- Maintenance
- Deprecated
- Retired/EOL
See also:
- https://github.com/endoflife-date/endoflife.date
- https://endoflife.date/
- https://github.com/aboutcode-org/purldb/issues/42
- https://tc54.org/cle/
- https://github.com/Ecma-TC54/tg3
CycloneDX lifecycle values: https://cyclonedx.org/docs/1.6/json/#metadata_lifecycles_items_oneOf_i0_phase