Certification Requirements
Red Hat Vulnerability Scanner Certification Policy
The certification policy includes a set of technical requirements and a non-technical requirement that the partner organization must fulfill.
Technical requirements
Accurately determine Red Hat package versions to detect Red Hat security fixes backporting
The implementation is up to the partner.
For RHEL layered products, like containerized products (OpenShift), you should use specific for that product OVAL feeds available at https://www.redhat.com/security/data/oval/v2/. You may also use the Red Hat Security Data API to consume necessary security information. In this API there is information for RPM and non-RPM content in Red Hat products. For RPMs the adoption is similar to OVAL v2. For non-RPM content in the container images please read details below.
Integrate Red Hat four point scale severity rating in your scan results
In addition to any other severity (impact) rating; display Red Hat Severity Ratings (Critical, Important, Moderate, Low) as they apply to each CVE detected in scan results.
Clearly display or suppress vulnerabilities (CVEs) fixed by Red Hat where applicable.
For vulnerabilities which Red Hat has fixed (patched), either suppress those vulnerabilities in the scan results or display the vulnerabilities with associated Red Hat Security Advisory (RHSA) describing the fix provided by Red Hat.
Non-technical requirement
Provide security product license to Red Hat (with minimum one year validity)
Scanners vendors must provide evidence that consumed Red Hat Security Data are correctly displayed on the scanner report
In order to maintain the certified status the partner product must be re-certified under two circumstances
If a new major version of the certified product is released
If the test harness images for certification are updated (once a year)
*Appropriate partner communication will be generated in case the test harness images for certification are updated.
Please note that the terms vulnerability and CVE are used interchangeably throughout this document.
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 creating new ticket via PAD.
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 via PAD (Partner Acceleration Desk), or to share with us your certification plans and roadmap. After two months your scanner will be “date-flagged”.
Certification requirement details
Red Hat OVAL v2
The Red Hat Product Security (PS) has long published security data for Red Hat products and packages through various resources including: Common Vulnerability Reporting Framework (CVRF) documents, Open Vulnerability and Assessment Language (OVAL) definitions, the Red Hat Common Vulnerabilities and Exposure (CVE) database, RPM to CVE mappings, Common Platform Enumeration (CPE) dictionary, etc. (An alternative representation of these resources is also available through the Red Hat Security Data API.)
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 Red Hat OVAL v2 streams in their security solutions.
The Red Hat Product Security team has recently enhanced the Red Hat OVAL v2 feed for high volume commercial consumption that includes new features like product-version specific patched and un-patched streams. This comprehensive OVAL v2 security data feed
aims to minimize false positives and other discrepancies as a result of product and version specific OVAL streams and
makes it possible to report on CVEs which are fixed (patched) by Red Hat as well as those which are yet to be fixed (unpatched) or will not be fixed by Red Hat or do not affect specific packages based on the product stream; with the addition of product-version specific unpatched streams.
To learn more about Red Hat OVAL v2 refer to "Technical Guidance on adopting Red Hat OVAL v2" guide
Red Hat Security fixes Backporting
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.
In an effort to minimize false positives the certification requires that the security product accurately determines Red Hat package versions taking into account the Red Hat security backporting during vulnerability risk assessment of Red Hat products and packages.
Red Hat Severity Ratings
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.
Differences Between NVD and Red Hat Scores
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.
Providing software license for your security product to Red Hat
From time to time Red Hat Product Security works with Red Hat support teams to resolve reported vulnerability risk inconsistencies between Red Hat and partner security products. As part of certification we request a software license of your product, with one year validity, for in-house testing under such circumstances.
Non-RPM content in the container images (container first scanning)
To correctly detect the fix state for container images and affected non-RPM content there, you must consume data from the Red Hat Security Data API, because non-RPM content is not supported yet by OVAL data format.
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).
By querying the Security Data API endpoints you get details about the fix status for a specific container image.
To learn how to use Security Data API read Gathering security data using the Red Hat Security Data API blog post.
Additionally you may see upstream projects where non-RPM content security data gathering is already implemented:
cve-analyserproject
Last updated