OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

csaf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [csaf] Generic Software Identification Parameter/Attribute to be included in CSAF 2.0 schema.


Hi Omar,

On Thu, Nov 29, 2018 at 9:14 AM Omar Santos (osantos) <osantos@cisco.com> wrote:
Thank you Eric!Â

I like your suggestion. The main challenge that I was trying to address is that we cannot predict when the next software bill of material (SBOM) standard will be created. If we provide the ability to strictly define cpe, SWID, SPDX, etc, Âwhat happen when the next standard format is created?Â

For instance, the example that Art mentioned around âpurlâ.
https://lists.oasis-open.org/archives/csaf/201811/msg00001.html

I think the standard answer there is simply to add another property, as it is deemed useful. In contrast to XML, where an extra element in a schema creates massive backwards compatibility problems (at least when attempting to validate using XML Schema), merely adding an additional property to a JSON object is pretty much a no-brainer.

Eric.


I was trying to suggest something like:

"standard_product_id": {

"type": "#/cpe/swid/purl/co-swid"
"$ref": "#/definitions/non_empty_string_t"

}

I think that it is basically the same as you are suggesting.

Regards,


Omar Santos
Cisco PSIRT
Email: os@cisco.com
PGP Key: 8E19A9D13AF27EDC




On Nov 29, 2018, at 12:00 PM, Eric Johnson <eric@tibco.com> wrote:

Hi Omar,

Sorry I didn't manage to get off a response to this before our meeting yesterday.

On Tue, Nov 27, 2018 at 5:31 PM Omar Santos (osantos) <osantos@cisco.com> wrote:
This is to continue the discussion related to aÂGeneric Software Identification Parameter/Attribute to be included in CSAF 2.0 schema.

The following is the current CSAF 2.0 draft schema:


Under full_product_name there is a CPE property. Replacing CPE for âstandard_product_identifierâ (or similar) may be the best place. Then the $ref: could be to a pointer to a SWID, CO-SWID, SPDX, etc docâ Thoughts or suggestions?

Due to the expectations and processing model behind JSON, I don't see the need or value to be generic. Put differently, in a JSON instance, the product definition could have a property for cpe, swid, spdx. The JSON schema could then more readily validate the corresponding value the property with a regular _expression_ match, at least. That also gives us the freedom, in some ideal future, to decide that one of these properties might be required, while the others could continue to be optional.

So instead of having "standard_product_identifier" as a property, and then have the implementation required to distinguish the kind of identifier based on the value, why not have "cpe", "swid", "co_swid", "spdx" as distinct properties?

Eric.
Â


"full_product_name_t": {
"type": "object",
"required": [
"product_id",
"text"
],
"properties": {
"product_id": {
"$ref": "#/definitions/non_empty_string_t"
},
"text": {
"$ref": "#/definitions/non_empty_string_t"
},
"cpe": {
"$ref": "#/definitions/non_empty_string_t"
}
}
},
"non_empty_string_t": {
"type": "string",
"minLength": 1
},







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]