From 1346050548bf1f2fafef999ec9c28217f79474e2 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 09:11:12 +0100 Subject: [PATCH 01/24] ((re-structuring all edits into individual commits)) Updating Jira base URL across all pages Re-created jira custom filter that was invalidated by the hosting change. --- docs/csaf-vex.md | 3 ++- docs/purl.md | 2 +- docs/sbom.md | 2 +- docs/scanning-vendors.md | 20 ++++++++++---------- docs/vex-ga-details.md | 2 +- docs/vex-ga.md | 2 +- 6 files changed, 16 insertions(+), 15 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index e8e4702..a8040e6 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -598,4 +598,5 @@ Red Hat is committed to continually improving our security data; any future chan 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). +issue in the public [SECDATA Jira project](https://redhat.atlassian.net/projects/SECDATA/issues/?filter=allopenissues). + diff --git a/docs/purl.md b/docs/purl.md index da2a16a..5520036 100644 --- a/docs/purl.md +++ b/docs/purl.md @@ -178,7 +178,7 @@ The guidelines highlighted in this document represent an ideal state across all that we want to achieve in the long term. In some cases, purl identifiers may be missing some of the metadata presented here or not specify it. Please [contact Red Hat Product Security](https://access.redhat.com/security/team/contact/) or file a Jira issue in the -[SECDATA project](https://issues.redhat.com/projects/SECDATA) if you find any discrepancies in Red Hat's security data. +[SECDATA project](https://redhat.atlassian.net/projects/SECDATA) if you find any discrepancies in Red Hat's security data. Feedback on our usage of purl is always welcome and appreciated. Also of note is the purpose of using purls as identifiers versus locators. Some purls may include certain qualifiers diff --git a/docs/sbom.md b/docs/sbom.md index 73b00cb..1f88668 100644 --- a/docs/sbom.md +++ b/docs/sbom.md @@ -770,5 +770,5 @@ The guidelines highlighted in this document represent an ideal state across all that we want to achieve in the long term. In some SBOMs, components may be missing their provenance data or their license expressions may not be accurate. Please [contact Red Hat Product Security](https://access.redhat.com/security/team/contact/) or file a Jira issue in the -[SECDATA project](https://issues.redhat.com/projects/SECDATA) if you find any discrepancies in Red Hat's security data. +[SECDATA project](https://redhat.atlassian.net/projects/SECDATA) if you find any discrepancies in Red Hat's security data. Feedback on our SBOM design and publishing is always welcome and appreciated. diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md index 7ef1d18..926c8c7 100644 --- a/docs/scanning-vendors.md +++ b/docs/scanning-vendors.md @@ -706,30 +706,30 @@ A Low Red Hat severity should be reported for the rhel9/python-312 container and ## Frequently Asked Questions (FAQs) Vendors are encouraged to raise any questions regarding security data by opening a 'Ticket' issue type in the public -[SECDATA Jira project](https://issues.redhat.com/projects/SECDATA/). +[SECDATA Jira project](https://redhat.atlassian.net/projects/SECDATA/). Many scanning vendors face similar challenges when reading and parsing Red Hat's security data. To check if your question -has already been asked, you can review the list of questions asked [here](https://issues.redhat.com/browse/SECDATA-862?filter=12444038). +has already been asked, you can review the list of questions asked [here](https://redhat.atlassian.net/browse/?filter=114902). ### Python and VENV -[https://issues.redhat.com/browse/SECDATA-831](https://issues.redhat.com/browse/SECDATA-831) +[https://redhat.atlassian.net/browse/SECDATA-831](https://redhat.atlassian.net/browse/SECDATA-831) ### Repository Relative URLs -[https://issues.redhat.com/browse/SECDATA-1089](https://issues.redhat.com/browse/SECDATA-1089) -[https://issues.redhat.com/browse/SECDATA-797](https://issues.redhat.com/browse/SECDATA-797) -[https://issues.redhat.com/browse/SECDATA-1020](https://issues.redhat.com/browse/SECDATA-1020) +[https://redhat.atlassian.net/browse/SECDATA-1089](https://redhat.atlassian.net/browse/SECDATA-1089) +[https://redhat.atlassian.net/browse/SECDATA-797](https://redhat.atlassian.net/browse/SECDATA-797) +[https://redhat.atlassian.net/browse/SECDATA-1020](https://redhat.atlassian.net/browse/SECDATA-1020) ### Empty Content Sets -[https://issues.redhat.com/browse/SECDATA-966](https://issues.redhat.com/browse/SECDATA-966) +[https://redhat.atlassian.net/browse/SECDATA-966](https://redhat.atlassian.net/browse/SECDATA-966) ### Differences in OVAL and VEX CPEs -[https://issues.redhat.com/browse/SECDATA-1141](https://issues.redhat.com/browse/SECDATA-1141) +[https://redhat.atlassian.net/browse/SECDATA-1141](https://redhat.atlassian.net/browse/SECDATA-1141) ### Duplicate RHSAs -[https://issues.redhat.com/browse/SECDATA-969](https://issues.redhat.com/browse/SECDATA-969) +[https://redhat.atlassian.net/browse/SECDATA-969](https://redhat.atlassian.net/browse/SECDATA-969) ## 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). -For any potential bugs identified regarding security data, please file a 'Bug' issue type in the public [SECDATA Jira project](https://issues.redhat.com/projects/SECDATA/). \ No newline at end of file +For any potential bugs identified regarding security data, please file a 'Bug' issue type in the public [SECDATA Jira project](https://redhat.atlassian.net/projects/SECDATA/). diff --git a/docs/vex-ga-details.md b/docs/vex-ga-details.md index b5d384a..7d8319d 100644 --- a/docs/vex-ga-details.md +++ b/docs/vex-ga-details.md @@ -494,7 +494,7 @@ The new GA VEX files simplify the representation of CVSS scores by eliminating t For any issues or questions you have, please file a jira issue with the following: -- **Project**: [SECDATA](https://issues.redhat.com/projects/SECDATA/summary) +- **Project**: [SECDATA](https://redhat.atlassian.net/projects/SECDATA/summary) - **Issue Type**: Ticket - **Component**: ‘feedback-new-vex’ - **Description**: The question or issue you wish to raise. Please provide a detailed explanation, the VEX file you are referencing and a specific example of the data. diff --git a/docs/vex-ga.md b/docs/vex-ga.md index 21c76e5..c623bcd 100644 --- a/docs/vex-ga.md +++ b/docs/vex-ga.md @@ -41,7 +41,7 @@ More detailed information on the differences between legacy VEX files and GA VEX For any issues or questions you have, please file a jira issue with the following: -- **Project**: [SECDATA](https://issues.redhat.com/projects/SECDATA/summary) +- **Project**: [SECDATA](https://redhat.atlassian.net/projects/SECDATA/summary) - **Issue Type**: Ticket - **Component**: ‘feedback-new-vex’ - **Description**: The question or issue you wish to raise. Please provide a detailed explanation, the VEX file you are referencing and a specific example of the data. From 03c838d8b5e97efb89e3542bd00d72c0ba856eda Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 09:27:22 +0100 Subject: [PATCH 02/24] Rephrasing for clarity and examples --- docs/scanning-vendors.md | 34 +++++++++++++++++++++++----------- 1 file changed, 23 insertions(+), 11 deletions(-) diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md index 926c8c7..a6089b5 100644 --- a/docs/scanning-vendors.md +++ b/docs/scanning-vendors.md @@ -32,23 +32,34 @@ CSAF advisory and VEX files as well as our SBOM files. Detailed information abou [here](https://redhatproductsecurity.github.io/security-data-guidelines/purl/). ### RPMs and RPM modules -An RPM package is a file format used by the Red Hat Package Manager (RPM) system for software distribution and management, -which package consists of an archive of files and metadata used to install and erase these files. -There are two types of RPM packages: source RPMs, which contain source code and a spec file and binary RPMs, which are -the files built from source packages and patches. +RPM is a file format used by the Red Hat Package Manager (RPM) system for software distribution and management, +in which packages consist of an archive of files and metadata used to manage the installation, upgrade and deinstallation of the associated software package. -Additionally, an RPM module is a set of RPM packages that represent a component and are usually installed together. -Starting from RHEL 10, there will be no more RPM modules. +There are two types of RPM packages: Source RPMs (also known as SRPMs) contain a spec file along with source code and patches from which the binary RPMs are built. Binary RPMs (RPMs) contain the actual files for the package to be installed, and are separated by CPU architecture (arch) for compiled content. -SRPMS, RPMs and RPM modules are represented in CSAF advisories and VEX data using the `rpm` purl type. More detailed -information about RPM purl usage can be found +Packages commonly have a one-to-one mapping of SRPM to RPM, but more complex +software may have subpackages defined in the RPM .spec file creating a +one-to-many mapping. For example, the `git` SRPM creates `git`, `git-core`, +`git-gui` and `git-devel` binary RPMs. In the context of mapping +vulnerabilities in source code to affectedness in binary packages we can +clearly see that a vulnerability in the graphical user interface is likely to +be present in the git-gui binary RPM but might be absent from git-core. By +adding an extra level of granularity to the VEX data, scanners are able to +exclude non-affected binary packages from vulnerabilities that are present in +the shared source. + +Additionally, an RPM module is a set of RPM packages that represent a higher level software component that is installed together. AppStreams are a common example of RPM modules. Note that RPM module support was removed in RHEL 10. + +SRPMs and RPMs are represented in CSAF advisories and VEX data using the `rpm` purl type. RPM Modules are represented with the `rpm` purl type and also have a `rpmmod` modifier with additional data. More detailed information about RPM purl usage can be found [here](https://redhatproductsecurity.github.io/security-data-guidelines/purl/#identifying-rpm-packages). + #### Binary RPMs -Both binary RPMs and RPM modules installed in a container image can be discovered using the `rpm -qa` command from within -the container image. +Both binary RPMs and RPM modules installed on a host (or in a container image) can be discovered using the `rpm -qa` command from within the system. In this case the `-qa` refers to `q` (query) and `a` (all installed packages), and the `--qf` specifies +the format to use for each installed package. + ``` # Example return of RPM query $ rpm -qa --qf '%{NAME} %{EPOCHNUM} %{VERSION} %{RELEASE} %{ARCH}\n' @@ -68,7 +79,8 @@ pkg:rpm/redhat/libgcc@11.3.1-4.3.el9?arch=x86_64 ``` #### SRPMs -Additionally, SRPMs can be discovered from a binary RPM by using the following command from within the container image. +The metadata for every RPM contains information on the source from which it was build. In this example, we can query a single +package (`libgcc`) and use the `--qf` format option to return the name of the Source RPM from which it was created. ``` # Example return of SRPM query From 616b190a0dc4d672d33e320a01dcdf78b162c54a Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 09:29:15 +0100 Subject: [PATCH 03/24] clarity --- docs/scanning-vendors.md | 33 +++++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md index a6089b5..d3abf70 100644 --- a/docs/scanning-vendors.md +++ b/docs/scanning-vendors.md @@ -216,15 +216,23 @@ Red Hat uses CPEs to uniquely identify each product and version, following the C Red Hat CPEs can be found [here](https://redhatproductsecurity.github.io/security-data-guidelines/cpe/). ### RPM Repositories -Each Red Hat container images published after June 2020 include information about the repositories from which -the packages used in the container are sourced. Scanning vendors will use the repositories to identify CPEs that are -associated with the scanned image. The following sections explain different ways to identify repository information for -a container image. + +Each Red Hat container image published after June 2020 include information +about the repositories from which the packages used in the container are +sourced. Scanning vendors should use these repositories to identify CPEs that +are associated with the scanned image. The following sections explain different +ways to identify repository information for a container image. #### Content Manifest JSON files -Previously, content manifest JSON files were included for each layer in the container image in the `root/buildinfo/` -directory. Inside each content manifest JSON file, you'll find a `content_sets` object, which specifies the -repository names that provided the packages found in the container image. + +Starting in June 2020, Content manifest JSON files were included for each layer +in the container image in the `root/buildinfo/` directory. In July 2025 this +system was replaced (see below) with content-sets, and will be deprecated at +some point in the future. + +Inside each content manifest JSON file, you'll find a `content_sets` object, +which specifies the repository names that provided the packages found in the +container image. The following examples show how to get a list of the content manifest files from within a container image. ``` @@ -316,9 +324,14 @@ $ cat cat /usr/share/buildinfo/content-sets.json ``` #### Querying Repositories for Binary RPMs -Although container images provide a list of repositories from which the packages in the image are sourced, vendors may also -be interested in determining the repository that provided a specific binary RPM. This can be done using the dnf database, but -dnf is not always shipped with container images. + +Although container images provide a list of repositories from which the +packages in the image are sourced, vendors may also be interested in +determining the repository that provided a specific binary RPM. It is possible +for multiple repositories to contain the same binary RPMs - this command lets +you query the system to determine which repository was used at install time. +Note that `dnf` is not always shipped with container images. + ``` # Example return of repository query $ dnf repoquery --qf "%{repoid}" libgcc-11.3.1-4.3.el9.x86_64 From 41c811a9e8704b8dc7607f20dab7141cdeb257c0 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 09:31:29 +0100 Subject: [PATCH 04/24] clarity on CVE; typo --- docs/csaf-vex.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index a8040e6..4808748 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -116,8 +116,8 @@ 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. +* `id`: Provides the official CVE ID, as published by [NVD](https://nvd.nist.gov). +* `initial_release_date`: Represents the date that Red Hat first published information on the CVE. * `revision_history`: Details any changes made to the CVE information published by Red Hat. ```json From abbeefaadc5479032abe8d64502a05edf8a10423 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 09:31:53 +0100 Subject: [PATCH 05/24] CPE definition --- docs/csaf-vex.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 4808748..504d37f 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -188,6 +188,9 @@ 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. +CPE stands for Common Platform Enumeration, and refers to a centralised database (https://nvd.nist.gov/products/cpe) that +stores unique identifiers that allow you to refer to specific versions of released products or components. + 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". From e080c7e0e8444d12a46974d72e10354bbd5528f1 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 09:32:45 +0100 Subject: [PATCH 06/24] more direct phrasing --- docs/csaf-vex.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 504d37f..b1675dc 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -222,7 +222,7 @@ always include the name of the component, a product ID and a product identificat 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. The purl identifiers for unfixed content are only available for -`rpm`, `oci` (container), and `rpmmod` (modular) purl content type. +`rpm`, `oci` (container), and `rpmmod` (modular rpm) 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. @@ -275,7 +275,7 @@ 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 +Also included in the `product_tree` section is a `relationships` object which is used by Red Hat to 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 From 78d105349c9b17bdf5591b90500c33bcf24da660 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 09:33:25 +0100 Subject: [PATCH 07/24] CSAF file vs CSAF advisory --- docs/csaf-vex.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index b1675dc..02b7aca 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -496,7 +496,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` and +that have products which fall into those statuses. For CSAF advisories, 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. From f75a678e26bbc9ba403e2459608eb554943e4491 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 09:50:00 +0100 Subject: [PATCH 08/24] update, clarify, restructure --- docs/csaf-vex.md | 58 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 42 insertions(+), 16 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 02b7aca..76b3a58 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -2,36 +2,62 @@ ## Security Data Overview -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. +Starting July 10th, 2024, Red Hat Product Security publishes CSAF advisory files for +every Red Hat Security Advisory +([RHSA](https://access.redhat.com/articles/explaining_redhat_errata)) published, as well +as CSAF VEX files for every CVE record that is associated with the Red Hat portfolio +in any way. + +This format is more capable than, and supercedes the prior data which was +formatted as Common Vulnerability Reporting Framework (CVRF) files for +advisories and Open Vulnerability and Assessment Language (OVAL) format files +for CVE information. + +See the [OVAL v2 Announcement](https://access.redhat.com/security/oval-v2-deprecation-announcement) for the timeline +of the OVAL deprecation. + + +### CSAF File Format 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, +was originally published as an open standard by OASIS Open in November 2022. CSAF provide a structured, machine-readable way of representing and sharing security advisory information across all software and hardware providers. -### CSAF Security Advisories Overview +Two types of file are published that each conform to this standard. These are "CSAF advisory files" (commonly referred to +as "CSAF files") which are created per advisory published, and "CSAF VEX files" (also referred to as "VEX files") which +are created per CVE. + + +### CSAF Advisories Overview -Red Hat's CSAF security advisory files are always associated with an RHSA. A given security advisory may describe -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](https://security.access.redhat.com/data/csaf/v2/advisories/). +Red Hat's CSAF advisory files are created for every security fix published by Red Hat. Depending on the fix, this might +describe one or more product versions, or one or more components being updated, in addition to fixes for one or more +vulnerabilities. + +These files contain the machine readable information that captures the fixes that the security update provided. + +A Red Hat Security Advisory (RHSA) will always have a CSAF advisory file associated with it. Additionally, Red Hat +Bug Advisory (RHBA) or Red Hat Enhancement Advisory (RHEA) releases that contain security fixes will have a CSAF advisory +file associated. + +Red Hat's CSAF files are publicly available per advisory [here](https://security.access.redhat.com/data/csaf/v2/advisories/). - ### CSAF 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. +The CSAF standard acknowledges the need for different use cases and has therefore defined a variety of profiles, each one +containing the necessary fields and information needed for that specific use case. Red Hat has adopted the +Vulnerability Exploitability eXchange (VEX) profile, which captures the affected (affected, not affected, fixed, etc) state +of a vulnerability across any products or components that it applies to. + +Taken together, the CSAF advisory informs of what vulnerabilities are fixed in every security update, and the VEX files give +the portfolio-wide view of what is affected versus what is fixed. 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://security.access.redhat.com/data/csaf/v2/vex/). + ### Differences from OVAL The data that is included in CSAF files differs from that included in OVAL in certain cases: From 38ddb2d7c7486ad9d7b5b11e1f6bebc1a61928ae Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 09:50:29 +0100 Subject: [PATCH 09/24] removed obsolete diffs from OVAL that was confusingly written and no longer correct --- docs/csaf-vex.md | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 76b3a58..ec25849 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -58,22 +58,6 @@ and Red Hat products. Red Hat's VEX files are publicly available per CVE [here](https://security.access.redhat.com/data/csaf/v2/vex/). -### Differences from OVAL - -The data that is included in CSAF files differs from that included in OVAL in certain cases: - -- CSAF files identify a variety of software components, not just RPMs. The identification mechanism used is purl, - which itself contains a type for each identified software component. - -- CSAF files refer to SRPMs only when listed as affected but not yet fixed components. OVAL files contain a - listing of binary RPMs but this listing proved to be difficult to maintain. Until CSAF data is improved to include - consistent lists of binary RPMs, consumers of CSAF data can look up the related SRPM (to be matched with the one in - CSAF files) for a given binary RPM with: - ```bash - # Example lookup for the vim-minimal binary RPM: - $ rpm -q --qf "%{SOURCERPM}\n" vim-minimal-8.2.2637-21.el9.x86_64 - vim-8.2.2637-21.el9.src.rpm - ``` ## Document Structure From c52eabc1ab0a7395e0b1081feeaf799056d7c15e Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 12:45:49 +0100 Subject: [PATCH 10/24] uniformity of phrasing --- docs/csaf-vex.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index ec25849..b576a88 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -40,7 +40,7 @@ A Red Hat Security Advisory (RHSA) will always have a CSAF advisory file associa Bug Advisory (RHBA) or Red Hat Enhancement Advisory (RHEA) releases that contain security fixes will have a CSAF advisory file associated. -Red Hat's CSAF files are publicly available per advisory [here](https://security.access.redhat.com/data/csaf/v2/advisories/). +Red Hat's CSAF files are public, and published per advisory [here](https://security.access.redhat.com/data/csaf/v2/advisories/). ### CSAF VEX Overview @@ -54,7 +54,9 @@ Taken together, the CSAF advisory informs of what vulnerabilities are fixed in e the portfolio-wide view of what is affected versus what is fixed. 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 +and Red Hat products. + +Red Hat's VEX files are public, and published per CVE [here](https://security.access.redhat.com/data/csaf/v2/vex/). From 1adfef78a2ed7d446db2d492fa9562a237bdf7d3 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 12:46:08 +0100 Subject: [PATCH 11/24] fix format bug - whitespace before bullet list --- docs/csaf-vex.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index b576a88..bbfdb72 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -337,6 +337,7 @@ The `vulnerabilities` section reports vulnerability metadata for the CVE and als #### 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 From c8944f1304383342da1a67216335c2933b6e1d81 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 6 Aug 2026 12:49:28 +0100 Subject: [PATCH 12/24] Add link to new vex-feed --- docs/csaf-vex.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index bbfdb72..3f1b73b 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -57,7 +57,8 @@ Red Hat's VEX files are always associated with one CVE and include fix status in and Red Hat products. Red Hat's VEX files are public, and published per CVE -[here](https://security.access.redhat.com/data/csaf/v2/vex/). +[here](https://security.access.redhat.com/data/csaf/v2/vex/) in the original format, and +[here](https://security.access.redhat.com/data/csaf/v2/vex-feed/) in the binary RPM aware format. From f621f10b839b23f92b901e1f01fe3eb12a557221 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Fri, 7 Aug 2026 16:06:48 +0100 Subject: [PATCH 13/24] First draft of binary expansion data gap --- docs/csaf-vex.md | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 3f1b73b..18b3086 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -58,7 +58,7 @@ and Red Hat products. Red Hat's VEX files are public, and published per CVE [here](https://security.access.redhat.com/data/csaf/v2/vex/) in the original format, and -[here](https://security.access.redhat.com/data/csaf/v2/vex-feed/) in the binary RPM aware format. +[here](https://security.access.redhat.com/data/csaf/v2/vex-feed/) in the newer, binary RPM aware format. @@ -329,6 +329,33 @@ For the fixed component `kernel-0:3.10.0-693.112.1.el7.src`, a relationship entr } ``` +#### Binary RPM Expansion + +RPMs can have either a one-to-one or one-to-many mapping between the Source RPM and Binary RPM(s). +Binary expansion allows the VEX data to offer a more fine-grained level of detail to describe +where vulnerabilities are present, and where they are fixed, + +Expanding single SRPMs to multiple binary RPMs comes with a potential issue when data in different places +refers to different levels. As binary expansion is rolled out, there may be a case where a CSAF Advisory +mentions a fix being made to a Source RPM, but a corresponding VEX File for the CVE listing it as being +fixed in the individual Binary RPMs. + +At the present time, End of Life (EOL) products have limited binary expansion available due to them +pre-dating the current system and missing the level of data needed to perform the mapping. + +#### Modular RPM (rpmmod) Expansion + +Similar to Binary RPM Expansion, a similiar concept applies to `rpmmod` content. In the event +that a vulnerability affects the module (the rpmmod entity) it is unlikely to affect every RPM +that the module consists of. + +Expanding rpmmod level information to rpm level allows for fine-grained detail to capture +the affectedness of the specific packages. + +As with the above, there is the need to map `rpmmod` entities to their constituent parts, and to +map in the inverse to identify what rpmmod a given part may belong to. + + ### Vulnerability Metadata The `vulnerabilities` section reports vulnerability metadata for the CVE and also contains a From d22db49994a1ccafa6fc3b302adfd454b5764943 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Mon, 10 Aug 2026 11:54:14 +0100 Subject: [PATCH 14/24] add clarity to purl introduction --- docs/purl.md | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/docs/purl.md b/docs/purl.md index 5520036..37ed52b 100644 --- a/docs/purl.md +++ b/docs/purl.md @@ -5,14 +5,8 @@ standard for identifying and locating software components throughout the open so supported by various tools and data formats and provides an easy way for representing package metadata across different contexts and ecosystems. -Red Hat uses purl to identify software components in our -[CSAF](https://www.redhat.com/en/blog/csaf-vex-documents-now-generally-available) advisory and -[VEX](https://www.redhat.com/en/blog/red-hat-vex-files-cves-are-now-generally-available) files as -well as our -[SBOM](https://www.redhat.com/en/blog/future-red-hat-security-data?channel=/en/blog/channel/security) files. We will -continue expanding our use of purl across additional security-related metadata files and software solutions in the -future as well. - +Red Hat uses purl to identify software components in our CSAF advisory and VEX files as well as our SBOM files. These files are all published [here](https://access.redhat.com/security/data). + To increase the interoperability of all tools processing purl strings, each purl generator must ensure that identical software components are identified with the same purls. Adopting a consistent purl convention across the industry improves collaboration among organizations and simplifies the exchange of (not-just-) security-related @@ -29,8 +23,7 @@ to refer to the same concept. ## Identifying RPM packages -The [`rpm` purl type](https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#rpm) identifies, -unsurprisingly, an RPM package. When it comes to the naming conventions of a single RPM file, Red Hat uses the NEVRA +As the name implies, the [`rpm` purl type](https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#rpm) identifies an RPM package. When it comes to the naming conventions of a single RPM file, Red Hat uses the NEVRA convention that follows the `-:-..rpm` file name pattern, for example `emacs-27.2-9.el9.x86_64.rpm`. For more information about RPM packaging conventions, see the [RPM Packaging Guide](https://rpm-packaging-guide.github.io/) From 00e89d668498b23f6e7948ab39db7cac5242bfea Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Wed, 12 Aug 2026 12:04:46 +0100 Subject: [PATCH 15/24] Accept coderabbit suggestion to avoid 'here' hyperlinks --- docs/csaf-vex.md | 9 +++------ docs/purl.md | 2 +- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 18b3086..135f510 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -40,7 +40,7 @@ A Red Hat Security Advisory (RHSA) will always have a CSAF advisory file associa Bug Advisory (RHBA) or Red Hat Enhancement Advisory (RHEA) releases that contain security fixes will have a CSAF advisory file associated. -Red Hat's CSAF files are public, and published per advisory [here](https://security.access.redhat.com/data/csaf/v2/advisories/). +Red Hat's CSAF files are public, and published per advisory, at . ### CSAF VEX Overview @@ -56,9 +56,7 @@ the portfolio-wide view of what is affected versus what is fixed. 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 public, and published per CVE -[here](https://security.access.redhat.com/data/csaf/v2/vex/) in the original format, and -[here](https://security.access.redhat.com/data/csaf/v2/vex-feed/) in the newer, binary RPM aware format. +Red Hat's VEX files are public, and published per CVE at in the original format, and at in the newer, binary RPM aware format. @@ -67,8 +65,7 @@ Red Hat's VEX files are public, and published per CVE Although CSAF advisory and VEX files ultimately serve different purposes, both file types meet the 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/main/csaf-vex/csaf-vex.json). +be found at . 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. diff --git a/docs/purl.md b/docs/purl.md index 37ed52b..f48222d 100644 --- a/docs/purl.md +++ b/docs/purl.md @@ -5,7 +5,7 @@ standard for identifying and locating software components throughout the open so supported by various tools and data formats and provides an easy way for representing package metadata across different contexts and ecosystems. -Red Hat uses purl to identify software components in our CSAF advisory and VEX files as well as our SBOM files. These files are all published [here](https://access.redhat.com/security/data). +Red Hat uses purl to identify software components in our CSAF advisory and VEX files as well as our SBOM files. These files are all published at . To increase the interoperability of all tools processing purl strings, each purl generator must ensure that identical software components are identified with the same purls. Adopting a consistent purl convention across the From eed1e580a698c18e687c66725e445199ff5eeba5 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Wed, 12 Aug 2026 12:05:34 +0100 Subject: [PATCH 16/24] Accept coderabbit suggestion to avoid 'here' hyperlinks --- docs/vex-ga.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/vex-ga.md b/docs/vex-ga.md index c623bcd..6a19c64 100644 --- a/docs/vex-ga.md +++ b/docs/vex-ga.md @@ -2,7 +2,7 @@ ## VEX-GA Announcement -Red Hat Product Security is pleased to share that the GA version of our new VEX (Vulnerability Exploit eXchange) files is now available [here](https://security.access.redhat.com/data/csaf/v2/vex-feed/). +Red Hat Product Security is pleased to share that the GA version of our new VEX (Vulnerability Exploit eXchange) files is now available at . ### GA Overview @@ -15,7 +15,7 @@ This new release focuses on data precision and standardizing our CSAF VEX format - **Streamlined Content**: We’ve removed unrequired fields (duplicate titles, redundant CVSS scores, unnecessary note objects) and ensured `fixed` product and components no longer appear in `workaround` remediation objects. - **Modernized Infrastructure**: We have migrated VEX publication to a completely new service that improves performance and supportability. -More detailed information on the differences between legacy VEX files and GA VEX files will be found [here](https://redhatproductsecurity.github.io/security-data-guidelines/vex-ga-details/). +More detailed information on the differences between legacy VEX files and GA VEX files will be found at . ### Bugs Fixed in GA Release From 9cb49b9796e29a31003f1a50645f0b80f1489223 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Wed, 12 Aug 2026 14:14:00 +0100 Subject: [PATCH 17/24] Address more coderabbit suggestions --- docs/csaf-vex.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index 135f510..c322c00 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -2,7 +2,7 @@ ## Security Data Overview -Starting July 10th, 2024, Red Hat Product Security publishes CSAF advisory files for +On July 10th, 2024, Red Hat Product Security started publishing CSAF advisory files for every Red Hat Security Advisory ([RHSA](https://access.redhat.com/articles/explaining_redhat_errata)) published, as well as CSAF VEX files for every CVE record that is associated with the Red Hat portfolio @@ -198,8 +198,8 @@ 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. -CPE stands for Common Platform Enumeration, and refers to a centralised database (https://nvd.nist.gov/products/cpe) that -stores unique identifiers that allow you to refer to specific versions of released products or components. +CPE stands for Common Platform Enumeration, and refers to a structured naming convention used to uniquely +identify specific versions of released products or components. A centralised database exists at that stores all published identifiers. 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". From f73e9abd8e17dae345228330e4d43c7f548740c4 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Wed, 12 Aug 2026 14:16:59 +0100 Subject: [PATCH 18/24] coderabbit suggested clarity on rhel10 and rpmmod --- docs/scanning-vendors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md index d3abf70..28a8b69 100644 --- a/docs/scanning-vendors.md +++ b/docs/scanning-vendors.md @@ -49,7 +49,7 @@ adding an extra level of granularity to the VEX data, scanners are able to exclude non-affected binary packages from vulnerabilities that are present in the shared source. -Additionally, an RPM module is a set of RPM packages that represent a higher level software component that is installed together. AppStreams are a common example of RPM modules. Note that RPM module support was removed in RHEL 10. +Additionally, an RPM module is a set of RPM packages that represent a higher level software component that is installed together. AppStreams are a common example of RPM modules. Note that RPM module support was removed in RHEL 10, to the extent that it no longer distributes modular RPM content. Although the actual functionality is scheduled for removal in a later release, `rpmmod` remains valid and is supported for prior versions. SRPMs and RPMs are represented in CSAF advisories and VEX data using the `rpm` purl type. RPM Modules are represented with the `rpm` purl type and also have a `rpmmod` modifier with additional data. More detailed information about RPM purl usage can be found [here](https://redhatproductsecurity.github.io/security-data-guidelines/purl/#identifying-rpm-packages). From df1106dff396e6ed39a41556e67d5c8bffcb3423 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Wed, 12 Aug 2026 14:21:19 +0100 Subject: [PATCH 19/24] note on rpmmods and dnf module list from coderabbit --- docs/scanning-vendors.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md index 28a8b69..5f06990 100644 --- a/docs/scanning-vendors.md +++ b/docs/scanning-vendors.md @@ -78,6 +78,10 @@ Using this information, we can format a purl for the libgcc component. pkg:rpm/redhat/libgcc@11.3.1-4.3.el9?arch=x86_64 ``` +Modular RPMs (`rpmmod`) can be queried using the `dnf module list` command (which requires the python3-dnf-plugin-modulesync package to be installed) + + + #### SRPMs The metadata for every RPM contains information on the source from which it was build. In this example, we can query a single package (`libgcc`) and use the `--qf` format option to return the name of the Source RPM from which it was created. From a280645302a64470872fb068982b0f370d1e3002 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Wed, 12 Aug 2026 14:22:06 +0100 Subject: [PATCH 20/24] date discrepancy was flagged in review --- docs/scanning-vendors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md index 5f06990..1707269 100644 --- a/docs/scanning-vendors.md +++ b/docs/scanning-vendors.md @@ -230,7 +230,7 @@ ways to identify repository information for a container image. #### Content Manifest JSON files Starting in June 2020, Content manifest JSON files were included for each layer -in the container image in the `root/buildinfo/` directory. In July 2025 this +in the container image in the `root/buildinfo/` directory. In 2025 this system was replaced (see below) with content-sets, and will be deprecated at some point in the future. From fb5a0a90eacea138033329a98be862fb9db10fe9 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Wed, 12 Aug 2026 14:26:34 +0100 Subject: [PATCH 21/24] note on repoquery limiting to only installed packages --- docs/scanning-vendors.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md index 1707269..4216039 100644 --- a/docs/scanning-vendors.md +++ b/docs/scanning-vendors.md @@ -343,6 +343,13 @@ $ dnf repoquery --qf "%{repoid}" libgcc-11.3.1-4.3.el9.x86_64 rhel-9-for-x86_64-baseos-rpms ``` +You can also limit to installed packages to ensure what is printed correlates to what has been installed, versus is available to install. For example, + +``` +$ dnf repoquery --installed --qf "%{name}: %{from_repo} %{repoid}" +``` + + ### RPM Repository to CPE mapping Red Hat maintains a JSON file to map Red Hat RPM repositories to our CPEs. Once you have identified the repositories used for the product and version by following the previous steps, you search for the repository label and determine From 95f3573f0debbfbd6ea8c8d6aa7597fbf43683c0 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Wed, 12 Aug 2026 16:03:43 +0100 Subject: [PATCH 22/24] clarity - rpmmod is a qualifier on rpm purl content type, not a content type of its own --- docs/csaf-vex.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index c322c00..6288765 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -232,7 +232,7 @@ always include the name of the component, a product ID and a product identificat 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. The purl identifiers for unfixed content are only available for -`rpm`, `oci` (container), and `rpmmod` (modular rpm) purl content type. +`rpm`, `oci` (container) purl content types. In the example below, the unfixed kernel component's name is `kernel` and doesn't include a specific version number or an architecture format. From 431b9143949efb341ceaf9a2bb5415188df1622d Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Wed, 12 Aug 2026 16:04:31 +0100 Subject: [PATCH 23/24] absolute path for /root/buildinfo/ --- docs/scanning-vendors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md index 4216039..431933a 100644 --- a/docs/scanning-vendors.md +++ b/docs/scanning-vendors.md @@ -230,7 +230,7 @@ ways to identify repository information for a container image. #### Content Manifest JSON files Starting in June 2020, Content manifest JSON files were included for each layer -in the container image in the `root/buildinfo/` directory. In 2025 this +in the container image in the `/root/buildinfo/` directory. In 2025 this system was replaced (see below) with content-sets, and will be deprecated at some point in the future. From ad434015f868260bdf1c577e49afed08b7832da9 Mon Sep 17 00:00:00 2001 From: Dave Baker Date: Thu, 13 Aug 2026 12:42:16 +0100 Subject: [PATCH 24/24] add clarity on binary expansion causing records to be removed --- docs/scanning-vendors.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/scanning-vendors.md b/docs/scanning-vendors.md index 431933a..d22560f 100644 --- a/docs/scanning-vendors.md +++ b/docs/scanning-vendors.md @@ -80,6 +80,7 @@ pkg:rpm/redhat/libgcc@11.3.1-4.3.el9?arch=x86_64 Modular RPMs (`rpmmod`) can be queried using the `dnf module list` command (which requires the python3-dnf-plugin-modulesync package to be installed) +Due to changes in "binary expansion", meaning the mapping of a vulnerability in a Source RPM to identified binary RPMs that were created from it, it is possible that the list of RPMs included might change when a VEX file is regenerated. Without fine-grained information, a vulnerability in a Source RPM will be reflected in every binary RPM that it creates. If fine-grained information later becomes available, some of these binary RPMs may no longer be in scope for the CVE and so be removed from both the "products" list, as well as the "product_status" list. #### SRPMs