diff --git a/docs/csaf-vex.md b/docs/csaf-vex.md index e8e4702..6288765 100644 --- a/docs/csaf-vex.md +++ b/docs/csaf-vex.md @@ -2,60 +2,70 @@ ## 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. +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 +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 public, and published per advisory, at . - ### 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. -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/). +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. -### Differences from OVAL +Red Hat's VEX files are always associated with one CVE and include fix status information for all vulnerable packages +and Red Hat products. -The data that is included in CSAF files differs from that included in OVAL in certain cases: +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. -- 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 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. @@ -116,8 +126,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 @@ -188,6 +198,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 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". @@ -219,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) 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. @@ -272,7 +285,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 @@ -313,6 +326,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 @@ -322,6 +362,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 @@ -493,7 +534,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. @@ -598,4 +639,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..f48222d 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 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 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/) @@ -178,7 +171,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..d22560f 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, 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). + #### 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' @@ -67,8 +78,14 @@ 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) + +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 -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 @@ -204,15 +221,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 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. ``` @@ -304,9 +329,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 @@ -314,6 +344,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 @@ -706,30 +743,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..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 @@ -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.