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