Re: [csaf] Would CSAF be appropriate for SBOM VEX?

I participated in a meeting with Allan and team several weeks ago. I think that there is definitely a use case to use a CSAF document. I also shared this initiative with the TC in two meetings. The interesting and challenging part is that the VEX meeting is exactly at the same time as the CSAF meeting 😉

We are in the middle of finishing the CSAF 2.0 documentation and hopefully very soon we will have a candidate release. The CSAF 2.0 schema is located at: https://github.com/oasis-tcs/csaf

You can definitely use the product status for a vulnerability as shown below (fixed, known_affected, first_affected, last_affected, known_not_affected, and under_investigation):

"product_status": {
	"title": "Product status",
	"description": "Contains different lists of product_ids which provide details on the status of the referenced product related to the current vulnerability. ",
	"type": "object",
	"minProperties": 1,
	"properties": {
	"fixed": {
	"title": "Fixed",
	"description": "These versions contain a fix for the vulnerability but may not be the recommended fixed versions.",
	"$ref": "#/definitions/products_t"
	},
	"first_fixed": {
	"title": "First fixed",
	"description": "These versions contain the first fix for the vulnerability but may not be the recommended fixed versions.",
	"$ref": "#/definitions/products_t"
	},
	"recommended": {
	"title": "Recommended",
	"description": "These versions have a fix for the vulnerability and are the vendor-recommended versions for fixing the vulnerability.",
	"$ref": "#/definitions/products_t"
	},
	"known_affected": {
	"title": "Known affected",
	"description": "These versions are known to be affected by the vulnerability.",
	"$ref": "#/definitions/products_t"
	},
	"first_affected": {
	"title": "First affected",
	"description": "These are the first versions of the releases known to be affected by the vulnerability.",
	"$ref": "#/definitions/products_t"
	},
	"last_affected": {
	"title": "Last affected",
	"description": "These are the last versions in a release train known to be affected by the vulnerability. Subsequently released versions would contain a fix for the vulnerability.",
	"$ref": "#/definitions/products_t"
	},
	"known_not_affected": {
	"title": "Known not affected",
	"description": "These versions are known not to be affected by the vulnerability.",
	"$ref": "#/definitions/products_t"
	},
	"under_investigation": {
	"title": "Under investigation",
	"description": "It is not known yet whether this version is or is not affected by the vulnerability. However, it is still under investigation - the result will be provided in a later release of the document.",
	"$ref": "#/definitions/products_t"
	}
	}
	},

Regards,

Omar Santos

PSIRT, Security Research and Operations

Cisco Systems

From: <csaf@lists.oasis-open.org> on behalf of "duncan sfractal.com" <duncan@sfractal.com>
Date: Monday, February 8, 2021 at 8:11 PM
To: "csaf@lists.oasis-open.org" <csaf@lists.oasis-open.org>
Cc: "Eliot Lear (elear)" <elear@cisco.com>, "Friedman, Allan" <AFriedman@ntia.gov>, "Jacobson, Jim" <james.jacobson@siemens-healthineers.com>, Jane Harnad <jharnad@oasis-open.org>
Subject: [csaf] Would CSAF be appropriate for SBOM VEX?

I apologize but I havenât been very active in CSAF lately. Iâve been spending more of my time on the software transparency working group set up by the NTIA. See https://www.ntia.gov/sbom for more about software bill of materials (SBOM) or https://www.ntia.gov/SoftwareTransparency for the process we are following.

A particular problem of the SBOM group is communicating that a specific product is not affected/exploitable from a given vulnerability--we are calling this "Vulnerability Exploitability eXchange," or VEX. This will be important to minimize false positives in a world of widespread SBOM use. The SBOM group is looking at CVRF/CSAF for VEX, but has some hesitancy since none of the transparency attendees have CSAF knowledge. We thinkâ CVRF can convey this, but it would be very helpful to have some people who know the standard, and also have input on some more precise definitions and other extensions (e.g. 1. we would like to be more precise on what "not affected" means and 2. make sure suppliers can easily implement or add on integrity mechanisms to these messages). They asked me because I did attend CSAF early on and I am a member of the TC (so Iâm allowed to post to this list). However Iâm too out of touch to be able to help much and Iâm asking if any of you would be able to help. The VEX subgroup meets Wednesdays 1-2 and Iâve included Allan Friedman on the cc. Allan is the overall lead at NTIA for the software transparency effort and he would provide the meeting info if anyone could attend.

I notice that there are companies that are active in both groups, even if there are no individual overlaps. Iâm hoping some of you might get together intracompany and help cross fertilize. I notice that 3 of the 14 voting members of the TC are from Cisco and that Eliot Lear of Cisco (ccâd on this) is very active in SBOM and VEX. Similarly two of voting members are from Siemens - and Jim Jacobson of Siemens cochairs the SBOM Healthcare Working Group (which is very interested in using VEX in the next phase of the proof of concept underway). Similarly many of the companies involved in VEX/SBOM are already OASIS members so I will try to talk them into joining the CSAF TC so the dialog can be two-way and I donât have to play middleman.

Please let Allan and myself know if (1) you think your specifications could help our software transparency needs and if so, (2) who might be able to help us.

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/

csaf message