From 495e04fbdf43693365a4106c88b6540ccd6a1397 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Tue, 10 Sep 2024 15:59:46 -0700 Subject: [PATCH 01/17] CSAF Guidance --- .idea/.gitignore | 3 ++ .idea/misc.xml | 6 +++ .idea/modules.xml | 8 ++++ .idea/security-data-guidelines.iml | 9 +++++ .idea/vcs.xml | 6 +++ docs/CSAF.md | 61 ++++++++++++++++++++++++++++++ 6 files changed, 93 insertions(+) create mode 100644 .idea/.gitignore create mode 100644 .idea/misc.xml create mode 100644 .idea/modules.xml create mode 100644 .idea/security-data-guidelines.iml create mode 100644 .idea/vcs.xml create mode 100644 docs/CSAF.md diff --git a/.idea/.gitignore b/.idea/.gitignore new file mode 100644 index 0000000..26d3352 --- /dev/null +++ b/.idea/.gitignore @@ -0,0 +1,3 @@ +# Default ignored files +/shelf/ +/workspace.xml diff --git a/.idea/misc.xml b/.idea/misc.xml new file mode 100644 index 0000000..639900d --- /dev/null +++ b/.idea/misc.xml @@ -0,0 +1,6 @@ + + + + + + \ No newline at end of file diff --git a/.idea/modules.xml b/.idea/modules.xml new file mode 100644 index 0000000..8108c98 --- /dev/null +++ b/.idea/modules.xml @@ -0,0 +1,8 @@ + + + + + + + + \ No newline at end of file diff --git a/.idea/security-data-guidelines.iml b/.idea/security-data-guidelines.iml new file mode 100644 index 0000000..d6ebd48 --- /dev/null +++ b/.idea/security-data-guidelines.iml @@ -0,0 +1,9 @@ + + + + + + + + + \ No newline at end of file diff --git a/.idea/vcs.xml b/.idea/vcs.xml new file mode 100644 index 0000000..35eb1dd --- /dev/null +++ b/.idea/vcs.xml @@ -0,0 +1,6 @@ + + + + + + \ No newline at end of file diff --git a/docs/CSAF.md b/docs/CSAF.md new file mode 100644 index 0000000..3f486f1 --- /dev/null +++ b/docs/CSAF.md @@ -0,0 +1,61 @@ +# Red Hat CSAF-VEX Advisories + +## Red Hat Security Data Overview +Red Hat has always been committed to providing our customers and partners with complete and accurate security data for +all Red Hat software. In the past, Red Hat published security advisory information using Common Vulnerability Reporting +Framework (CVRF) and CVE information using the Open Vulnerability and Assessment Language (OVAL) format. Over the last +few years, the Common Security Advisory Framework (CSAF) 2.0 standard was published and is now the successor to the +CVRF version 1.2 as there are many enhancements to the information provided in each CSAF file. + +On February 1st, 2023, Red Hat first announced the general availability of CSAF 2.0 documents. This version of our CSAF +files are published using the VEX profile (Vulnerability Exploitability eXchange) and the document type is now known as +csaf_vex. Since then Red Hat has continued to make improvements to our published security data, including the GA release +of our VEX files on July 10th, 2024. While publishing our CSAF files was extremely helpful for correlating security data +to individual advisories, we began publishing VEX files to make it easier for our partners and customers to correlate +both fixed and unfixed security information to an individual CVE. Additionally, the publication of our VEX files +announced the deprecation of our previously published OVAL data, which did not provide the same level of detailed +security information. + +Currently, Red Hat Product Security publishes CSAF advisories for every single Red Hat security advisory and VEX files +for every single CVE record that is associated with the Red Hat portfolio in any way. + +## Red Hat and CSAF/VEX +### CSAF Overview +The Common Security Advisory Framework (CSAF) was originally published as an open standard by OASIS Open in November 2022. +CSAF files provide a standard structured, machine-readable way of representing and sharing security advisory information +across all software and hardware providers. + +Our CSAF files are always associated with one specific advisory and a given advisory may include one or more product +version(s) and one or more components, depending on the product type and update scope. The advisory itself can also +include updates to address one or more vulnerabilities. Red Hat’s CSAF files are publicly available per advisory at +https://access.redhat.com/security/data/csaf/v2/advisories. + +### VEX Overview +[Vex profile info] +The CSAF standard acknowledges the need for different use cases and has therefore defined a variety of profiles. Each +profile describes the necessary fields and information needed for a specific use case. Red Hat has adopted the +Vulnerability Exploitability eXchange (VEX) profile, which is intended to provide the affected state of a vulnerability +on a product or component. + +Red Hat's VEX files are always associated with one CVE and include fix status information for all vulnerable packages and +Red Hat products. Red Hat’s VEX files are publicly available per CVE at +https://access.redhat.com/security/data/csaf/v2/vex/. + +## Document Structure +Although both CSAF and VEX files ultimately serve different purposes, both CSAF and VEX files meet the +CSAF machine readable standard and use the VEX profile to convey security information. The CSAF-VEX standard includes +three main sections: document metadata, a product tree array and vulnerability metadata. + +### Document Metadata + + +### Product Tree + + +### Vulnerability Metadata + + + +## Technical Guidance on Adopting CSAF/VEX + +## Additional Notes From 8f7b2cc3d665aa37da62e770736f06830a517ec8 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Wed, 18 Sep 2024 09:12:28 -0700 Subject: [PATCH 02/17] Adding csaf vex --- docs/CSAF.md | 61 ---------------------- docs/csaf-vex.md | 133 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 133 insertions(+), 61 deletions(-) delete mode 100644 docs/CSAF.md create mode 100644 docs/csaf-vex.md diff --git a/docs/CSAF.md b/docs/CSAF.md deleted file mode 100644 index 3f486f1..0000000 --- a/docs/CSAF.md +++ /dev/null @@ -1,61 +0,0 @@ -# Red Hat CSAF-VEX Advisories - -## Red Hat Security Data Overview -Red Hat has always been committed to providing our customers and partners with complete and accurate security data for -all Red Hat software. In the past, Red Hat published security advisory information using Common Vulnerability Reporting -Framework (CVRF) and CVE information using the Open Vulnerability and Assessment Language (OVAL) format. Over the last -few years, the Common Security Advisory Framework (CSAF) 2.0 standard was published and is now the successor to the -CVRF version 1.2 as there are many enhancements to the information provided in each CSAF file. - -On February 1st, 2023, Red Hat first announced the general availability of CSAF 2.0 documents. This version of our CSAF -files are published using the VEX profile (Vulnerability Exploitability eXchange) and the document type is now known as -csaf_vex. Since then Red Hat has continued to make improvements to our published security data, including the GA release -of our VEX files on July 10th, 2024. While publishing our CSAF files was extremely helpful for correlating security data -to individual advisories, we began publishing VEX files to make it easier for our partners and customers to correlate -both fixed and unfixed security information to an individual CVE. Additionally, the publication of our VEX files -announced the deprecation of our previously published OVAL data, which did not provide the same level of detailed -security information. - -Currently, Red Hat Product Security publishes CSAF advisories for every single Red Hat security advisory and VEX files -for every single CVE record that is associated with the Red Hat portfolio in any way. - -## Red Hat and CSAF/VEX -### CSAF Overview -The Common Security Advisory Framework (CSAF) was originally published as an open standard by OASIS Open in November 2022. -CSAF files provide a standard structured, machine-readable way of representing and sharing security advisory information -across all software and hardware providers. - -Our CSAF files are always associated with one specific advisory and a given advisory may include one or more product -version(s) and one or more components, depending on the product type and update scope. The advisory itself can also -include updates to address one or more vulnerabilities. Red Hat’s CSAF files are publicly available per advisory at -https://access.redhat.com/security/data/csaf/v2/advisories. - -### VEX Overview -[Vex profile info] -The CSAF standard acknowledges the need for different use cases and has therefore defined a variety of profiles. Each -profile describes the necessary fields and information needed for a specific use case. Red Hat has adopted the -Vulnerability Exploitability eXchange (VEX) profile, which is intended to provide the affected state of a vulnerability -on a product or component. - -Red Hat's VEX files are always associated with one CVE and include fix status information for all vulnerable packages and -Red Hat products. Red Hat’s VEX files are publicly available per CVE at -https://access.redhat.com/security/data/csaf/v2/vex/. - -## Document Structure -Although both CSAF and VEX files ultimately serve different purposes, both CSAF and VEX files meet the -CSAF machine readable standard and use the VEX profile to convey security information. The CSAF-VEX standard includes -three main sections: document metadata, a product tree array and vulnerability metadata. - -### Document Metadata - - -### Product Tree - - -### Vulnerability Metadata - - - -## Technical Guidance on Adopting CSAF/VEX - -## Additional Notes diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md new file mode 100644 index 0000000..e24ac11 --- /dev/null +++ b/docs/csaf-vex.md @@ -0,0 +1,133 @@ +# Red Hat CSAF-VEX Advisories + +## Red Hat Security Data Overview +The Red Hat Product Security was originally founded in 2001 and has always been committed to providing our customers +and partners with complete and accurate security data for all Red Hat software. In the past, Red Hat published security +advisory information using Common Vulnerability Reporting Framework (CVRF) and CVE information using the Open +Vulnerability and Assessment Language (OVAL) format. Over the last few years, the Common Security Advisory Framework +(CSAF) 2.0 standard was published and is now the successor to the CVRF version 1.2 as there are many enhancements to the +information provided in each CSAF file. + +On February 1st, 2023, Red Hat first announced the general availability of CSAF 2.0 documents. This version of our CSAF +files are published using the VEX profile (Vulnerability Exploitability eXchange) and the document type is now known as +csaf_vex. Since then Red Hat has continued to make improvements to our published security data, including the GA release +of our VEX files on July 10th, 2024. While publishing our CSAF files was extremely helpful for correlating security data +to individual advisories, we began publishing VEX files to make it easier for our partners and customers to correlate +both fixed and unfixed security information to an individual CVE. Additionally, the publication of our VEX files +announced the deprecation of our previously published OVAL data, which did not provide the same level of detailed +security information. + +Currently, Red Hat Product Security publishes CSAF advisories for every single Red Hat security advisory and VEX files +for every single CVE record that is associated with the Red Hat portfolio in any way. + +## Red Hat and CSAF/VEX +### CSAF Overview +The Common Security Advisory Framework (CSAF) was originally published as an open standard by OASIS Open in November 2022. +CSAF files provide a structured, machine-readable way of representing and sharing security advisory information +across all software and hardware providers. + +Red Hat's CSAF files are always associated with one specific advisory and a given advisory may include one or more product +version(s) and one or more components, depending on the product type and update scope. The advisory itself can also +include updates to address one or more vulnerabilities. Red Hat’s CSAF files are publicly available per advisory +[here](https://access.redhat.com/security/data/csaf/v2/advisories). + +### VEX Overview +The CSAF standard acknowledges the need for different use cases and has therefore defined a variety of profiles. +Each profile describes the necessary fields and information needed for that specific use case. Red Hat has adopted the +Vulnerability Exploitability eXchange (VEX) profile, which is intended to provide the affected state of a vulnerability +on a product or component. + +Red Hat's VEX files are always associated with one CVE and include fix status information for all vulnerable packages +and Red Hat products. Red Hat’s VEX files are publicly available per CVE +[here](https://access.redhat.com/security/data/csaf/v2/vex/). + +## Document Structure +Although CSAF and VEX files ultimately serve different purposes, both CSAF and VEX files meet the +CSAF machine readable standard and use the VEX profile to convey security information. The CSAF-VEX standard includes +three main sections: document metadata, a product tree array and vulnerability metadata. The full document structure can +be found here [insert link]. + +### Document Metadata +The "document_metadata" section contains general information about the published document itself +including CVE severity, vendor, published date and revision history. + +General CVE Severity: + +``` +"aggregate_severity": { +"namespace": "https://access.redhat.com/security/updates/classification/", +"text": "moderate" +}, +``` + +CVE ID, publish date, and last update: + +``` +"id": "CVE-2022-1247", +"initial_release_date": "2022-05-11T09:37:00+00:00", +"revision_history": [ +{ +"date": "2022-05-11T09:37:00+00:00", +"number": "1", +"summary": "Initial version" +}, +{ +"date": "2023-09-19T14:13:41+00:00", +"number": "2", +"summary": "Current version" +} +``` + +### Product Tree +The “product_tree” section identifies all affected Red Hat software, represents the nested +relationship of component to product and provides CPEs or PURLs depending on the affected layer. There are two main +objects in the “product_tree” object; “branches” and “relationships”. + +#### Branches + +The "product_family" category represents a general Red Hat product stream. The following information is included: +``` +``` + +The "product_name" category includes information about a specific Red Hat product version. The following information is +included: + +``` +``` + +The "product_version" category includes information about a specific affected package. The following information is +included: +``` +``` + +#### Relationships +Also included in the "product_tree" section is a "relationships" object which is used by Red Hat to help represent layered +products. A relationship entry will be present for all "product_version" objects found in the "product_tree" object. +All of these nested objects are of the “default_component_of” category and include: + +``` +``` + + +### Vulnerability Metadata +The "vulnerability_metadata" section reports vulnerability fix status for any "product_id" listed in the product_tree. +The following fix statuses are available: + +* Fixed: Contains the same fixed component versions and other details (product_tree objects) that the CSAF advisory +reports for that CVE +* Known Affected: Confirmation that the specific component and product is affected by a particular CVE +* Known Not Affected: Confirmation that the specific component and product is not affected by a particular CVE +* Under Investigation: Information that the Red Hat Product Security team is verifying the applicability and impact of +a specific CVE to the specific component and product + +``` +``` + +For all the product_ids found in the “Fixed” array, these will also be listed in the “remediations” +array, which correlates each product_id to the correct RHSAs. The RHSA can be determined by the “url” field in the same +remediation object. + + +## Additional Notes +https://www.redhat.com/en/about/brand/standards/history +https://www.redhat.com/en/blog/20-years-red-hat-product-security-inception-customer-experience From c00ff78d9d4b35295e46418198d99ddaae244b35 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Thu, 19 Sep 2024 08:12:10 -0700 Subject: [PATCH 03/17] Examples added --- docs/csaf-vex.md | 160 ++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 132 insertions(+), 28 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index e24ac11..aa22bd9 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -44,38 +44,82 @@ and Red Hat products. Red Hat’s VEX files are publicly available per CVE ## Document Structure Although CSAF and VEX files ultimately serve different purposes, both CSAF and VEX files meet the CSAF machine readable standard and use the VEX profile to convey security information. The CSAF-VEX standard includes -three main sections: document metadata, a product tree array and vulnerability metadata. The full document structure can +three main sections: document metadata, a product tree and vulnerability metadata. The full document structure can be found here [insert link]. +The next sections break down each section of the document using the +[VEX file for CVE-2023-20593](https://access.redhat.com/security/data/csaf/v2/vex/2023/cve-2023-20593.json). + ### Document Metadata -The "document_metadata" section contains general information about the published document itself -including CVE severity, vendor, published date and revision history. +The "document" section contains general information about the published document itself including CVE severity, vendor, +published date and revision history. General CVE Severity: ``` "aggregate_severity": { -"namespace": "https://access.redhat.com/security/updates/classification/", -"text": "moderate" + "namespace": "https://access.redhat.com/security/updates/classification/", + "text": "moderate" }, ``` -CVE ID, publish date, and last update: +VEX Metadata: + +``` +"category": "csaf_vex", +"csaf_version": "2.0", +"distribution": { + "text": "Copyright © Red Hat, Inc. All rights reserved.", + "tlp": { + "label": "WHITE", + "url": "https://www.first.org/tlp/" + } +}, +"lang": "en", +"notes": [ + { + "category": "legal_disclaimer", + "text": "This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original.", + "title": "Terms of Use" + } +], +``` + +Vendor information: +``` +"publisher": { + "category": "vendor", + "contact_details": "https://access.redhat.com/security/team/contact/", + "issuing_authority": "Red Hat Product Security is responsible for vulnerability handling across all Red Hat offerings.", + "name": "Red Hat Product Security", + "namespace": "https://www.redhat.com" +}, +``` + +CVE ID, CVE publish date and CVE revision history: ``` "id": "CVE-2022-1247", "initial_release_date": "2022-05-11T09:37:00+00:00", "revision_history": [ -{ -"date": "2022-05-11T09:37:00+00:00", -"number": "1", -"summary": "Initial version" -}, -{ -"date": "2023-09-19T14:13:41+00:00", -"number": "2", -"summary": "Current version" -} + { + "date": "2022-05-11T09:37:00+00:00", + "number": "1", + "summary": "Initial version" + }, + { + "date": "2023-09-19T14:13:41+00:00", + "number": "2", + "summary": "Current version" + }, + { + "date": "2024-08-20T07:48:38+00:00", + "number": "3", + "summary": "Last generated version" + } +], +"status": "final", +"version": "3" ``` ### Product Tree @@ -85,33 +129,93 @@ objects in the “product_tree” object; “branches” and “relationships” #### Branches -The "product_family" category represents a general Red Hat product stream. The following information is included: -``` -``` +The parent "branches" object includes nested objects of three subcategories: "product_family", "product_name" and +"product_version". The "product_family" category represents a general Red Hat product stream and +includes one or more nested objects with the "product_name" category that represent an individual release. The +"product_name" object will always include the name of the product, a product ID and a product identification helper in +the form of a CPE. -The "product_name" category includes information about a specific Red Hat product version. The following information is -included: +In the example below, you can see that the "product_family" object is for Red Hat Enterprise Linux 9 and nested within +is the "product_name" object Red Hat Enterprise Linux 9. ``` +{ + "branches": [ + { + "category": "product_name", + "name": "Red Hat Enterprise Linux 9", + "product": { + "name": "Red Hat Enterprise Linux 9", + "product_id": "red_hat_enterprise_linux_9", + "product_identification_helper": { + "cpe": "cpe:/o:redhat:enterprise_linux:9" + } + } + } + ], + "category": "product_family", + "name": "Red Hat Enterprise Linux 9" +}, ``` -The "product_version" category includes information about a specific affected package. The following information is -included: +The "product_version" category includes information about a specific affected package. The "product_name" object will +always include the name of the component, a product ID and a product identification helper in the form of a PURL. The +example below represents the affected component kernel. + ``` +{ + "category": "product_version", + "name": "kernel", + "product": { + "name": "kernel", + "product_id": "kernel", + "product_identification_helper": { + "purl": "pkg:rpm/redhat/kernel?arch=src" + } + } +}, ``` #### Relationships -Also included in the "product_tree" section is a "relationships" object which is used by Red Hat to help represent layered -products. A relationship entry will be present for all "product_version" objects found in the "product_tree" object. -All of these nested objects are of the “default_component_of” category and include: +Also included in the "product_tree" section is a "relationships" object which is used by Red Hat to help represent +layered products. One or more relationship entries will be present for all "product_version" objects found in the +"branches" object. All of these nested objects are of the “default_component_of” category and include the full product +name and product id (a combination of the "product_name" and the "product_version"), a reference to the component name +and a reference to the product name. + +Continuing with the previous examples, we know that there should be at least one entry in the "relationships" object +that correlates to the "product_version" object for kernel. Looking at the VEX file, there are actually four entries for +kernel, all which relate to the different "product_name" objects from before. The below is the specific entry as it +relates to Red Hat Enterprise Linux 9. + +Here you can see that the "full_product_name" includes a name and a product_id which are the combination of the product, +Red Hat Enterprise Linux 9, and the component, kernel. The "product_reference" will always refer to the component's name +while the "relates_to_product_reference" will refer to the product name. ``` +{ +"category": "default_component_of", +"full_product_name": { + "name": "kernel as a component of Red Hat Enterprise Linux 9", + "product_id": "red_hat_enterprise_linux_9:kernel" + }, + "product_reference": "kernel", + "relates_to_product_reference": "red_hat_enterprise_linux_9" +}, ``` ### Vulnerability Metadata -The "vulnerability_metadata" section reports vulnerability fix status for any "product_id" listed in the product_tree. -The following fix statuses are available: + +The "vulnerabilities" section reports vulnerability metadata for any CVEs included in the document and also contains a +"product_status" object that reports fix status for any "product_id" listed in the "product_tree". + +CVE Information: +``` + +``` + +The "product_status" includes the following fix statuses: * Fixed: Contains the same fixed component versions and other details (product_tree objects) that the CSAF advisory reports for that CVE From f07eafbfcd5c9c025590d3ab68132524d2a5c6f1 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Thu, 19 Sep 2024 08:28:55 -0700 Subject: [PATCH 04/17] Examples added --- docs/csaf-vex.md | 110 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 108 insertions(+), 2 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index aa22bd9..fd020ed 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -210,9 +210,76 @@ while the "relates_to_product_reference" will refer to the product name. The "vulnerabilities" section reports vulnerability metadata for any CVEs included in the document and also contains a "product_status" object that reports fix status for any "product_id" listed in the "product_tree". -CVE Information: +CVE ID, CWE and Publication Date: +``` +"cve": "CVE-2022-1247", + "cwe": { + "id": "CWE-366", + "name": "Race Condition within a Thread" + }, + "discovery_date": "2022-03-22T00:00:00+00:00", ``` +CVE Description, Summary and Statement: +``` +"notes": [ + { + "category": "description", + "text": "An issue found in linux-kernel that leads to a race condition in rose_connect(). The rose driver uses rose_neigh->use to represent how many objects are using the rose_neigh. When a user wants to delete a rose_route via rose_ioctl(), the rose driver calls rose_del_node() and removes neighbours only if their “count” and “use” are zero.", + "title": "Vulnerability description" + }, + { + "category": "summary", + "text": "kernel: A race condition bug in rose_connect()", + "title": "Vulnerability summary" + }, + { + "category": "other", + "text": "There was no shipped kernel version that was seen affected by this problem. These files are not built in our source code.", + "title": "Statement" + }, + { + "category": "general", + "text": "The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.", + "title": "CVSS score applicability" + } +], +``` + +CVSS Score and Severity: +``` +"scores": [ + { + "cvss_v3": { + "attackComplexity": "LOW", + "attackVector": "LOCAL", + "availabilityImpact": "HIGH", + "baseScore": 7.8, + "baseSeverity": "HIGH", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "privilegesRequired": "LOW", + "scope": "UNCHANGED", + "userInteraction": "NONE", + "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", + "version": "3.1" + }, + "products": [ + "red_hat_enterprise_linux_9:kernel", + "red_hat_enterprise_linux_9:kernel-rt" + ] + } +], +"threats": [ + { + "category": "impact", + "details": "Moderate", + "product_ids": [ + "red_hat_enterprise_linux_9:kernel", + "red_hat_enterprise_linux_9:kernel-rt" + ] + } +], ``` The "product_status" includes the following fix statuses: @@ -225,13 +292,52 @@ reports for that CVE a specific CVE to the specific component and product ``` +"product_status": { + "known_affected": [ + "red_hat_enterprise_linux_9:kernel", + "red_hat_enterprise_linux_9:kernel-rt" + ], + "known_not_affected": [ + "red_hat_enterprise_linux_6:kernel", + "red_hat_enterprise_linux_7:kernel", + "red_hat_enterprise_linux_7:kernel-rt", + "red_hat_enterprise_linux_8:kernel", + "red_hat_enterprise_linux_8:kernel-rt" + ] +}, ``` - For all the product_ids found in the “Fixed” array, these will also be listed in the “remediations” array, which correlates each product_id to the correct RHSAs. The RHSA can be determined by the “url” field in the same remediation object. +Additional CVE Resources: +``` +"references": [ + { + "category": "self", + "summary": "Canonical URL", + "url": "https://access.redhat.com/security/cve/CVE-2022-1247" + }, + { + "category": "external", + "summary": "RHBZ#2066799", + "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2066799" + }, + { + "category": "external", + "summary": "https://www.cve.org/CVERecord?id=CVE-2022-1247", + "url": "https://www.cve.org/CVERecord?id=CVE-2022-1247" + }, + { + "category": "external", + "summary": "https://nvd.nist.gov/vuln/detail/CVE-2022-1247", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1247" + } +], +``` + + ## Additional Notes https://www.redhat.com/en/about/brand/standards/history https://www.redhat.com/en/blog/20-years-red-hat-product-security-inception-customer-experience From 61287cb338f75ea17ac45a7bdd15b966cce0a731 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Thu, 19 Sep 2024 08:48:52 -0700 Subject: [PATCH 05/17] Added json structure and scanning vendor page --- docs/csaf-vex.json | 217 +++++++++++++++++++++++++++++++++++++++ docs/csaf-vex.md | 2 +- docs/scanning-vendors.md | 11 ++ 3 files changed, 229 insertions(+), 1 deletion(-) create mode 100644 docs/csaf-vex.json create mode 100644 docs/scanning-vendors.md diff --git a/docs/csaf-vex.json b/docs/csaf-vex.json new file mode 100644 index 0000000..5a19db6 --- /dev/null +++ b/docs/csaf-vex.json @@ -0,0 +1,217 @@ +{ + "document": { + "aggregate_severity": { + "namespace": "https://access.redhat.com/security/updates/classification/", + "text": "" + }, + "category": "csaf_vex", + "csaf_version": "2.0", + "distribution": { + "text": "Copyright © Red Hat, Inc. All rights reserved.", + "tlp": { + "label": "WHITE", + "url": "https://www.first.org/tlp/" + } + }, + "lang": "en", + "notes": [ + { + "category": "legal_disclaimer", + "text": "This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original.", + "title": "Terms of Use" + } + ], + "publisher": { + "category": "vendor", + "contact_details": "https://access.redhat.com/security/team/contact/", + "issuing_authority": "Red Hat Product Security is responsible for vulnerability handling across all Red Hat offerings.", + "name": "Red Hat Product Security", + "namespace": "https://www.redhat.com" + }, + "references": [ + { + "category": "self", + "summary": "Canonical URL", + "url": "" + } + ], + "title": "", + "tracking": { + "current_release_date": "", + "generator": { + "date": "", + "engine": { + "name": "", + "version": "" + } + }, + "id": "", + "initial_release_date": "", + "revision_history": [ + { + "date": "", + "number": "", + "summary": "" + } + ], + "status": "", + "version": "" + } + }, + "product_tree": { + "branches": [ + { + "branches": [ + { + "branches": [ + { + "category": "product_name", + "name": "", + "product": { + "name": "", + "product_id": "", + "product_identification_helper": { + "cpe": "" + } + } + } + ], + "category": "product_family", + "name": "Red Hat Enterprise Linux 6" + }, + { + "category": "product_version", + "name": "kernel", + "product": { + "name": "kernel", + "product_id": "kernel", + "product_identification_helper": { + "purl": "pkg:rpm/redhat/kernel?arch=src" + } + } + }, + ], + "category": "vendor", + "name": "Red Hat" + } + ], + "relationships": [ + { + "category": "default_component_of", + "full_product_name": { + "name": "", + "product_id": "" + }, + "product_reference": "", + "relates_to_product_reference": "" + } + ] + }, + "vulnerabilities": [ + { + "acknowledgments": [ + { + "names": [ + + ] + } + ], + "cve": "", + "cwe": { + "id": "", + "name": "" + }, + "discovery_date": "", + "flags": [ + { + "label": "", + "product_ids": [ + ] + } + ], + "ids": [ + { + "system_name": "Red Hat Bugzilla ID", + "text": "" + } + ], + "notes": [ + { + "category": "description", + "text": "", + "title": "Vulnerability description" + }, + { + "category": "summary", + "text": "", + "title": "Vulnerability summary" + }, + { + "category": "other", + "text": "", + "title": "Statement" + }, + { + "category": "general", + "text": "", + "title": "CVSS score applicability" + } + ], + "product_status": { + "fixed": [ + ], + "known_affected": [ + ], + "known_not_affected": [ + ], + "under_investigation": [ + ] + }, + "references": [ + { + "category": "self", + "summary": "Canonical URL", + "url": "" + } + ], + "release_date": "", + "remediations": [ + { + "category": "", + "details": "", + "product_ids": [ + ] + } + ], + "scores": [ + { + "cvss_v3": { + "attackComplexity": "", + "attackVector": "", + "availabilityImpact": "", + "baseScore": , + "baseSeverity": "", + "confidentialityImpact": "", + "integrityImpact": "", + "privilegesRequired": "", + "scope": "", + "userInteraction": "", + "vectorString": "", + "version": "3.1" + }, + "products": [ + ] + } + ], + "threats": [ + { + "category": "impact", + "details": "", + "product_ids": [ + ] + } + ], + "title": "" + } + ] +} \ No newline at end of file diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index fd020ed..24fc6bf 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -48,7 +48,7 @@ three main sections: document metadata, a product tree and vulnerability metadat be found here [insert link]. The next sections break down each section of the document using the -[VEX file for CVE-2023-20593](https://access.redhat.com/security/data/csaf/v2/vex/2023/cve-2023-20593.json). +[VEX file for CVE-2022-1247](https://access.redhat.com/security/data/csaf/v2/vex/2022/cve-2022-1247.json). ### Document Metadata The "document" section contains general information about the published document itself including CVE severity, vendor, diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md new file mode 100644 index 0000000..f2d7071 --- /dev/null +++ b/docs/scanning-vendors.md @@ -0,0 +1,11 @@ +# Vulnerability Scanning and CSAF/VEX + +## Red Hat's Vulnerability Scanning Certification Program +### Overview +### Certification Requirements + +## Technical Guidance on CSAF/VEX Adoption for Vendors + +## Additional Notes +https://www.redhat.com/en/about/brand/standards/history +https://www.redhat.com/en/blog/20-years-red-hat-product-security-inception-customer-experience From 9d6ed80b877c54f85dac97bda1d8b634ddac2faa Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Thu, 19 Sep 2024 09:24:53 -0700 Subject: [PATCH 06/17] Scanning vendor updates --- .DS_Store | Bin 0 -> 6148 bytes docs/csaf-vex.md | 3 ++- docs/scanning-vendors.md | 52 ++++++++++++++++++++++++++++++++++++--- 3 files changed, 50 insertions(+), 5 deletions(-) create mode 100644 .DS_Store diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..8781dea3faf648dcc41d6e3543567efd2f555ace GIT binary patch literal 6148 zcmeHK!D_=W43)MN!glF#M<4bB{R6LLuzP->B!TUa;zHTouz%~JU$rMo8wm@$b_ZqAZA*7hN|tc?D$2F&z7`OKHU5T139RqJa|ibew+w zw{d*kw0+ti%8piio(Akw({y9%V5@hJ?cK-A>1pmCe)S*Trnv(`U7P`Dz!`7`oPkR- zVAphgf9Zuhzcb(rTpa^)J_IzuXqXkt(Sfd%0Kf|7BG9FlkeFZ?4YMLV5Y|wjhO(6y ztl_W+n->kUqJ|S&@xiw8SMkDSb>t6aI&oC=-WhNP<_z5Ga4q-$Gk%%HB7Yv@BWJ)F z_-71o)wInPo3gw0$M)o|4QM+w5t)}ofk2-<0x*zssSY L5bvCUKVaY!a_KAs literal 0 HcmV?d00001 diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 24fc6bf..6f9fc1d 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -45,7 +45,8 @@ and Red Hat products. Red Hat’s VEX files are publicly available per CVE Although CSAF and VEX files ultimately serve different purposes, both CSAF and VEX files meet the CSAF machine readable standard and use the VEX profile to convey security information. The CSAF-VEX standard includes three main sections: document metadata, a product tree and vulnerability metadata. The full document structure can -be found here [insert link]. +be found +[here](https://github.com/RedHatProductSecurity/security-data-guidelines/blob/csaf-vex-guidelines/docs/csaf-vex.json). The next sections break down each section of the document using the [VEX file for CVE-2022-1247](https://access.redhat.com/security/data/csaf/v2/vex/2022/cve-2022-1247.json). diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md index f2d7071..0658ccc 100644 --- a/docs/scanning-vendors.md +++ b/docs/scanning-vendors.md @@ -1,11 +1,55 @@ # Vulnerability Scanning and CSAF/VEX ## Red Hat's Vulnerability Scanning Certification Program -### Overview -### Certification Requirements +The Red Hat Vulnerability Scanner Certification is a collaboration with security partners to deliver accurate and +reliable container vulnerability scanning results of Red Hat-published images and packages. More about the Vulnerability +Scanner Certification program can be found +[here](https://connect.redhat.com/en/partner-with-us/red-hat-vulnerability-scanner-certification?extIdCarryOver=true&sc_cid=701f2000001Css5AAC). + +The full list of requirements that vendors must meet to be certified are detailed +[here](https://redhat-connect.gitbook.io/partner-guide-red-hat-vulnerability-scanner-cert/requirements). ## Technical Guidance on CSAF/VEX Adoption for Vendors +### Package Identification +In order to accurately find vulnerability information on a particular package within a repository, it’s necessary to +first properly identify the Red Hat package version, which can differ from upstream versions due to [Red Hat’s +backporting policy](https://access.redhat.com/security/updates/backporting). + +A detailed explanation of how Red Hat uses PURL's can be found +[here](https://github.com/RedHatProductSecurity/security-data-guidelines/blob/csaf-vex-guidelines/docs/purl.md). + +### Determining CPE +Common Platform Enumeration (CPE) is a standardized method of describing and identifying classes of applications, +operating systems, and hardware devices present among an enterprise's computing assets. + +Each CPE uniquely identifies the Red Hat platform (product) and version and can be referenced across all of Red Hat’s +security data. Identifying CPEs is important because a package, identified during the container scan, can have a +different severity impact rating and state for identified CVE(s) based on the platform and version specific repository +it belongs to. + +#### Container Identification +In order to correctly identify the container images included in an environment, you can use the podman images command +to get basic information about container images. Red Hat strongly recommends providing the container repository, +container tag and container image ID in all vulnerability scans. + +#### Repository Identification +Each Red Hat published container image after June 2020 includes content manifest JSON files. The running container’s +"/root/buildinfo/content_manifests" folder contains the aggregation of all layer’s content manifests, which could have +different content sets. An individual content manifest JSON file includes a “content_sets” array which provides the +repository names from which the packages from that container image were installed from. Red Hat recommends extracting +the “content_sets” data from all json files. + +#### CPE Mapping +After correctly pulling the repository names from the content manifest JSON files, you can use the Red Hat CPE to +Repository mapping to identify the associated CPEs. The mapping JSON file includes objects for all Red Hat repositories. +Find the corresponding object for the repository name and extract the nested CPE object for the list of all associated +CPEs. + +### Using CSAF/VEX to Find Fix Status +CPEs can be mapped to the product_name objects while individual package PURLs should be mapped to the product_version +objects. + + ## Additional Notes -https://www.redhat.com/en/about/brand/standards/history -https://www.redhat.com/en/blog/20-years-red-hat-product-security-inception-customer-experience + From 743da99925078b7bc4dd6f268dcc86545914cc96 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Thu, 19 Sep 2024 09:44:48 -0700 Subject: [PATCH 07/17] More updates, more to follow --- .DS_Store | Bin 6148 -> 6148 bytes docs/csaf-vex.md | 19 +++++++++++++------ docs/scanning-vendors.md | 2 +- 3 files changed, 14 insertions(+), 7 deletions(-) diff --git a/.DS_Store b/.DS_Store index 8781dea3faf648dcc41d6e3543567efd2f555ace..86d09cb6a8b8695501724ddbb6e43114f9cf32da 100644 GIT binary patch delta 49 zcmZoMXfc@J&&W10U^gS%WFE!|qAUz44EYSn48>)^MR_^-dFc!c42+u>GKR5jX6N|J F4**uB4ZQ#W delta 30 mcmZoMXfc@J&&WD4U^gS{WFE!|o3}Csu}v(H+|17LmmdI@+X=}4 diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 6f9fc1d..9f94e18 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -48,8 +48,8 @@ three main sections: document metadata, a product tree and vulnerability metadat be found [here](https://github.com/RedHatProductSecurity/security-data-guidelines/blob/csaf-vex-guidelines/docs/csaf-vex.json). -The next sections break down each section of the document using the -[VEX file for CVE-2022-1247](https://access.redhat.com/security/data/csaf/v2/vex/2022/cve-2022-1247.json). +The following sections break down the information included in CSAF/VEX documents using the +[VEX file for CVE-2022-1247](https://access.redhat.com/security/data/csaf/v2/vex/2022/cve-2022-1247.json) as an example. ### Document Metadata The "document" section contains general information about the published document itself including CVE severity, vendor, @@ -307,10 +307,18 @@ a specific CVE to the specific component and product ] }, ``` -For all the product_ids found in the “Fixed” array, these will also be listed in the “remediations” -array, which correlates each product_id to the correct RHSAs. The RHSA can be determined by the “url” field in the same -remediation object. +The "remediations" object includes information about +* Vendor Fix: For all the product_ids found in the “Fixed” array there will be a corresponding entry in the +"remediations" object that correlates each product_id to the correct RHSAs. The RHSA can be determined by the “url” +field. +* No Fix Planned: Correlates to the known affected + * Details: Will not fix or Out of support scope +* None Available: + * Details: affected + +``` +``` Additional CVE Resources: ``` @@ -338,7 +346,6 @@ Additional CVE Resources: ], ``` - ## Additional Notes https://www.redhat.com/en/about/brand/standards/history https://www.redhat.com/en/blog/20-years-red-hat-product-security-inception-customer-experience diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md index 0658ccc..eb6c9bd 100644 --- a/docs/scanning-vendors.md +++ b/docs/scanning-vendors.md @@ -51,5 +51,5 @@ objects. -## Additional Notes +## Frequently Asked Questions From 9942681d461e5367be7986b13a19e09436875f91 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Mon, 23 Sep 2024 13:49:01 -0700 Subject: [PATCH 08/17] Updated branches info --- {docs => csaf-vex}/csaf-vex.json | 0 docs/csaf-vex.md | 182 +++++++++++++++++++++---------- 2 files changed, 125 insertions(+), 57 deletions(-) rename {docs => csaf-vex}/csaf-vex.json (100%) diff --git a/docs/csaf-vex.json b/csaf-vex/csaf-vex.json similarity index 100% rename from docs/csaf-vex.json rename to csaf-vex/csaf-vex.json diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 9f94e18..2c96211 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -22,9 +22,9 @@ for every single CVE record that is associated with the Red Hat portfolio in any ## Red Hat and CSAF/VEX ### CSAF Overview -The Common Security Advisory Framework (CSAF) was originally published as an open standard by OASIS Open in November 2022. -CSAF files provide a structured, machine-readable way of representing and sharing security advisory information -across all software and hardware providers. +The [Common Security Advisory Framework (CSAF)](https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html) +was originally published as an open standard by OASIS Open in November 2022. CSAF files provide a structured, +machine-readable way of representing and sharing security advisory information across all software and hardware providers. Red Hat's CSAF files are always associated with one specific advisory and a given advisory may include one or more product version(s) and one or more components, depending on the product type and update scope. The advisory itself can also @@ -43,7 +43,7 @@ and Red Hat products. Red Hat’s VEX files are publicly available per CVE ## Document Structure Although CSAF and VEX files ultimately serve different purposes, both CSAF and VEX files meet the -CSAF machine readable standard and use the VEX profile to convey security information. The CSAF-VEX standard includes +CSAF machine-readable standard and use the VEX profile to convey security information. The CSAF-VEX standard includes three main sections: document metadata, a product tree and vulnerability metadata. The full document structure can be found [here](https://github.com/RedHatProductSecurity/security-data-guidelines/blob/csaf-vex-guidelines/docs/csaf-vex.json). @@ -125,24 +125,51 @@ CVE ID, CVE publish date and CVE revision history: ### Product Tree The “product_tree” section identifies all affected Red Hat software, represents the nested -relationship of component to product and provides CPEs or PURLs depending on the affected layer. There are two main -objects in the “product_tree” object; “branches” and “relationships”. +relationship of component to product and provides CPEs or PURLs depending on the affected layer. There are two main +objects in the “product_tree” object: “branches” and “relationships”. #### Branches -The parent "branches" object includes nested objects of three subcategories: "product_family", "product_name" and -"product_version". The "product_family" category represents a general Red Hat product stream and -includes one or more nested objects with the "product_name" category that represent an individual release. The -"product_name" object will always include the name of the product, a product ID and a product identification helper in -the form of a CPE. +The parent "branches" object has one child object of the "vendor" category with the name set to "Red Hat". All +affected Red Hat products and components will be nested in that "branches" array. + +``` +{ + "branches": [ + { + "branches": [] + "category": "vendor" + "name": "Red Hat: + } + ] +} +``` + +All nested objects included in the "branches" object of the "vendor" category fall into the following subcategories: +* "product_family": The "product_family" category represents a general Red Hat product stream and includes one or more +nested objects of the "product_name". +* "product_name": The "product_name" category represents a specific product release and is always nested under the +corresponding "product_family" +* "product_version": The "product version" category represents a specific component. When displayed unnested, the +component is not fixed yet and will not include a specific version number. Note: This will only be present in VEX files +since CSAF files are per advisory and will only include fixed components. +* "architecture": The "architecture" category represents fixed components by their architecture and includes nested + "product_version" objects. These "product_version" will be fixed and provide the specific version number. + + + +##### Product Family and Product Name Examples +The "product_family" category represents a general Red Hat product stream and includes one or +more nested objects of the "product_name" category that represents an individual release. The "product_name" object will +always include the name of the product, a product ID and a product identification helper in the form of a CPE. In the example below, you can see that the "product_family" object is for Red Hat Enterprise Linux 9 and nested within -is the "product_name" object Red Hat Enterprise Linux 9. +is the "product_name" object Red Hat Enterprise Linux 9 with the CPE "cpe:/o:redhat:enterprise_linux:9". ``` { "branches": [ - { + { "category": "product_name", "name": "Red Hat Enterprise Linux 9", "product": { @@ -159,29 +186,62 @@ is the "product_name" object Red Hat Enterprise Linux 9. }, ``` -The "product_version" category includes information about a specific affected package. The "product_name" object will -always include the name of the component, a product ID and a product identification helper in the form of a PURL. The -example below represents the affected component kernel. +##### Unfixed Product Versions (VEX only) Examples +The "product_version" category includes information about a specific affected package. The "product_version" object will +always include the name of the component, a product ID and a product identification helper in the form of a PURL. When +displayed unnested under an "architecture" object, the "name" attribute will not reference a specific version number +because these components are unfixed. Again, these unfixed "product_version" components will only be found in VEX files +since CSAF files always represent a released RHSA. + +In the example below, the unfixed kernel component's name is "kernel" and doesn't include a specific version number. ``` { - "category": "product_version", + "category": "product_version", + "name": "kernel", + "product": { "name": "kernel", - "product": { - "name": "kernel", - "product_id": "kernel", + "product_id": "kernel", + "product_identification_helper": { + "purl": "pkg:rpm/redhat/kernel?arch=src" + } + } +}, +``` +##### Architecture and Fixed Product Versions +Similarly to the "product_family" object, the "architecture" category represents a specific architecture for packages +and includes one or more "product_version" objects. As before, the "product_version" category will still include the same +information: the name of the component, a product ID and product identification helper in the form of a PURL. However, +when product_versions are nested under architecture object, they are fixed components and the "name" attribute will +include a specific version number and the specific architecture format. + +In the example below, you can see the fixed kernel component's name is "kernel-0:3.10.0-693.112.1.el7.src" which includes +the specific version number "0:3.10.0-693.112.1.el7" and architecture format ".src". +``` +{ + "branches": [ + { + "category": "product_version", + "name": "kernel-0:3.10.0-693.112.1.el7.src", + "product": { + "name": "kernel-0:3.10.0-693.112.1.el7.src", + "product_id": "kernel-0:3.10.0-693.112.1.el7.src", "product_identification_helper": { - "purl": "pkg:rpm/redhat/kernel?arch=src" + "purl": "pkg:rpm/redhat/kernel@3.10.0-693.112.1.el7?arch=src" } + } } -}, + ], + "category": "architecture", + "name": "src" +} ``` #### Relationships Also included in the "product_tree" section is a "relationships" object which is used by Red Hat to help represent layered products. One or more relationship entries will be present for all "product_version" objects found in the -"branches" object. All of these nested objects are of the “default_component_of” category and include the full product -name and product id (a combination of the "product_name" and the "product_version"), a reference to the component name +"branches" object. All of these objects are of the “default_component_of” category and include the full product +name and product ID (a combination of the "product_name" and the "product_version"), a reference to the component name and a reference to the product name. Continuing with the previous examples, we know that there should be at least one entry in the "relationships" object @@ -189,7 +249,7 @@ that correlates to the "product_version" object for kernel. Looking at the VEX f kernel, all which relate to the different "product_name" objects from before. The below is the specific entry as it relates to Red Hat Enterprise Linux 9. -Here you can see that the "full_product_name" includes a name and a product_id which are the combination of the product, +Here you can see that the "full_product_name" includes a name and a product ID which are the combination of the product, Red Hat Enterprise Linux 9, and the component, kernel. The "product_reference" will always refer to the component's name while the "relates_to_product_reference" will refer to the product name. @@ -205,12 +265,13 @@ while the "relates_to_product_reference" will refer to the product name. }, ``` - -### Vulnerability Metadata +### Vulnerability Metadata The "vulnerabilities" section reports vulnerability metadata for any CVEs included in the document and also contains a -"product_status" object that reports fix status for any "product_id" listed in the "product_tree". +"product_status" object that reports fix status for any "product_id" listed in the "product_tree" and a "remediations" +object. +#### CVE Information CVE ID, CWE and Publication Date: ``` "cve": "CVE-2022-1247", @@ -282,6 +343,33 @@ CVSS Score and Severity: } ], ``` +Additional CVE Resources: +``` +"references": [ + { + "category": "self", + "summary": "Canonical URL", + "url": "https://access.redhat.com/security/cve/CVE-2022-1247" + }, + { + "category": "external", + "summary": "RHBZ#2066799", + "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2066799" + }, + { + "category": "external", + "summary": "https://www.cve.org/CVERecord?id=CVE-2022-1247", + "url": "https://www.cve.org/CVERecord?id=CVE-2022-1247" + }, + { + "category": "external", + "summary": "https://nvd.nist.gov/vuln/detail/CVE-2022-1247", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1247" + } +], +``` + +#### Product Fix Status The "product_status" includes the following fix statuses: @@ -308,43 +396,23 @@ a specific CVE to the specific component and product }, ``` +#### Remediations The "remediations" object includes information about -* Vendor Fix: For all the product_ids found in the “Fixed” array there will be a corresponding entry in the +* Vendor Fix: For all the product_ids found in the “Fixed” product status there will be a corresponding entry in the "remediations" object that correlates each product_id to the correct RHSAs. The RHSA can be determined by the “url” field. -* No Fix Planned: Correlates to the known affected - * Details: Will not fix or Out of support scope + * Details: Link on how to apply update + * URL: Link for the correlated RHSA +* No Fix Planned: + * Details: Will not fix + * Details: Out of support scope * None Available: - * Details: affected + * Details: Affected ``` ``` -Additional CVE Resources: -``` -"references": [ - { - "category": "self", - "summary": "Canonical URL", - "url": "https://access.redhat.com/security/cve/CVE-2022-1247" - }, - { - "category": "external", - "summary": "RHBZ#2066799", - "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2066799" - }, - { - "category": "external", - "summary": "https://www.cve.org/CVERecord?id=CVE-2022-1247", - "url": "https://www.cve.org/CVERecord?id=CVE-2022-1247" - }, - { - "category": "external", - "summary": "https://nvd.nist.gov/vuln/detail/CVE-2022-1247", - "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1247" - } -], -``` + ## Additional Notes https://www.redhat.com/en/about/brand/standards/history From 62261d13ed3924dde78efab9d6782d4ac9582d44 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Mon, 23 Sep 2024 15:01:33 -0700 Subject: [PATCH 09/17] Removed scanning vendor doc since it will need more work --- .gitignore | 2 + docs/csaf-vex.md | 307 +++++++++++++++++++++++---------------- docs/scanning-vendors.md | 55 ------- 3 files changed, 182 insertions(+), 182 deletions(-) delete mode 100644 docs/scanning-vendors.md diff --git a/.gitignore b/.gitignore index dcc8394..73c606c 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,5 @@ .cache *.egg-info/ .tox +/.idea/ +/.github/ diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 2c96211..dad730d 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -49,11 +49,11 @@ be found [here](https://github.com/RedHatProductSecurity/security-data-guidelines/blob/csaf-vex-guidelines/docs/csaf-vex.json). The following sections break down the information included in CSAF/VEX documents using the -[VEX file for CVE-2022-1247](https://access.redhat.com/security/data/csaf/v2/vex/2022/cve-2022-1247.json) as an example. +[VEX file for CVE-2023-20593](https://access.redhat.com/security/data/csaf/v2/vex/2022/cve-2023-20593.json) as an example. ### Document Metadata The "document" section contains general information about the published document itself including CVE severity, vendor, -published date and revision history. +published date and revision history. General CVE Severity: @@ -100,24 +100,24 @@ Vendor information: CVE ID, CVE publish date and CVE revision history: ``` -"id": "CVE-2022-1247", -"initial_release_date": "2022-05-11T09:37:00+00:00", +"id": "CVE-2023-20593", +"initial_release_date": "2023-07-25T06:30:00+00:00", "revision_history": [ - { - "date": "2022-05-11T09:37:00+00:00", - "number": "1", - "summary": "Initial version" - }, - { - "date": "2023-09-19T14:13:41+00:00", - "number": "2", - "summary": "Current version" - }, - { - "date": "2024-08-20T07:48:38+00:00", - "number": "3", - "summary": "Last generated version" - } + { + "date": "2023-07-25T06:30:00+00:00", + "number": "1", + "summary": "Initial version" + }, + { + "date": "2024-04-18T04:20:20+00:00", + "number": "2", + "summary": "Current version" + }, + { + "date": "2024-09-13T20:58:30+00:00", + "number": "3", + "summary": "Last generated version" + } ], "status": "final", "version": "3" @@ -129,9 +129,9 @@ relationship of component to product and provides CPEs or PURLs depending on the objects in the “product_tree” object: “branches” and “relationships”. #### Branches - The parent "branches" object has one child object of the "vendor" category with the name set to "Red Hat". All -affected Red Hat products and components will be nested in that "branches" array. +affected Red Hat products and components will be nested in that "branches" array. Compressed down, the parent branches +object would look like: ``` { @@ -163,26 +163,26 @@ The "product_family" category represents a general Red Hat product stream and in more nested objects of the "product_name" category that represents an individual release. The "product_name" object will always include the name of the product, a product ID and a product identification helper in the form of a CPE. -In the example below, you can see that the "product_family" object is for Red Hat Enterprise Linux 9 and nested within -is the "product_name" object Red Hat Enterprise Linux 9 with the CPE "cpe:/o:redhat:enterprise_linux:9". +In the example below, you can see that the "product_family" object is for Red Hat Enterprise Linux 6 and nested within +is the "product_name" object Red Hat Enterprise Linux 6 with the CPE "cpe:/o:redhat:enterprise_linux:6". ``` { - "branches": [ - { - "category": "product_name", - "name": "Red Hat Enterprise Linux 9", - "product": { - "name": "Red Hat Enterprise Linux 9", - "product_id": "red_hat_enterprise_linux_9", - "product_identification_helper": { - "cpe": "cpe:/o:redhat:enterprise_linux:9" - } - } + "branches": [ + { + "category": "product_name", + "name": "Red Hat Enterprise Linux 6", + "product": { + "name": "Red Hat Enterprise Linux 6", + "product_id": "red_hat_enterprise_linux_6", + "product_identification_helper": { + "cpe": "cpe:/o:redhat:enterprise_linux:6" } - ], - "category": "product_family", - "name": "Red Hat Enterprise Linux 9" + } + } + ], +"category": "product_family", +"name": "Red Hat Enterprise Linux 6" }, ``` @@ -193,7 +193,8 @@ displayed unnested under an "architecture" object, the "name" attribute will not because these components are unfixed. Again, these unfixed "product_version" components will only be found in VEX files since CSAF files always represent a released RHSA. -In the example below, the unfixed kernel component's name is "kernel" and doesn't include a specific version number. +In the example below, the unfixed kernel component's name is "kernel" and doesn't include a specific version number or +an architecture format. ``` { @@ -208,6 +209,7 @@ In the example below, the unfixed kernel component's name is "kernel" and doesn' } }, ``` + ##### Architecture and Fixed Product Versions Similarly to the "product_family" object, the "architecture" category represents a specific architecture for packages and includes one or more "product_version" objects. As before, the "product_version" category will still include the same @@ -247,26 +249,38 @@ and a reference to the product name. Continuing with the previous examples, we know that there should be at least one entry in the "relationships" object that correlates to the "product_version" object for kernel. Looking at the VEX file, there are actually four entries for kernel, all which relate to the different "product_name" objects from before. The below is the specific entry as it -relates to Red Hat Enterprise Linux 9. +relates to Red Hat Enterprise Linux 6. Here you can see that the "full_product_name" includes a name and a product ID which are the combination of the product, -Red Hat Enterprise Linux 9, and the component, kernel. The "product_reference" will always refer to the component's name +Red Hat Enterprise Linux 6, and the component, kernel. The "product_reference" will always refer to the component's name while the "relates_to_product_reference" will refer to the product name. ``` { -"category": "default_component_of", -"full_product_name": { - "name": "kernel as a component of Red Hat Enterprise Linux 9", - "product_id": "red_hat_enterprise_linux_9:kernel" - }, - "product_reference": "kernel", - "relates_to_product_reference": "red_hat_enterprise_linux_9" + "category": "default_component_of", + "full_product_name": { + "name": "kernel as a component of Red Hat Enterprise Linux 6", + "product_id": "red_hat_enterprise_linux_6:kernel" + }, + "product_reference": "kernel", + "relates_to_product_reference": "red_hat_enterprise_linux_6" }, ``` -### Vulnerability Metadata +For the fixed component kernel-0:3.10.0-693.112.1.el7.src, a relationship entry looks like: +``` +{ + "category": "default_component_of", + "full_product_name": { + "name": "kernel-0:3.10.0-693.112.1.el7.src as a component of Red Hat Enterprise Linux Server AUS (v. 7.4)", + "product_id": "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.src" + }, + "product_reference": "kernel-0:3.10.0-693.112.1.el7.src", + "relates_to_product_reference": "7Server-7.4.AUS" +}, +``` +### Vulnerability Metadata The "vulnerabilities" section reports vulnerability metadata for any CVEs included in the document and also contains a "product_status" object that reports fix status for any "product_id" listed in the "product_tree" and a "remediations" object. @@ -274,37 +288,32 @@ object. #### CVE Information CVE ID, CWE and Publication Date: ``` -"cve": "CVE-2022-1247", +"cve": "CVE-2023-20593", "cwe": { - "id": "CWE-366", - "name": "Race Condition within a Thread" + "id": "CWE-1239", + "name": "Improper Zeroization of Hardware Register" }, - "discovery_date": "2022-03-22T00:00:00+00:00", + "discovery_date": "2023-05-31T00:00:00+00:00", ``` CVE Description, Summary and Statement: ``` "notes": [ - { - "category": "description", - "text": "An issue found in linux-kernel that leads to a race condition in rose_connect(). The rose driver uses rose_neigh->use to represent how many objects are using the rose_neigh. When a user wants to delete a rose_route via rose_ioctl(), the rose driver calls rose_del_node() and removes neighbours only if their “count” and “use” are zero.", - "title": "Vulnerability description" - }, - { - "category": "summary", - "text": "kernel: A race condition bug in rose_connect()", - "title": "Vulnerability summary" - }, - { - "category": "other", - "text": "There was no shipped kernel version that was seen affected by this problem. These files are not built in our source code.", - "title": "Statement" - }, - { - "category": "general", - "text": "The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.", - "title": "CVSS score applicability" - } + { + "category": "description", + "text": "A flaw was found in hw, in “Zen 2” CPUs. This issue may allow an attacker to access sensitive information under specific microarchitectural circumstances.", + "title": "Vulnerability description" + }, + { + "category": "summary", + "text": "hw: amd: Cross-Process Information Leak", + "title": "Vulnerability summary" + }, + { + "category": "general", + "text": "The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.", + "title": "CVSS score applicability" + } ], ``` @@ -315,94 +324,128 @@ CVSS Score and Severity: "cvss_v3": { "attackComplexity": "LOW", "attackVector": "LOCAL", - "availabilityImpact": "HIGH", - "baseScore": 7.8, - "baseSeverity": "HIGH", + "availabilityImpact": "NONE", + "baseScore": 6.5, + "baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", - "integrityImpact": "HIGH", + "integrityImpact": "NONE", "privilegesRequired": "LOW", - "scope": "UNCHANGED", + "scope": "CHANGED", "userInteraction": "NONE", - "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", + "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N", "version": "3.1" }, - "products": [ - "red_hat_enterprise_linux_9:kernel", - "red_hat_enterprise_linux_9:kernel-rt" - ] + "products": [] } ], "threats": [ { "category": "impact", "details": "Moderate", - "product_ids": [ - "red_hat_enterprise_linux_9:kernel", - "red_hat_enterprise_linux_9:kernel-rt" - ] + "product_ids": [] } ], ``` Additional CVE Resources: ``` -"references": [ - { - "category": "self", - "summary": "Canonical URL", - "url": "https://access.redhat.com/security/cve/CVE-2022-1247" - }, - { - "category": "external", - "summary": "RHBZ#2066799", - "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2066799" - }, - { - "category": "external", - "summary": "https://www.cve.org/CVERecord?id=CVE-2022-1247", - "url": "https://www.cve.org/CVERecord?id=CVE-2022-1247" - }, - { - "category": "external", - "summary": "https://nvd.nist.gov/vuln/detail/CVE-2022-1247", - "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1247" - } -], + "references": [ + { + "category": "self", + "summary": "Canonical URL", + "url": "https://access.redhat.com/security/cve/CVE-2023-20593" + }, + { + "category": "external", + "summary": "RHBZ#2217845", + "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2217845" + }, + { + "category": "external", + "summary": "https://www.cve.org/CVERecord?id=CVE-2023-20593", + "url": "https://www.cve.org/CVERecord?id=CVE-2023-20593" + }, + { + "category": "external", + "summary": "https://nvd.nist.gov/vuln/detail/CVE-2023-20593", + "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20593" + }, + { + "category": "external", + "summary": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=522b1d69219d8f083173819fde04f994aa051a98", + "url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=522b1d69219d8f083173819fde04f994aa051a98" + }, + { + "category": "external", + "summary": "https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html", + "url": "https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html" + } + ], ``` #### Product Fix Status - The "product_status" includes the following fix statuses: -* Fixed: Contains the same fixed component versions and other details (product_tree objects) that the CSAF advisory -reports for that CVE +* Fixed: Contains the same fixed component versions and other details (product_tree objects) that the are reported fixed +for a given CVE * Known Affected: Confirmation that the specific component and product is affected by a particular CVE * Known Not Affected: Confirmation that the specific component and product is not affected by a particular CVE * Under Investigation: Information that the Red Hat Product Security team is verifying the applicability and impact of a specific CVE to the specific component and product +Compressed down, a product_status object that included products of each category, would look like: + ``` "product_status": { - "known_affected": [ - "red_hat_enterprise_linux_9:kernel", - "red_hat_enterprise_linux_9:kernel-rt" - ], - "known_not_affected": [ - "red_hat_enterprise_linux_6:kernel", - "red_hat_enterprise_linux_7:kernel", - "red_hat_enterprise_linux_7:kernel-rt", - "red_hat_enterprise_linux_8:kernel", - "red_hat_enterprise_linux_8:kernel-rt" - ] + "fixed": [] + "known_affected": [], + "known_not_affected": [], + "under_investigation": [] }, ``` +Note: It's important to remember that with VEX files, not every "product_status" will be included, only the categories that +have products which fall into those statuses. For CSAF files, the only included status will be the "fixed" category. + +Continuing with our previous examples with CVE-2023-20593, the full product ID "red_hat_enterprise_linux_6:kernel" +can be found in the "known_not_affected" list: + +``` +"known_not_affected": [ + ..., + "red_hat_enterprise_linux_6:kernel", + "red_hat_enterprise_linux_6:microcode_ctl" +] + +``` + +Our other full product ID "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.src" can be found in the "fixed" list: +``` +"fixed": [ + ..., + "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.src", + "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.x86_64", + ... +] +``` #### Remediations -The "remediations" object includes information about -* Vendor Fix: For all the product_ids found in the “Fixed” product status there will be a corresponding entry in the +The "remediations" object provides additional information about the previously identified product status. The following +remediations status are available per product_status: + +"fixed" product status: +* "vendor_fix": For all the product_ids found in the “Fixed” product status there will be a corresponding entry in the "remediations" object that correlates each product_id to the correct RHSAs. The RHSA can be determined by the “url” -field. - * Details: Link on how to apply update - * URL: Link for the correlated RHSA +field. Note: In VEX files, there may be more than one "vendor_fix" object if more than one RHSA released fixes for the +CVE, while in CSAF files there will only be one "vendor_fix" object that correlates to the RHSA in that CSAF file. + +"known_affected": +* + +"known_not_affected": +* "workaround" + +"under_investigation" +* + * No Fix Planned: * Details: Will not fix * Details: Out of support scope @@ -410,6 +453,16 @@ field. * Details: Affected ``` +{ + "category": "workaround", + "details": "Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.", + "product_ids": [ + ..., + "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.src", + "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.x86_64", + ... + ] + ``` diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md deleted file mode 100644 index eb6c9bd..0000000 --- a/docs/scanning-vendors.md +++ /dev/null @@ -1,55 +0,0 @@ -# Vulnerability Scanning and CSAF/VEX - -## Red Hat's Vulnerability Scanning Certification Program -The Red Hat Vulnerability Scanner Certification is a collaboration with security partners to deliver accurate and -reliable container vulnerability scanning results of Red Hat-published images and packages. More about the Vulnerability -Scanner Certification program can be found -[here](https://connect.redhat.com/en/partner-with-us/red-hat-vulnerability-scanner-certification?extIdCarryOver=true&sc_cid=701f2000001Css5AAC). - -The full list of requirements that vendors must meet to be certified are detailed -[here](https://redhat-connect.gitbook.io/partner-guide-red-hat-vulnerability-scanner-cert/requirements). - -## Technical Guidance on CSAF/VEX Adoption for Vendors -### Package Identification -In order to accurately find vulnerability information on a particular package within a repository, it’s necessary to -first properly identify the Red Hat package version, which can differ from upstream versions due to [Red Hat’s -backporting policy](https://access.redhat.com/security/updates/backporting). - -A detailed explanation of how Red Hat uses PURL's can be found -[here](https://github.com/RedHatProductSecurity/security-data-guidelines/blob/csaf-vex-guidelines/docs/purl.md). - -### Determining CPE -Common Platform Enumeration (CPE) is a standardized method of describing and identifying classes of applications, -operating systems, and hardware devices present among an enterprise's computing assets. - -Each CPE uniquely identifies the Red Hat platform (product) and version and can be referenced across all of Red Hat’s -security data. Identifying CPEs is important because a package, identified during the container scan, can have a -different severity impact rating and state for identified CVE(s) based on the platform and version specific repository -it belongs to. - -#### Container Identification -In order to correctly identify the container images included in an environment, you can use the podman images command -to get basic information about container images. Red Hat strongly recommends providing the container repository, -container tag and container image ID in all vulnerability scans. - -#### Repository Identification -Each Red Hat published container image after June 2020 includes content manifest JSON files. The running container’s -"/root/buildinfo/content_manifests" folder contains the aggregation of all layer’s content manifests, which could have -different content sets. An individual content manifest JSON file includes a “content_sets” array which provides the -repository names from which the packages from that container image were installed from. Red Hat recommends extracting -the “content_sets” data from all json files. - -#### CPE Mapping -After correctly pulling the repository names from the content manifest JSON files, you can use the Red Hat CPE to -Repository mapping to identify the associated CPEs. The mapping JSON file includes objects for all Red Hat repositories. -Find the corresponding object for the repository name and extract the nested CPE object for the list of all associated -CPEs. - -### Using CSAF/VEX to Find Fix Status -CPEs can be mapped to the product_name objects while individual package PURLs should be mapped to the product_version -objects. - - - -## Frequently Asked Questions - From 39b52d03c7d50c4b9653d644c73a5a7638d1eea2 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Mon, 23 Sep 2024 15:56:26 -0700 Subject: [PATCH 10/17] YAY! Final content added :) --- docs/csaf-vex.md | 86 +++++++++++++++++++++++++++++++----------------- 1 file changed, 56 insertions(+), 30 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index dad730d..082c459 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -55,7 +55,7 @@ The following sections break down the information included in CSAF/VEX documents The "document" section contains general information about the published document itself including CVE severity, vendor, published date and revision history. -General CVE Severity: +CVE severity: ``` "aggregate_severity": { @@ -64,7 +64,7 @@ General CVE Severity: }, ``` -VEX Metadata: +VEX metadata: ``` "category": "csaf_vex", @@ -286,7 +286,7 @@ The "vulnerabilities" section reports vulnerability metadata for any CVEs includ object. #### CVE Information -CVE ID, CWE and Publication Date: +CVE ID, CWE and publication date: ``` "cve": "CVE-2023-20593", "cwe": { @@ -296,7 +296,7 @@ CVE ID, CWE and Publication Date: "discovery_date": "2023-05-31T00:00:00+00:00", ``` -CVE Description, Summary and Statement: +CVE description, summary and statement: ``` "notes": [ { @@ -317,7 +317,7 @@ CVE Description, Summary and Statement: ], ``` -CVSS Score and Severity: +CVSS score and severity: ``` "scores": [ { @@ -346,7 +346,7 @@ CVSS Score and Severity: } ], ``` -Additional CVE Resources: +Additional CVE resources: ``` "references": [ { @@ -385,11 +385,11 @@ Additional CVE Resources: #### Product Fix Status The "product_status" includes the following fix statuses: -* Fixed: Contains the same fixed component versions and other details (product_tree objects) that the are reported fixed +* "fixed": Contains the same fixed component versions and other details (product_tree objects) that the are reported fixed for a given CVE -* Known Affected: Confirmation that the specific component and product is affected by a particular CVE -* Known Not Affected: Confirmation that the specific component and product is not affected by a particular CVE -* Under Investigation: Information that the Red Hat Product Security team is verifying the applicability and impact of +* "known_affected": Confirmation that the specific component and product is affected by a particular CVE +* "known_not_affected": Confirmation that the specific component and product is not affected by a particular CVE +* "under_investigation": Information that the Red Hat Product Security team is verifying the applicability and impact of a specific CVE to the specific component and product Compressed down, a product_status object that included products of each category, would look like: @@ -431,26 +431,53 @@ Our other full product ID "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.src" ca The "remediations" object provides additional information about the previously identified product status. The following remediations status are available per product_status: -"fixed" product status: -* "vendor_fix": For all the product_ids found in the “Fixed” product status there will be a corresponding entry in the -"remediations" object that correlates each product_id to the correct RHSAs. The RHSA can be determined by the “url” -field. Note: In VEX files, there may be more than one "vendor_fix" object if more than one RHSA released fixes for the -CVE, while in CSAF files there will only be one "vendor_fix" object that correlates to the RHSA in that CSAF file. +* "fixed" product status + * "vendor_fix": For all the product_IDs found in the “fixed” product_status there will be a corresponding entry + in the "remediations" object that correlates each full product ID to the correct RHSAs. The RHSA can be determined by + the “url” field. + * Details: "Fixed" + * URL: Link to the RHSA + * "workaround": If a mitigation exists, it applies to all components regardless of their fix state. + * Details: "Mitigation" +* "known_affected": For all the full product IDs found in the "known_affected" product status, there will be additional +entries in the "remediations" object that fall into the following categories. + * "no_fix_planned": Will include any product_IDs in the "known_affected" product status that will not be fixed by Red + Hat, either because it is out of support scope or the engineering team has decided not to fix it for other reasons. + * Details: "Will not fix" or "Out of support scope" + * "none_available": Will include any product_IDs in the "known_affected" product status that are either still reported + affected, meaning a fix is likely in progress, or deferred, which may be fixed at a future date. + * Details: "Affected" or "Deferred" + * "workaround": If a mitigation exists, it applies to all components regardless of their fix state. + * Details: "Mitigation" +* "known_not_affected": There are no "remediation" objects for the known not affected status since it is implicitly +assumed that there are no remediations needed if the product and component are not affected. +* "under_investigation": There are no "remediation" objects for the under investigation status since it is implicitly +assumed that no remediations exist since we are still investigating the vulnerability. + +Note: As with the "product_status" object, there may not be an entry for every category. Additionally, in VEX files, +there may be more than one "vendor_fix" object if more than one RHSA released fixes for the CVE. In the CSAF files, +the only "remediation" category present will be one "vendor_fix" object that correlates to the RHSA that the CSAF +file represents. + +Following our two previous kernel examples, we can see that for the unfixed kernel component +"red_hat_enterprise_linux_6:kernel" there is no entry in the remediations section. This is expected behavior because +it was listed in the "known_not_affected" product status and therefore no remediation is needed. + +For our fixed kernel component "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.src", there are two remediation entries. +One represents the vendor fix that was released and the other represents that there is a reported mitigation for this +CVE. -"known_affected": -* - -"known_not_affected": -* "workaround" - -"under_investigation" -* - -* No Fix Planned: - * Details: Will not fix - * Details: Out of support scope -* None Available: - * Details: Affected +``` +{ + "category": "vendor_fix", + "details": "For details on how to apply this update, which includes the changes described in this advisory, refer to:\n\nhttps://access.redhat.com/articles/11258\n\nThe system must be rebooted for this update to take effect.", + "product_ids": [ + "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.src", + "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.x86_64", + ... + ] +} +``` ``` { @@ -466,7 +493,6 @@ CVE, while in CSAF files there will only be one "vendor_fix" object that correla ``` - ## Additional Notes https://www.redhat.com/en/about/brand/standards/history https://www.redhat.com/en/blog/20-years-red-hat-product-security-inception-customer-experience From 5f428712cef22d70058559785b2977dd4899bfb4 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Mon, 23 Sep 2024 15:59:29 -0700 Subject: [PATCH 11/17] Clean up files --- .DS_Store | Bin 6148 -> 0 bytes .idea/.gitignore | 3 --- .idea/misc.xml | 6 ------ .idea/modules.xml | 8 -------- .idea/security-data-guidelines.iml | 9 --------- .idea/vcs.xml | 6 ------ 6 files changed, 32 deletions(-) delete mode 100644 .DS_Store delete mode 100644 .idea/.gitignore delete mode 100644 .idea/misc.xml delete mode 100644 .idea/modules.xml delete mode 100644 .idea/security-data-guidelines.iml delete mode 100644 .idea/vcs.xml diff --git a/.DS_Store b/.DS_Store deleted file mode 100644 index 86d09cb6a8b8695501724ddbb6e43114f9cf32da..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6148 zcmeHK!A`?447H)43NAZx%z+=+AC##`-1`GlTWK7+W!l8fmG*BO_$r=b1Ffhy!iH=q zd5#^Y&XbzNM8u1ic1|=Sq8v?-MVSyWPr5E_@->iUjdtI3b&MSb=OU7OMlD5ZXg|#V z)7Y)%RTJ0Sw4*D28wRXnS=L>wVau2I)y?tg^;7mD6H1J1yhflD3E zk3)Rq3^)V-i~-Kds$5`GcDH`pp4_zoZHXo#^LkMr&_|B|4CEZSOHTC% a(J`+u>=k7dv8QmLKLipX-Z=xmz`#2isxb@z diff --git a/.idea/.gitignore b/.idea/.gitignore deleted file mode 100644 index 26d3352..0000000 --- a/.idea/.gitignore +++ /dev/null @@ -1,3 +0,0 @@ -# Default ignored files -/shelf/ -/workspace.xml diff --git a/.idea/misc.xml b/.idea/misc.xml deleted file mode 100644 index 639900d..0000000 --- a/.idea/misc.xml +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - \ No newline at end of file diff --git a/.idea/modules.xml b/.idea/modules.xml deleted file mode 100644 index 8108c98..0000000 --- a/.idea/modules.xml +++ /dev/null @@ -1,8 +0,0 @@ - - - - - - - - \ No newline at end of file diff --git a/.idea/security-data-guidelines.iml b/.idea/security-data-guidelines.iml deleted file mode 100644 index d6ebd48..0000000 --- a/.idea/security-data-guidelines.iml +++ /dev/null @@ -1,9 +0,0 @@ - - - - - - - - - \ No newline at end of file diff --git a/.idea/vcs.xml b/.idea/vcs.xml deleted file mode 100644 index 35eb1dd..0000000 --- a/.idea/vcs.xml +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - \ No newline at end of file From 2ea78d245f6e33e35bed6a568efb91da45d3ebdc Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Tue, 24 Sep 2024 07:59:21 -0700 Subject: [PATCH 12/17] Updates --- .gitignore | 2 +- README.md | 6 +++ docs/csaf-vex.md | 129 +++++++++++++++++++++++------------------------ 3 files changed, 71 insertions(+), 66 deletions(-) diff --git a/.gitignore b/.gitignore index 73c606c..0e934dd 100644 --- a/.gitignore +++ b/.gitignore @@ -2,4 +2,4 @@ *.egg-info/ .tox /.idea/ -/.github/ + diff --git a/README.md b/README.md index a0e82de..dad9e28 100644 --- a/README.md +++ b/README.md @@ -12,3 +12,9 @@ source venv/bin/activate pip install -r requirements/docs-requirements.txt mkdocs serve ``` + +If your running on MacOS and experience issues with the `cairo` dependency, try add the following: + +``` +brew install cairo +``` diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 082c459..08991ea 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -29,7 +29,7 @@ machine-readable way of representing and sharing security advisory information a Red Hat's CSAF files are always associated with one specific advisory and a given advisory may include one or more product version(s) and one or more components, depending on the product type and update scope. The advisory itself can also include updates to address one or more vulnerabilities. Red Hat’s CSAF files are publicly available per advisory -[here](https://access.redhat.com/security/data/csaf/v2/advisories). +[here](security.access.redhat.com/data). ### VEX Overview The CSAF standard acknowledges the need for different use cases and has therefore defined a variety of profiles. @@ -39,7 +39,7 @@ on a product or component. Red Hat's VEX files are always associated with one CVE and include fix status information for all vulnerable packages and Red Hat products. Red Hat’s VEX files are publicly available per CVE -[here](https://access.redhat.com/security/data/csaf/v2/vex/). +[here](security.access.redhat.com/data). ## Document Structure Although CSAF and VEX files ultimately serve different purposes, both CSAF and VEX files meet the @@ -52,7 +52,7 @@ The following sections break down the information included in CSAF/VEX documents [VEX file for CVE-2023-20593](https://access.redhat.com/security/data/csaf/v2/vex/2022/cve-2023-20593.json) as an example. ### Document Metadata -The "document" section contains general information about the published document itself including CVE severity, vendor, +The `document` section contains general information about the published document itself including CVE severity, vendor, published date and revision history. CVE severity: @@ -124,12 +124,12 @@ CVE ID, CVE publish date and CVE revision history: ``` ### Product Tree -The “product_tree” section identifies all affected Red Hat software, represents the nested +The `product_tree` section identifies all affected Red Hat software, represents the nested relationship of component to product and provides CPEs or PURLs depending on the affected layer. There are two main -objects in the “product_tree” object: “branches” and “relationships”. +objects in the “product_tree” object: `branches` and `relationships`. #### Branches -The parent "branches" object has one child object of the "vendor" category with the name set to "Red Hat". All +The parent `branches` object has one child object of the `vendor` category with the name set to "Red Hat". All affected Red Hat products and components will be nested in that "branches" array. Compressed down, the parent branches object would look like: @@ -145,26 +145,26 @@ object would look like: } ``` -All nested objects included in the "branches" object of the "vendor" category fall into the following subcategories: -* "product_family": The "product_family" category represents a general Red Hat product stream and includes one or more -nested objects of the "product_name". -* "product_name": The "product_name" category represents a specific product release and is always nested under the +All nested objects included in the `branches` object of the `vendor` category fall into the following subcategories: +* `product_family`: Represents a general Red Hat product stream and includes one or more +nested objects of the `product_name` category . +* `product_name`: Represents a specific product release and is always nested under the corresponding "product_family" -* "product_version": The "product version" category represents a specific component. When displayed unnested, the +* `product_version`: Represents a specific component. When displayed unnested, the component is not fixed yet and will not include a specific version number. Note: This will only be present in VEX files since CSAF files are per advisory and will only include fixed components. -* "architecture": The "architecture" category represents fixed components by their architecture and includes nested +* `architecture`: Represents fixed components by their architecture and includes nested "product_version" objects. These "product_version" will be fixed and provide the specific version number. ##### Product Family and Product Name Examples -The "product_family" category represents a general Red Hat product stream and includes one or -more nested objects of the "product_name" category that represents an individual release. The "product_name" object will +The `product_family` category represents a general Red Hat product stream and includes one or +more nested objects of the `product_name` category that represents an individual release. The `product_name` object will always include the name of the product, a product ID and a product identification helper in the form of a CPE. -In the example below, you can see that the "product_family" object is for Red Hat Enterprise Linux 6 and nested within -is the "product_name" object Red Hat Enterprise Linux 6 with the CPE "cpe:/o:redhat:enterprise_linux:6". +In the example below, you can see that the `product_family` object is for Red Hat Enterprise Linux 6 and nested within +is the `product_name` object Red Hat Enterprise Linux 6 with the CPE "cpe:/o:redhat:enterprise_linux:6". ``` { @@ -187,10 +187,10 @@ is the "product_name" object Red Hat Enterprise Linux 6 with the CPE "cpe:/o:red ``` ##### Unfixed Product Versions (VEX only) Examples -The "product_version" category includes information about a specific affected package. The "product_version" object will +The `product_version` category includes information about a specific affected package. The `product_version` object will always include the name of the component, a product ID and a product identification helper in the form of a PURL. When -displayed unnested under an "architecture" object, the "name" attribute will not reference a specific version number -because these components are unfixed. Again, these unfixed "product_version" components will only be found in VEX files +displayed unnested under an `architecture` object, the `name` attribute will not reference a specific version number +because these components are unfixed. Again, these unfixed `product_version` components will only be found in VEX files since CSAF files always represent a released RHSA. In the example below, the unfixed kernel component's name is "kernel" and doesn't include a specific version number or @@ -211,10 +211,10 @@ an architecture format. ``` ##### Architecture and Fixed Product Versions -Similarly to the "product_family" object, the "architecture" category represents a specific architecture for packages -and includes one or more "product_version" objects. As before, the "product_version" category will still include the same +Similarly to the `product_family` object, the `architecture` category represents a specific architecture for packages +and includes one or more `product_version` objects. As before, the `product_version` category will still include the same information: the name of the component, a product ID and product identification helper in the form of a PURL. However, -when product_versions are nested under architecture object, they are fixed components and the "name" attribute will +when `product_versions` are nested under `architecture` object, they are fixed components and the `name` attribute will include a specific version number and the specific architecture format. In the example below, you can see the fixed kernel component's name is "kernel-0:3.10.0-693.112.1.el7.src" which includes @@ -240,20 +240,20 @@ the specific version number "0:3.10.0-693.112.1.el7" and architecture format ".s ``` #### Relationships -Also included in the "product_tree" section is a "relationships" object which is used by Red Hat to help represent -layered products. One or more relationship entries will be present for all "product_version" objects found in the -"branches" object. All of these objects are of the “default_component_of” category and include the full product -name and product ID (a combination of the "product_name" and the "product_version"), a reference to the component name +Also included in the `product_tree` section is a `relationships` object which is used by Red Hat to help represent +layered products. One or more relationship entries will be present for all `product_version` objects found in the +`branches` object. All of these objects are of the `default_component_of` category and include the full product +name and product ID (a combination of the `product_name` and the `product_version`), a reference to the component name and a reference to the product name. -Continuing with the previous examples, we know that there should be at least one entry in the "relationships" object -that correlates to the "product_version" object for kernel. Looking at the VEX file, there are actually four entries for -kernel, all which relate to the different "product_name" objects from before. The below is the specific entry as it +Continuing with the previous examples, we know that there should be at least one entry in the `relationships` object +that correlates to the `product_version` object for kernel. Looking at the VEX file, there are actually four entries for +kernel, all which relate to the different `product_name` objects from before. The below is the specific entry as it relates to Red Hat Enterprise Linux 6. -Here you can see that the "full_product_name" includes a name and a product ID which are the combination of the product, -Red Hat Enterprise Linux 6, and the component, kernel. The "product_reference" will always refer to the component's name -while the "relates_to_product_reference" will refer to the product name. +Here you can see that the `full_product_name` includes a `name` and a `product_id` which are the combination of the product, +Red Hat Enterprise Linux 6, and the component, kernel. The `product_reference` will always refer to the component's name +while the `relates_to_product_reference` will refer to the product name. ``` { @@ -281,8 +281,8 @@ For the fixed component kernel-0:3.10.0-693.112.1.el7.src, a relationship entry ``` ### Vulnerability Metadata -The "vulnerabilities" section reports vulnerability metadata for any CVEs included in the document and also contains a -"product_status" object that reports fix status for any "product_id" listed in the "product_tree" and a "remediations" +The `vulnerabilities` section reports vulnerability metadata for any CVEs included in the document and also contains a +`product_status` object that reports fix status for any `product_id` listed in the `product_tree` and a `remediations` object. #### CVE Information @@ -383,16 +383,16 @@ Additional CVE resources: ``` #### Product Fix Status -The "product_status" includes the following fix statuses: +The `product_status` includes the following fix statuses: -* "fixed": Contains the same fixed component versions and other details (product_tree objects) that the are reported fixed +* `fixed`: Contains the same fixed component versions and other details (product_tree objects) that the are reported fixed for a given CVE -* "known_affected": Confirmation that the specific component and product is affected by a particular CVE -* "known_not_affected": Confirmation that the specific component and product is not affected by a particular CVE -* "under_investigation": Information that the Red Hat Product Security team is verifying the applicability and impact of +* `known_affected`: Confirmation that the specific component and product is affected by a particular CVE +* `known_not_affected`: Confirmation that the specific component and product is not affected by a particular CVE +* `under_investigation`: Information that the Red Hat Product Security team is verifying the applicability and impact of a specific CVE to the specific component and product -Compressed down, a product_status object that included products of each category, would look like: +Compressed down, a `product_status` object that included products of each category, would look like: ``` "product_status": { @@ -402,11 +402,11 @@ Compressed down, a product_status object that included products of each category "under_investigation": [] }, ``` -Note: It's important to remember that with VEX files, not every "product_status" will be included, only the categories that -have products which fall into those statuses. For CSAF files, the only included status will be the "fixed" category. +Note: It's important to remember that with VEX files, not every product status will be included, only the categories that +have products which fall into those statuses. For CSAF files, the only included status will be the `fixed` category. Continuing with our previous examples with CVE-2023-20593, the full product ID "red_hat_enterprise_linux_6:kernel" -can be found in the "known_not_affected" list: +can be found in the `known_not_affected` list: ``` "known_not_affected": [ @@ -417,7 +417,7 @@ can be found in the "known_not_affected" list: ``` -Our other full product ID "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.src" can be found in the "fixed" list: +Our other full product ID "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.src" can be found in the `fixed` list: ``` "fixed": [ ..., @@ -428,40 +428,39 @@ Our other full product ID "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.src" ca ``` #### Remediations -The "remediations" object provides additional information about the previously identified product status. The following -remediations status are available per product_status: +The `remediations` object provides additional information about the previously identified product status. The following +remediations status are available per `product_status` category: -* "fixed" product status - * "vendor_fix": For all the product_IDs found in the “fixed” product_status there will be a corresponding entry - in the "remediations" object that correlates each full product ID to the correct RHSAs. The RHSA can be determined by - the “url” field. +* `fixed` + * `vendor_fix`: For all the product IDs with a fixed product status there will be a corresponding entry + in the remediations object that correlates each full product ID to the correct RHSAs. The RHSA can be determined by + the `url` field. * Details: "Fixed" * URL: Link to the RHSA - * "workaround": If a mitigation exists, it applies to all components regardless of their fix state. - * Details: "Mitigation" -* "known_affected": For all the full product IDs found in the "known_affected" product status, there will be additional -entries in the "remediations" object that fall into the following categories. - * "no_fix_planned": Will include any product_IDs in the "known_affected" product status that will not be fixed by Red + * `workaround`: If a mitigation exists, it applies to all components regardless of their fix state. + * `Details`: "Mitigation" +* `known_affected` + * `no_fix_planned`: Will include any product IDs with the known affected product status that will not be fixed by Red Hat, either because it is out of support scope or the engineering team has decided not to fix it for other reasons. * Details: "Will not fix" or "Out of support scope" - * "none_available": Will include any product_IDs in the "known_affected" product status that are either still reported + * `none_available`: Will include any product IDs with the known affected product status that are either still reported affected, meaning a fix is likely in progress, or deferred, which may be fixed at a future date. * Details: "Affected" or "Deferred" - * "workaround": If a mitigation exists, it applies to all components regardless of their fix state. + * `workaround`: If a mitigation exists, it applies to all components regardless of their fix state. * Details: "Mitigation" -* "known_not_affected": There are no "remediation" objects for the known not affected status since it is implicitly +* `known_not_affected`: There are no remediation objects for the known not affected status since it is implicitly assumed that there are no remediations needed if the product and component are not affected. -* "under_investigation": There are no "remediation" objects for the under investigation status since it is implicitly +* `under_investigation`: There are no remediation objects for the under investigation status since it is implicitly assumed that no remediations exist since we are still investigating the vulnerability. -Note: As with the "product_status" object, there may not be an entry for every category. Additionally, in VEX files, -there may be more than one "vendor_fix" object if more than one RHSA released fixes for the CVE. In the CSAF files, -the only "remediation" category present will be one "vendor_fix" object that correlates to the RHSA that the CSAF -file represents. +Note: As with the `product_status` object, there may not be a `remediations` entry for every category. Additionally, +in VEX files, there may be more than one `vendor_fix` object if more than one RHSA released fixes for the CVE. In the +CSAF files, the only `remediations` category present will be one `vendor_fix` object that maps to the RHSA that +the CSAF file represents. Following our two previous kernel examples, we can see that for the unfixed kernel component -"red_hat_enterprise_linux_6:kernel" there is no entry in the remediations section. This is expected behavior because -it was listed in the "known_not_affected" product status and therefore no remediation is needed. +"red_hat_enterprise_linux_6:kernel" there is no entry in the remediation section. This is expected behavior because +it was listed in the `known_not_affected` product status and therefore no remediation is needed. For our fixed kernel component "7Server-7.4.AUS:kernel-0:3.10.0-693.112.1.el7.src", there are two remediation entries. One represents the vendor fix that was released and the other represents that there is a reported mitigation for this From 142ff28357ce5290650e18b81165258f83538d67 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Tue, 24 Sep 2024 13:36:22 -0700 Subject: [PATCH 13/17] Updates based on feedback --- README.md | 2 +- docs/csaf-vex.md | 43 ++++++++++++++++--------------------------- mkdocs.yml | 3 ++- 3 files changed, 19 insertions(+), 29 deletions(-) diff --git a/README.md b/README.md index dad9e28..b3c0873 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,7 @@ pip install -r requirements/docs-requirements.txt mkdocs serve ``` -If your running on MacOS and experience issues with the `cairo` dependency, try add the following: +If your running on MacOS and experience issues with the `cairo` dependency, try adding the following: ``` brew install cairo diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 08991ea..4e616ae 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -1,23 +1,10 @@ # Red Hat CSAF-VEX Advisories ## Red Hat Security Data Overview -The Red Hat Product Security was originally founded in 2001 and has always been committed to providing our customers -and partners with complete and accurate security data for all Red Hat software. In the past, Red Hat published security -advisory information using Common Vulnerability Reporting Framework (CVRF) and CVE information using the Open -Vulnerability and Assessment Language (OVAL) format. Over the last few years, the Common Security Advisory Framework -(CSAF) 2.0 standard was published and is now the successor to the CVRF version 1.2 as there are many enhancements to the -information provided in each CSAF file. - -On February 1st, 2023, Red Hat first announced the general availability of CSAF 2.0 documents. This version of our CSAF -files are published using the VEX profile (Vulnerability Exploitability eXchange) and the document type is now known as -csaf_vex. Since then Red Hat has continued to make improvements to our published security data, including the GA release -of our VEX files on July 10th, 2024. While publishing our CSAF files was extremely helpful for correlating security data -to individual advisories, we began publishing VEX files to make it easier for our partners and customers to correlate -both fixed and unfixed security information to an individual CVE. Additionally, the publication of our VEX files -announced the deprecation of our previously published OVAL data, which did not provide the same level of detailed -security information. - -Currently, Red Hat Product Security publishes CSAF advisories for every single Red Hat security advisory and VEX files +In the past, Red Hat published security advisory information using Common Vulnerability Reporting Framework (CVRF) and +CVE information using the Open Vulnerability and Assessment Language (OVAL) format. As of July 10th,2024, Red Hat +Product Security publishes CSAF files for every single Red Hat Security Advisory +([RHSA](https://access.redhat.com/articles/explaining_redhat_errata)) and VEX files for every single CVE record that is associated with the Red Hat portfolio in any way. ## Red Hat and CSAF/VEX @@ -26,9 +13,9 @@ The [Common Security Advisory Framework (CSAF)](https://docs.oasis-open.org/csaf was originally published as an open standard by OASIS Open in November 2022. CSAF files provide a structured, machine-readable way of representing and sharing security advisory information across all software and hardware providers. -Red Hat's CSAF files are always associated with one specific advisory and a given advisory may include one or more product -version(s) and one or more components, depending on the product type and update scope. The advisory itself can also -include updates to address one or more vulnerabilities. Red Hat’s CSAF files are publicly available per advisory +Red Hat's CSAF files are always associated with RHSA and a given security advisory may include one or more product +version(s) and one or more components, depending on the product type and update scope. The RHSA itself can also +include updates to address one or more vulnerabilities. Red Hat’s CSAF files are publicly available per RHSA [here](security.access.redhat.com/data). ### VEX Overview @@ -43,13 +30,13 @@ and Red Hat products. Red Hat’s VEX files are publicly available per CVE ## Document Structure Although CSAF and VEX files ultimately serve different purposes, both CSAF and VEX files meet the -CSAF machine-readable standard and use the VEX profile to convey security information. The CSAF-VEX standard includes +CSAF machine-readable standard and use the VEX profile to convey security information. The CSAF-P standard includes three main sections: document metadata, a product tree and vulnerability metadata. The full document structure can be found [here](https://github.com/RedHatProductSecurity/security-data-guidelines/blob/csaf-vex-guidelines/docs/csaf-vex.json). The following sections break down the information included in CSAF/VEX documents using the -[VEX file for CVE-2023-20593](https://access.redhat.com/security/data/csaf/v2/vex/2022/cve-2023-20593.json) as an example. +[VEX file for CVE-2023-20593](https://access.redhat.com/security/data/csaf/v2/vex/2023/cve-2023-20593.json) as an example. ### Document Metadata The `document` section contains general information about the published document itself including CVE severity, vendor, @@ -147,12 +134,12 @@ object would look like: All nested objects included in the `branches` object of the `vendor` category fall into the following subcategories: * `product_family`: Represents a general Red Hat product stream and includes one or more -nested objects of the `product_name` category . +nested objects of the `product_name` category. * `product_name`: Represents a specific product release and is always nested under the -corresponding "product_family" +corresponding `product_family` category. * `product_version`: Represents a specific component. When displayed unnested, the component is not fixed yet and will not include a specific version number. Note: This will only be present in VEX files -since CSAF files are per advisory and will only include fixed components. +since CSAF files are per RHSA and will only include fixed components. * `architecture`: Represents fixed components by their architecture and includes nested "product_version" objects. These "product_version" will be fixed and provide the specific version number. @@ -188,7 +175,8 @@ is the `product_name` object Red Hat Enterprise Linux 6 with the CPE "cpe:/o:red ##### Unfixed Product Versions (VEX only) Examples The `product_version` category includes information about a specific affected package. The `product_version` object will -always include the name of the component, a product ID and a product identification helper in the form of a PURL. When +always include the name of the component, a product ID and a product identification helper in the form of a +[PURL](https://redhatproductsecurity.github.io/security-data-guidelines/purl/). When displayed unnested under an `architecture` object, the `name` attribute will not reference a specific version number because these components are unfixed. Again, these unfixed `product_version` components will only be found in VEX files since CSAF files always represent a released RHSA. @@ -213,7 +201,8 @@ an architecture format. ##### Architecture and Fixed Product Versions Similarly to the `product_family` object, the `architecture` category represents a specific architecture for packages and includes one or more `product_version` objects. As before, the `product_version` category will still include the same -information: the name of the component, a product ID and product identification helper in the form of a PURL. However, +information: the name of the component, a product ID and product identification helper in the form of a +[PURL](https://redhatproductsecurity.github.io/security-data-guidelines/purl/). However, when `product_versions` are nested under `architecture` object, they are fixed components and the `name` attribute will include a specific version number and the specific architecture format. diff --git a/mkdocs.yml b/mkdocs.yml index 939d643..f16501c 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -33,7 +33,8 @@ theme: nav: - Home: "index.md" - - purl: "purl.md" + - PURL: "purl.md" + - CSAF-VEX: "csaf-vex.md" plugins: - social From e56e56a7fce568ae89d94b600c950a0f5224853c Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Wed, 25 Sep 2024 12:13:01 -0700 Subject: [PATCH 14/17] Minor changes --- README.md | 2 +- docs/csaf-vex.md | 71 ++++++++++++++++++++++++++++++++++++------------ mkdocs.yml | 2 +- 3 files changed, 55 insertions(+), 20 deletions(-) diff --git a/README.md b/README.md index b3c0873..3579027 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,7 @@ pip install -r requirements/docs-requirements.txt mkdocs serve ``` -If your running on MacOS and experience issues with the `cairo` dependency, try adding the following: +If you're running on MacOS and experience issues with the `cairo` dependency, try adding the following: ``` brew install cairo diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 4e616ae..3ba88b2 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -38,11 +38,11 @@ be found The following sections break down the information included in CSAF/VEX documents using the [VEX file for CVE-2023-20593](https://access.redhat.com/security/data/csaf/v2/vex/2023/cve-2023-20593.json) as an example. -### Document Metadata -The `document` section contains general information about the published document itself including CVE severity, vendor, +### Document Metadata +The `document` section contains general information about the published document itself including the CVE severity, vendor, published date and revision history. -CVE severity: +The `aggregate_severity.text` object displays the general CVE severity: ``` "aggregate_severity": { @@ -51,7 +51,7 @@ CVE severity: }, ``` -VEX metadata: +The following objects provide general information about the VEX file itself: ``` "category": "csaf_vex", @@ -73,7 +73,7 @@ VEX metadata: ], ``` -Vendor information: +Vendor information is represented in the `publisher` object: ``` "publisher": { "category": "vendor", @@ -85,6 +85,9 @@ Vendor information: ``` CVE ID, CVE publish date and CVE revision history: +* `id`: Provides the official CVE ID. +* `initial_release_date`: Represents the date that the Red Hat first published information on the CVE. +* `revision_history`: Details any changes made to the CVE information published by Red Hat. ``` "id": "CVE-2023-20593", @@ -270,22 +273,30 @@ For the fixed component kernel-0:3.10.0-693.112.1.el7.src, a relationship entry ``` ### Vulnerability Metadata -The `vulnerabilities` section reports vulnerability metadata for any CVEs included in the document and also contains a -`product_status` object that reports fix status for any `product_id` listed in the `product_tree` and a `remediations` -object. +The `vulnerabilities` section reports vulnerability metadata for the CVE and also contains a +`product_status` object that reports affected status and fix information for any `product_id` listed in the `product_tree` and a `remediations` +object. -#### CVE Information -CVE ID, CWE and publication date: +#### General CVE Information +Basic CVE information is represented using the following objects: +* `cve`: The official CVE ID. +* `cwe`: Information about the corresponding CWE, include the CWE ID and the name. +* `discovery_date`: The first reported date of the vulnerability. Note: This date can differ from the previously + mentioned `initial_release_date` if the CVE was coordinated under embargo. ``` "cve": "CVE-2023-20593", - "cwe": { - "id": "CWE-1239", - "name": "Improper Zeroization of Hardware Register" - }, - "discovery_date": "2023-05-31T00:00:00+00:00", +"cwe": { + "id": "CWE-1239", + "name": "Improper Zeroization of Hardware Register" +}, +"discovery_date": "2023-05-31T00:00:00+00:00", ``` -CVE description, summary and statement: +Additional CVE information can be found in the `notes` object: +* `description`: This category includes a written description of the CVE. +* `summary`: This category includes a short summary of the CVE. +* `statement`: This category includes a statement from Red Hat on the CVE, when applicable (not present in the example). +* `general`: This category includes a general statement on the applicability of CVSS scores. ``` "notes": [ { @@ -306,7 +317,14 @@ CVE description, summary and statement: ], ``` -CVSS score and severity: +A CVE can have a single CVSS score that is associated to all products and components in the VEX file or there can +be different CVSS score metrics for different subset of products and components (per component Severity and CVSS metadata) + +All CVSS scores associated with the CVE will have entries included `scores` object: +* `cvss_v3`: Includes attributes for each CVSS base value, the complete CVSS vector string and the version of CVSS that + is used. +* `products`: Includes all product IDs, both for products and components, that are represented by the scores in the + `cvss_v3` object. ``` "scores": [ { @@ -327,6 +345,19 @@ CVSS score and severity: "products": [] } ], +``` + +Similarly to CVSS scores, a CVE can have one severity impact value that represents all products and components in the +VEX file or there can be different severity impact values for different subset of products and components +(per component Severity and CVSS metadata). + +All severity impact values with the CVE will have entires includes in the `threats` object: +* `category`: The "impact" value identifies that the following information is the severity impact value of a CVE. +* `details`: Reports the appropriate [Red Hat Severity Rating](https://access.redhat.com/security/updates/classification/) + for the associated `product_ids`. +* `product_ids`: Includes all product IDs, both for products and components, that have the severity rating in the + `details` object. +``` "threats": [ { "category": "impact", @@ -335,7 +366,11 @@ CVSS score and severity: } ], ``` -Additional CVE resources: + +Additional CVE resources are described in the `references` object: +* `category`: Either of the type "self" or "external". +* `summary`: A summary of the provided resource. +* `url`: A link to the resource. ``` "references": [ { diff --git a/mkdocs.yml b/mkdocs.yml index f16501c..5fdae4a 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -33,7 +33,7 @@ theme: nav: - Home: "index.md" - - PURL: "purl.md" + - purl: "purl.md" - CSAF-VEX: "csaf-vex.md" plugins: From 2d9c7adc250f11ad800eeb9a26496e0b2f90dc1f Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Wed, 25 Sep 2024 12:30:02 -0700 Subject: [PATCH 15/17] Fixed json and added contact methods --- docs/csaf-vex.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 3ba88b2..31c58d4 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -127,9 +127,9 @@ object would look like: { "branches": [ { - "branches": [] - "category": "vendor" - "name": "Red Hat: + "branches": [], + "category": "vendor", + "name": "Red Hat" } ] } @@ -516,6 +516,9 @@ CVE. ``` -## Additional Notes -https://www.redhat.com/en/about/brand/standards/history -https://www.redhat.com/en/blog/20-years-red-hat-product-security-inception-customer-experience +## Additional Questions or Concerns +Red Hat is committed to continually improving our security data; any future changes to the data itself or the format of +the files are tracked in the [Red Hat Security Data Changelog](https://access.redhat.com/articles/5554431). + +Please contact Red Hat Product Security with any questions regarding security data at [secalert@redhat.com](secalert@redhat.com) or file an +issue in the public [SECDATA Jira project](https://issues.redhat.com/projects/SECDATA/issues/SECDATA-525?filter=allopenissues). \ No newline at end of file From 684011a655fba7e92cfb00a94ae1fb882d679894 Mon Sep 17 00:00:00 2001 From: Aubrey Olandt Date: Wed, 25 Sep 2024 12:43:10 -0700 Subject: [PATCH 16/17] Fixed formatting --- docs/csaf-vex.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 31c58d4..e7ea4b9 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -85,6 +85,7 @@ Vendor information is represented in the `publisher` object: ``` CVE ID, CVE publish date and CVE revision history: + * `id`: Provides the official CVE ID. * `initial_release_date`: Represents the date that the Red Hat first published information on the CVE. * `revision_history`: Details any changes made to the CVE information published by Red Hat. @@ -136,6 +137,7 @@ object would look like: ``` All nested objects included in the `branches` object of the `vendor` category fall into the following subcategories: + * `product_family`: Represents a general Red Hat product stream and includes one or more nested objects of the `product_name` category. * `product_name`: Represents a specific product release and is always nested under the @@ -293,6 +295,7 @@ Basic CVE information is represented using the following objects: ``` Additional CVE information can be found in the `notes` object: + * `description`: This category includes a written description of the CVE. * `summary`: This category includes a short summary of the CVE. * `statement`: This category includes a statement from Red Hat on the CVE, when applicable (not present in the example). @@ -321,6 +324,7 @@ A CVE can have a single CVSS score that is associated to all products and compo be different CVSS score metrics for different subset of products and components (per component Severity and CVSS metadata) All CVSS scores associated with the CVE will have entries included `scores` object: + * `cvss_v3`: Includes attributes for each CVSS base value, the complete CVSS vector string and the version of CVSS that is used. * `products`: Includes all product IDs, both for products and components, that are represented by the scores in the @@ -352,6 +356,7 @@ VEX file or there can be different severity impact values for different subset o (per component Severity and CVSS metadata). All severity impact values with the CVE will have entires includes in the `threats` object: + * `category`: The "impact" value identifies that the following information is the severity impact value of a CVE. * `details`: Reports the appropriate [Red Hat Severity Rating](https://access.redhat.com/security/updates/classification/) for the associated `product_ids`. @@ -368,6 +373,7 @@ All severity impact values with the CVE will have entires includes in the `threa ``` Additional CVE resources are described in the `references` object: + * `category`: Either of the type "self" or "external". * `summary`: A summary of the provided resource. * `url`: A link to the resource. From e531e52af5e10f6e38145e9164153eb19dbacfd6 Mon Sep 17 00:00:00 2001 From: Przemyslaw Roguski Date: Fri, 27 Sep 2024 13:08:19 +0200 Subject: [PATCH 17/17] Only a few minor clarifications --- docs/csaf-vex.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index e7ea4b9..2196124 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -30,7 +30,7 @@ and Red Hat products. Red Hat’s VEX files are publicly available per CVE ## Document Structure Although CSAF and VEX files ultimately serve different purposes, both CSAF and VEX files meet the -CSAF machine-readable standard and use the VEX profile to convey security information. The CSAF-P standard includes +CSAF machine-readable standard and use the VEX profile to convey security information. The CSAF standard includes three main sections: document metadata, a product tree and vulnerability metadata. The full document structure can be found [here](https://github.com/RedHatProductSecurity/security-data-guidelines/blob/csaf-vex-guidelines/docs/csaf-vex.json). @@ -138,7 +138,7 @@ object would look like: All nested objects included in the `branches` object of the `vendor` category fall into the following subcategories: -* `product_family`: Represents a general Red Hat product stream and includes one or more +* `product_family`: Represents a general Red Hat product main stream and includes one or more nested objects of the `product_name` category. * `product_name`: Represents a specific product release and is always nested under the corresponding `product_family` category. @@ -184,7 +184,7 @@ always include the name of the component, a product ID and a product identificat [PURL](https://redhatproductsecurity.github.io/security-data-guidelines/purl/). When displayed unnested under an `architecture` object, the `name` attribute will not reference a specific version number because these components are unfixed. Again, these unfixed `product_version` components will only be found in VEX files -since CSAF files always represent a released RHSA. +since CSAF files always represent a released RHSA. The purl identifiers for unfixed content are only available for `rpm`, `oci` (container), and `rpmmod` (modular) purl content type. In the example below, the unfixed kernel component's name is "kernel" and doesn't include a specific version number or an architecture format. @@ -433,7 +433,7 @@ Compressed down, a `product_status` object that included products of each catego }, ``` Note: It's important to remember that with VEX files, not every product status will be included, only the categories that -have products which fall into those statuses. For CSAF files, the only included status will be the `fixed` category. +have products which fall into those statuses. For CSAF files, the only included status will be the `fixed` and optionally `known_not_affected` category if in the released RHSA there are more components and not all were vulnerable to the particular CVE id. Continuing with our previous examples with CVE-2023-20593, the full product ID "red_hat_enterprise_linux_6:kernel" can be found in the `known_not_affected` list: