Affected Product Information in the CSAF 2.0 Draft Schema

["Omar Santos (osantos)" <osantos@cisco.com>]

Hi folks,

One of the action items from the Oct 31st meeting was to resurrect the discussion about the product information in the CSAF 2.0 draft schema and also to do a comparison with MITREâs CVE schema.

The following is the current MITRE CVE schema:

https://github.com/CVEProject/automation-working-group/blob/master/cve_json_schema/CVE_JSON_4.0_min_public.schema

This is how the product element is structured in the MITRE CVE schema:

"product": {
	"type": "object",
	"required": [ "product_name", "version" ],
	"properties": {
	"product_name": { "type": "string" },
	"version": {
	"type": "object",
	"required": [ "version_data" ],
	"properties": {
	"version_data": {
	"type": "array",
	"minItems": 1,
	"items": {
	"type": "object",
	"required": [ "version_value" ],
	"properties": {
	"version_value": { "type": "string" }
	}
	}
	}
	}

It is very simple and elegant; less complicated that CSAF/CVRF. However, this is mostly because a CSAF/CVRF document can have multiple CVEs (vulnerabilities) and it can also list affected, not affected, patch levels, and other elements.

The following is our current CSAF 2.0 draft schema:

https://github.com/oasis-tcs/csaf/blob/master/sandbox/csaf_2.0/json_schema/csaf_json_schema.json

A vulnerability can have âproduct statusâ

"vulnerability_t": {
	"type": "object",
	"propertyNames": {
	"enum": [
	"acknowledgments",
	"cve",
	"cvss_score_sets",
	"discovery_date",
	"id",
	"involvements",
	"ordinal",
	"notes",
	"product_status",
	"references",
	"release_date",
	"remediations",
	"threats",
	"title"
	]
	},

Then under product_status:

"product_status": {
	"type": "object",
	"properties": {
	"fixed": {
	"$ref": "#/definitions/products_t"
	},
	"first_affected": {
	"$ref": "#/definitions/products_t"
	},
	"known_affected": {
	"$ref": "#/definitions/products_t"
	},
	"known_not_affected": {
	"$ref": "#/definitions/products_t"
	},
	"first_fixed": {
	"$ref": "#/definitions/products_t"
	},
	"recommended": {
	"$ref": "#/definitions/products_t"
	},
	"last_affected": {
	"$ref": "#/definitions/products_t"
	}
	}
	},

Which in my opinion, the values still relevant and we should not change them. My question is more around  the branch_product and the product_tree elements (below): is there an opportunity to simplify them? 

"branch_product_t": {
	"type": "object",
	"properties": {
	"name": {
	"type": "string"
	},
	"type": {
	"type": "string"
	},
	"full_product_name": {
	"$ref": "#/definitions/full_product_name_t"
	}
	}
	},

and

"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
	},

As you can see, the full_product_name has the CPE element/property. As we discussed in the previous meetings, a generic product identification element is more appropriate (which can support any identifier or reference to SWID, SPDX, etc.) I will start that conversation on a separate thread to not mix the two here.

Your thoughts here and during the meeting would be greatly appreciated. 

Regards,


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