Add inline mapping to SCVS BOM Maturity Model

[stevespringett]

A proposal has been suggested that the CycloneDX specification add native support for the SCVS BOM Maturity Model to the schema itself. This may likely be a JSON-only enhancement, but XML support may be considered.

For example, the definition of a /components/[]/supplier looks like:

"supplier": {
  "title": "Component Supplier",
  "description": " The organization that supplied the component. The supplier may often be the manufacturer, but may also be a distributor or repackager.",
  "$ref": "#/definitions/organizationalEntity"
}

could be enhanced to:

"supplier": {
  "title": "Component Supplier",
  "description": " The organization that supplied the component. The supplier may often be the manufacturer, but may also be a distributor or repackager.",
  "$ref": "#/definitions/organizationalEntity"
  "meta:scvs:version": "1.0",
  "meta:scvs:structure": "urn:owasp:scvs:bom:structure:inventory",
  "meta:scvs:taxonomy": [
    "urn:owasp:scvs:bom:provenance:role:supplier"
    "urn:owasp:scvs:bom:provenance:role:supplier:org",
    "urn:owasp:scvs:bom:provenance:role:supplier:non-org"
  ]
}

By supporting SCVS BOM Maturity Model in the schema itself, this would allow tool makers to leverage the model and have a build-in mapping. This will aid in:

• SBOM quality tools and score calculations
• Make policy and governance easier
  • SCVS profiles could be used together with CycloneDX natively
• Aid in conversions between BOM formats

[Mariuxdeangelo]

Do you plan to map the identifier to certain fields of the SBOM in the schema, or are the SBOM generators adding them?

So, if I initialize the supplier field, is it safe to say that the supplier identifier will always be right here?

Generators might forget to add the identifiers properly or add them in all the wrong places.

Or did I not understand the idea correctly?

[stevespringett]

Do you plan to map the identifier to certain fields of the SBOM in the schema

Yes.

A generator (or any BOM utility) will only need to read the schema if they want to make use of the mapping. SBOM generators will not need to do anything different than they do today. No changes.

But any BOM utility can then optionally make use of the mappings to aid in conversion, policy evaluation, etc.

[mrutkows]

@Mariuxdeangelo I hope to use/add a "meta:scvs" styled key to each data type in the schema (much like added for "meta:enum".

[jkowalleck]

I guess e could even grate an XSD extension that would allow adding these flags to out XSD files ....
Not so sure about the protobuff schema files ...

[stevespringett]

Yeah, not too worried about protobuf. But if we find a way to do this in the XSD, that would be great. If not, the JSON Schema is our reference implementation for the specification and the Ecma standard, so its obviously a priority.

[jkowalleck]

By supporting SCVS BOM Maturity Model in the schema itself, this would allow tool makers to leverage the model and have a build-in mapping.

@stevespringett if we added those markers to a schema, how would this help anybody?
Is there any existing/discrete tool that would read those fields? If there is no such tool yet, where is the spec of such a tool - I mean i could probably come up with some alternatives to this very proposal, so that such a tool would still be functioning ...

I find the proposal waaaay to vague, so I can not see any value in it yet. I would even say it is bloat I would avoid having in the schema files.

[stevespringett]

The CycloneDX SBOM Utility that Matt has created, currently uses Go annotations to do somthing similar. Its very manual however. The idea is to remove the annotations that are specific to the tool, and use the mapping provided by the schema itself. In doing so, other tools would be able to adopt the same approach.

[jkowalleck]

In doing so, other tools would be able to adopt the same approach.

This would require other tools to follow the same annotation style we would come up now.
I don't see that as a desirable way to work for anybody.

---

here is another approaches, which is more versatile in many means:
Somebody provides mapping of each SCVS "flag" to (multiple) actual BOM-document targets in form of JSONPath(JSON and YAML documents), XPATH(XML documents), FieldMask(Protobuf documents).

Such mapping is document centric (not schema- nor specification-centric).
Such mapping would not be part of any schema file, but independent.
Such mapping is portable.
Such mapping is machine readable.

example for CycloneDX JSON:

• urn:owasp:scvs:bom:core:timestamp -> $.metadata.timestamp
• urn:owasp:scvs:bom:resource:software:sbom -> $..externalReferences[?($.type=='bom')].url
• ...

This solution is actually one that the SCVS BOM Maturity Model WorkGroup should have come up with in the first place, since this is the most interoperable way (I can think of) of mapping their "Identifier" to an actual data structure.
This is the relevant part: mapping to data structures, since they should not care for capabilities(schema or specification) but actual SBOM data.

These mappings can be provided by the SCVS community without any need for interaction with SBOM standards working groups, so this makes them even independent.