Hi Allan,
There are indeed several minimum/required fields in the current CVRF standard, as well as the new CSAF 2.0 specification working draft. However, a vulnerability is not a required field.
One of the use cases for CSAF is to be able to still publish a âsecurity advisoryâ (the âSAâ in CSAF), even if the âissueâ addressed in such document is not a vulnerability or have an assigned CVE. For example, a vendor or any organization can potentially
use a CSAF document to respond to an industry event or âfalse positiveâ/allegation of a vulnerability. On the other hand, the main use case (of course) is to disclose vulnerabilities and their impact to products (software and hardware) or cloud services.
From: Friedman, Allan <
AFriedman@ntia.gov>
Sent: Tuesday, February 9, 2021 2:02 PM
To: Omar Santos (osantos); duncan sfractal.com;
csaf@lists.oasis-open.org Cc: Eliot Lear (elear); Jacobson, Jim; Jane Harnad
Subject: Re: [csaf] Would CSAF be appropriate for SBOM VEX?
Thanks, Omar!
One important question has been around the use of the term "affected." I think we are interested in
Defining "not affected" wrt assertions of non-exploitability. For example, a vulnerable library may be called, but the vulnerable function isn't loaded, etc.
Q: Does this align with how you have thought about "affected" and "not affected"?
Having a small set mutually-exclusive set of categories at a high level: known_affected, known_not_affected, under_investigation
Most of the examples we have thought about for VEX could be captured by these three categories. Q: are we missing anything here? How do you think of overlap for things like first/last known, fixed, etc? Beyond this, the community may be interested in defining further flags to allow communitcation of more details.
Another question is around a "minimum viable" CSAF implementation? We're interested in a mapping of <product, vulnerability, status> as a minimum VEX use case.
Thanks,
allan
From: Omar Santos (osantos) <
osantos@cisco.com>
Sent: Monday, February 8, 2021 8:26 PM
To: duncan sfractal.com <
duncan@sfractal.com>;
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: 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 /