What's a good logic to identify the kind of BOM given a json

[prabhu]

As per the project readme, a given JSON document could be of any of the following type:

    Software Bill of Materials (SBOM)
    Software-as-a-Service Bill of Materials (SaaSBOM)
    Hardware Bill of Materials (HBOM)
    Machine Learning Bill of Materials (ML-BOM)
    Cryptography Bill of Materials (CBOM)
    Manufacturing Bill of Materials (MBOM)
    Operations Bill of Materials (OBOM)
    Vulnerability Disclosure Reports (VDR)
    Vulnerability Exploitability eXchange (VEX)
    CycloneDX Attestations (CDXA)

What's a good logic that can be used to identify the type from the contents. Or should the specification have an explicit attribute to define the type and have strict semantic validations around the content?

[jkowalleck]

What I've learned over the past:
There is just no common minimum requirement, that could be used to define each xBOM profile.
If you think you finally define a minimum set, there are a handful of people arguing about it already, for years ;-) Every other organization has their own standards to a xBOM profile.

Some organizations require a PURL for each component of an SBOM, others don't.
Some organizations require a formulation for every component of an MBOM, others require it only for the primary component.
... and so on

[prabhu]

Agreed @jkowalleck. The situation is quite funny at times. People (and vendors) say they support CycloneDX (whole thing), when they really mean a tiny subset of SBOM (just name, version, and purls). May be, we need a way to describe the common minimum requirement for a document to be considered a BOM of a given type?

[stevespringett]

We may be able to leverage the SCVS BOM Maturity Model to describe various levels of CycloneDX support.