Add flags for product lifecycle

[tschmidtb51]

Currently, we can't efficiently transport the information that a product is End of Life or End of Support. I suggest to remove the lecagy option from the branches_t and create a lifecycle flag in the full_product_name.

The definition could be as follows:

"lifecycle_state": {
            "title": "State of the lifecycle",
            "description": "Describes in which state of the lifecycle the product is.",
            "type": "string",
            "enum": [
              "specification",
              "design",
              "implementation",
              "verification_validation",
              "feature_maintenance",
              "security_maintenance",
              "decommission"
            ]

If anyone has better generic lifecycle states, happy to hear them.

[sthagen]

Could we spare the dash? in other words: would decommission also work? This way, all enumeration values would be valid identifiers in the programming languages I know …

[tschmidtb51]

Could we spare the dash? in other words: would decommission also work? This way, all enumeration values would be valid identifiers in the programming languages I know …

My bad - I updated the suggestion.

[tschmidtb51]

Here are some examples:

Example 1: (not longer supported, aka End of Support / End of Life)

      {
        "product_id": "CSAFPID-0001",
        "name": "Very Old Product A",
        "lifecycle_state": "decommission"
      }

Example 2: (only security updates, but no feature updates anymore)

      {
        "product_id": "CSAFPID-0002",
        "name": "Old Product B",
        "lifecycle_state": "security_maintenance"
      }

Example 3: (Standard, fully operational product)

      {
        "product_id": "CSAFPID-0003",
        "name": "Product C",
        "lifecycle_state": "feature_maintenance"
      }

Example 4: (product is new, currently tested for production)

      {
        "product_id": "CSAFPID-0004",
        "name": "Product D beta",
        "lifecycle_state": "verification_validation"
      }

Example 5: (product is currently being implemented)

      {
        "product_id": "CSAFPID-0005",
        "name": "Product E (test)",
        "lifecycle_state": "implementation"
      }

[tschmidtb51]

Here is a todo list:

• [x] remove legacy
• [x] add new structure lifecycle_state
• [ ] adopt prose
• [ ] add conversion rules
• [ ] adopt committee note draft
• [ ] add test

[sparrell]

I agree with the need and with the concept but not the lifecycle list. How about the list NIST uses in https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf:

• Initiation (concept/requirements definition)
• Development/Acquisition
• Implementation/Assessment
• Operations/Maintenance
• Disposal

Not sure it's better and no clue where the USG got them from but seems if it's good enough for risk management framework, it's good enough for CSAF. I'd prefer something out of CMI SEI or the like but I couldn't find anything.

[sthagen]

if it's good enough for risk management framework, it's good enough for CSAF.

I hope not. The undecided slash versions remind me of and/or undecided perspectives.

The current proposed life cycle list is specific and IMO fits for many product life cycles and esp. nicely separates security from feature maintenance. Another advantage is the understandability.

For CSAF, we have to make up surprisingly many enum values because the market seems to either go esoteric or is not able to agree on good enough terms (I still suffer from the amortized endless vendor vs. supplier discussions spiraling in ether).

[tschmidtb51]

@sparrell I agree with @sthagen here. BTW: The list was derived from IEC62443. Unfortunately, they also didn't separate security from feature maintenance. That was the change I introduced...

I had a quick at the spec by I didn't saw the definitions there... Did I overlook something?

[santosomar]

We discussed this in detail during the monthly TC meeting on 2022-02-23. It was decided that we will address this at a later time and include this in the considerations for CSAF 2.1. This is a very complicated issue to implement by vendors and consumers.

[tschmidtb51]

There are currently some interesting efforts at another OASIS TC OpenEoX, that we hopefully can use: https://github.com/oasis-tcs/openeox/pull/10/files