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.

Chapter 1. Introduction to the Vulnerability Scanner Certification

1.1 Prerequisites

To start your certification journey, you must:

• Join the Red Hat Partner Connect 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, 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

• RH Severity

• RH CVSS (if reported separately from CVSS field)

• Link / resource / fix information (field where RHSA would be reported)

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

• Container Name

• Container Version Tag

• Full Path name

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.

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

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

Upon successful completion of Red Hat OpenShift Software Certification an entry will be published to the Red Hat Ecosystem Catalog. 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 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 streams with their security solutions.

Success criteria : Partner report consumes Red Hat CSAF-VEX reports

Learn more about Red Hat VEX files

2.2 Red Hat Security Fixes - RPMs

Requirement : In an effort to minimize false positives, the certification requires that the security tool accurately determines Red Hat package versions and takes into account the Red Hat security patches.

Details : Red Hat uses the term 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.

Success criteria : Partners report follows Red Hat Security patch policy and Red Hat product versioning.

Learn more about Red Hat security fixes backporting

2.3 Red Hat Severity Ratings

Requirement : Partners must use CVE metadata (Severity and the CVSS metrics) provided by Red Hat.

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 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 (Low, Moderate, Important, and Critical) which provide insight why Red Hat scores might differ from NVD scores.

Success criteria : Partners report should use Red Hat CVE metadata

Learn more about Red Hat Severity Ratings

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 that matches the affected vulnerable component and the impacted artifact.

Success criteria : Partners report should correct associated RHSA

2.5 Non-RPM content in the container images

Requirement : To correctly detect the fix state for container images and affected non-RPM content, you must consume data from CSAF/VEX.

Details : Many Red Hat layered, containerized products (like OpenShift) use the container image names in the security data to express vulnerabilities in the non-RPM content in those containers.

For example see CVE-2021-23337.

You will find there many container names because the vulnerable nodejs-lodash is bundled there and it’s shipped there as non-RPM content (if that would be shipped in the container as part of the installed rpm, then on the affected components list there will be listed rpm package name instead of the container name).

Success criteria : Partners correctly detect fix state for container images and affected non-RPM content