# Certification Policy Guide

The Vulnerability Scanner Certification Policy Guide describes the policy overview to certify third-party vendor security scaninng products.

This guide is intended for partners who want to offer their products for use with Red Hat security best practices in a jointly supported customer environment.&#x20;

## Chapter 1. Introduction to the Vulnerability Scanner Certification

### 1.1 Prerequisites

To start your certification journey, you must:

* Join the [Red Hat Partner Connect](https://connect.redhat.com/) program.
* Provide basic information about your company and the products you need to certify. Common information includes a product overview and links to supporting collateral such as product documentation, datasheets, or other relevant resources.
* Establish a support relationship with Red Hat. You can do this through the multi-vendor support network of [TSANet](https://redhatconnect.connect.tsanet.org/#/), or through a custom support agreement.

### 1.2 Vendor Certification Submission: Report File Format and Structure

In order for Red Hat to review the vendor’s vulnerability scan report, the Partner will be required to provide a report that complies with Red Hat format requirements.

Partners will be required to share a **CSV file format** report for the technical review, with the following structure

* CVE ID
* Package
* Package version&#x20;
* RH Severity&#x20;
* RH CVSS (if reported separately from CVSS field)&#x20;
* Link / resource / fix information (field where RHSA would be reported)

In addition, the following fields are optional, but will greatly help for the Certification review :

* Container Name
* Container Version Tag&#x20;
* PURL

### 1.3 Recertification

Recertification occurs once per year for every Certified Partners

During the re-certification process Certified Partners are required to scan once again the Red Hat test-harness images and deliver the results by starting a new [certification cycle](workflow).&#x20;

Scanning results should be shipped in 1 month after the re-certification process starts.&#x20;

When the reports are delivered, Red Hat will perform verification and provide the results. The feedback time will depend on various factors, but mainly on the number of issues that the security team needs to address concerning your scanner. Ideally, our security engineers will share their comments with you between 1 to 4 weeks. This time will **NOT** be accounted into the two-month “grace period”. In other words, we will not flag your scanner for delays depending on our side.

After RH published  the newest harness images, you have a **two-month "grace period"** to start the recertification process, or to share with us your certification plans and roadmap. After two months your scanner will be “date-flagged”.

### 1.4 Publishing to Red Hat Ecosystem Catalog&#x20;

Upon successful completion of Red Hat OpenShift Software Certification an entry will be published to the [Red Hat Ecosystem Catalog](https://catalog.redhat.com/software/vulnerability-scanner/search). This will include a product entry and relevant information collected as part of the process.

It is required for Partners that upon Certification, their Ecosystem Catalog Description accurately and only reflects what Red Hat has specifically tested and certified. Partners will include software version information with their certification.

After successful certification your product is published on the Red Hat Ecosystem Catalog. Contact the Red Hat certification team, if you want to remove the certified products or certification from the catalog.



## Chapter 2. Requirements for Vulnerability Scanner reports

The scope of Red Hat Vulnerability Scanner Certification is limited to Red Hat RPM packages and Red Hat RHEL streams (including RHEL layered products).\
Red Hat encourages also to use the [Security Data API](https://www.redhat.com/en/blog/gathering-security-data-using-red-hat-security-data-api) for gathering information about the non-RPM content.

### 2.1 Red Hat Security Data Use: CSAF-VEX

**Requirement :** Instead of each Security ISV making their own determination as to which Red Hat security data they consume and report on, with guidance from Red Hat Product Security, as part of certification partners can now standardize on consuming the [**CSAF-VEX** ](https://security.access.redhat.com/data/csaf/v2/vex/?extIdCarryOver=true\&sc_cid=701f2000001OH7EAAW?extIdCarryOver=true\&sc_cid=701f2000001OH7EAAW)files with their security solutions.

**Success criteria :** Partner report consumes Red Hat CSAF-VEX files

{% hint style="info" %}
Learn more about [**Red Hat VEX files**](https://redhatproductsecurity.github.io/security-data-guidelines/csaf-vex/)
{% endhint %}

### 2.2 Red Hat Package Identification

**Requirement :** In an effort to minimize false positives, the certification requires that the security tool accurately determines Red Hat package versions for RPMs, RPM modules and non-RPM content (container first non-rpm content and maven content).

**Details :** Red Hat uses the term [backporting](https://access.redhat.com/security/updates/backporting) to describe the action of taking a fix for a security flaw out of the most recent version of an upstream software package and applying that fix to an older version of the package Red Hat distributes.

When Red Hat backports security fixes, Red Hat:

* identifies the fixes and isolate them from any other changes
* makes sure the fixes do not introduce unwanted side effects
* applies the fixes to our previously released versions

It is important not to make decisions about vulnerabilities based solely on the version number of the software package detected. This can result in false positives since backported security fixes are not taken into account.&#x20;

**Success criteria :** Partners report follows Red Hat product versioning.

{% hint style="info" %}
Learn more about [**Red Hat security fixes backporting**](https://www.redhat.com/en/blog/what-backporting-and-how-does-it-apply-rhel-and-other-red-hat-products)
{% endhint %}

### 2.3 Red Hat Severity Ratings

**Requirement :** Customers must always provide Red Hat CVE metadata (Severity and the CVSS metrics) in the default scan report. If Red Hat CVE metadata is reported separately from the general Severity and CVSS fields, it should not require additional customer configuration to enable this information in the scan report.

**Details :** Red Hat Product Security rates the severity of security issues found in Red Hat products using a four-point scale (Low, Moderate, Important, and Critical), as well as including a separate Common Vulnerability Scoring System (CVSS) base score. These scoring systems provide a prioritized risk assessment to help our customers understand and schedule upgrades to their systems, enabling informed decisions on the risk each issue places on their unique environment.

For open source software shipped by multiple vendors, the CVSS base scores may vary for each vendor's version, depending on the version they ship, how they ship it, the platform, and even how the software is compiled. This makes scoring vulnerabilities difficult for third-party vulnerability databases, such as NVD, who can give only a single CVSS base score to each vulnerability, or when comparing to other vendors who score based on the characteristics of use in their own products. See the [National Vulnerability Database](https://nvd.nist.gov/vuln-metrics/cvss) for more information regarding NVD security ratings.

These differences can cause the scores to vary widely. Other reasons may include how the source code was compiled with certain compiler flags or hardening technologies that reduce or eliminate the security severity of a flaw, or how the software is used within the product. Software running standalone may suffer from a flaw, but its use within a product may preclude the vulnerable code from ever being used in a way that could be exploited.

For these reasons, Red Hat Product Security recommends that, whenever possible, customers use a CVSS base score provided by Red Hat in preference to a score from a third party. Hence one of the requirements for certification is that the security product must make provision to display [Red Hat four-point scale severity ratings](https://access.redhat.com/security/updates/classification/) (Low, Moderate, Important, and Critical) which provide insight why Red Hat scores might differ from NVD scores.&#x20;

**Success criteria :** Partners report should use Red Hat CVE metadata

{% hint style="info" %}
Learn more about [**Red Hat Severity Ratings**](https://access.redhat.com/security/updates/classification)
{% endhint %}

### 2.4 Red Hat Security Fixes - RHSAs

**Requirement :** For CVEs that have available fixes released by Red Hat, Partners should accurately report the correct associated [**RHSA**](https://access.redhat.com/articles/explaining_redhat_errata) that matches the affected vulnerable component and the impacted artifact.

**Success criteria :** Partners report should correct associated RHSA



### 2.5 Red Hat Not Affected CVEs

**Requirement :** CVEs that have been marked as **Not affected** by Red Hat should not be reported in the scan results. Additionally, any CVEs that have been rejected or disputed should also not be displayed or should be clearly reported with this information.

**Success criteria :** Partner accurately reflects if a vulnerability is not affected for Red Hat software
