From 2cb1a4307b1d0a25f8435208336489f7047999d0 Mon Sep 17 00:00:00 2001 From: tschmidtb51 <65305130+tschmidtb51@users.noreply.github.com> Date: Sat, 25 May 2024 22:54:05 +0200 Subject: [PATCH 1/3] Guidance on CPE pattern - addresses parts of oasis-tcs/csaf#693 - add FAQ regarding usage of the new pattern --- csaf_2.0/guidance/faq.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/csaf_2.0/guidance/faq.md b/csaf_2.0/guidance/faq.md index 3bc3d24c..9f84f4c9 100644 --- a/csaf_2.0/guidance/faq.md +++ b/csaf_2.0/guidance/faq.md @@ -22,6 +22,15 @@ CSAF enables individuals and organizations to successfully disclose and consume Yes. CSAF is the replacement for the [Common Vulnerability Reporting Framework (CVRF)](https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.html). It enhances the capabilities of CVRF including different profiles (e.g., CSAF Base, Informational Advisory, Incident Response, VEX, etc.). Each profile extends the base profile "CSAF Base" - directly or indirect through another profile from the standard - by making additional fields from the standard mandatory. A profile can always add, but never subtract nor overwrite requirements defined in the profile it extends. CSAF also provides several additional enhancements that were not supported in CVRF. In addition, CSAF uses JSON while CVRF used XML. +### There a change in the CPE pattern from CSAF 2.0 to CSAF 2.1. Why? + +The CPE pattern in CSAF 2.0 had two problems: + +1. It allowed invalid CPEs due to the fact of missing brakes. Simplified it stated the pattern `^(CPE2.3)|(CPE2.2)$` instead of `^((CPE2.3)|(CPE2.2))$` which allowed for CPE 2.3 with additional content at the end and CPE 2.2 with additional content as a prefix, i.e. `NOTAVALIDCPEcpe:/o:example:a:42::anyother` is accepted while it is not a valid CPE. +2. Some implementations had issues with unescaped `/` characters in JSON patterns. + +To avoid both problems, is was decided to change the CPE pattern. Tools implementing CSAF 2.0 are allowed to use the CSAF 2.1 CPE regex. This does not impact their state of conformance regarding CSAF 2.0. + ### What is VEX and how is it supported in CSAF? The Vulnerability Exploitability eXchange (VEX) allows a software supplier or other parties to assert the status of specific vulnerabilities in a particular product. CSAF supports VEX to allow suppliers and other parties to provide the status of the vulnerabilities that may affect a product. As stated in [CISA's VEX Use Case documentation](https://www.cisa.gov/sites/default/files/publications/VEX_Use_Cases_Aprill2022.pdf), VEX is a form of a security advisory, similar to those already issued by mature product security teams today. There are a few important improvements for the VEX model over ‘traditional’ security advisories. First, VEX documents are machine readable, built to support integration into existing and novel security management tools, as well as broader vulnerability tracking platforms. Second, VEX data can support more effective use of [Software Bills of Materials (SBOM)](https://www.cisa.gov/sbom) data. From 28bfca7c7526d784033c5b8c2d451c5b3b3e3fb1 Mon Sep 17 00:00:00 2001 From: tschmidtb51 <65305130+tschmidtb51@users.noreply.github.com> Date: Sat, 25 May 2024 23:24:21 +0200 Subject: [PATCH 2/3] CPE pattern - addresses parts of oasis-tcs/csaf#693 - clarify that the pattern was changed in CSAF 2.1 --- csaf_2.0/guidance/faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/csaf_2.0/guidance/faq.md b/csaf_2.0/guidance/faq.md index 9f84f4c9..c17de551 100644 --- a/csaf_2.0/guidance/faq.md +++ b/csaf_2.0/guidance/faq.md @@ -29,7 +29,7 @@ The CPE pattern in CSAF 2.0 had two problems: 1. It allowed invalid CPEs due to the fact of missing brakes. Simplified it stated the pattern `^(CPE2.3)|(CPE2.2)$` instead of `^((CPE2.3)|(CPE2.2))$` which allowed for CPE 2.3 with additional content at the end and CPE 2.2 with additional content as a prefix, i.e. `NOTAVALIDCPEcpe:/o:example:a:42::anyother` is accepted while it is not a valid CPE. 2. Some implementations had issues with unescaped `/` characters in JSON patterns. -To avoid both problems, is was decided to change the CPE pattern. Tools implementing CSAF 2.0 are allowed to use the CSAF 2.1 CPE regex. This does not impact their state of conformance regarding CSAF 2.0. +To avoid both problems, is was decided to change the CPE pattern in CSAF 2.1. Tools implementing CSAF 2.0 are allowed to use the CSAF 2.1 CPE regex. This does not impact their state of conformance regarding CSAF 2.0. ### What is VEX and how is it supported in CSAF? From 85a2c200ea914994cbd915068f0bd9db89a25bd8 Mon Sep 17 00:00:00 2001 From: Stefan Hagen Date: Sun, 26 May 2024 21:28:56 +0200 Subject: [PATCH 3/3] Simplified heading --- csaf_2.0/guidance/faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/csaf_2.0/guidance/faq.md b/csaf_2.0/guidance/faq.md index c17de551..023b3dff 100644 --- a/csaf_2.0/guidance/faq.md +++ b/csaf_2.0/guidance/faq.md @@ -22,7 +22,7 @@ CSAF enables individuals and organizations to successfully disclose and consume Yes. CSAF is the replacement for the [Common Vulnerability Reporting Framework (CVRF)](https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.html). It enhances the capabilities of CVRF including different profiles (e.g., CSAF Base, Informational Advisory, Incident Response, VEX, etc.). Each profile extends the base profile "CSAF Base" - directly or indirect through another profile from the standard - by making additional fields from the standard mandatory. A profile can always add, but never subtract nor overwrite requirements defined in the profile it extends. CSAF also provides several additional enhancements that were not supported in CVRF. In addition, CSAF uses JSON while CVRF used XML. -### There a change in the CPE pattern from CSAF 2.0 to CSAF 2.1. Why? +### The CPE pattern changed from CSAF 2.0 to CSAF 2.1. Why? The CPE pattern in CSAF 2.0 had two problems: