The certification policy includes a set of technical requirements and a non-technical requirement that the partner organization must fulfill.
Accurately determine Red Hat package versions to detect Red Hat security fixes backporting
The implementation is up to the partner.
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.
Provide security product license to Red Hat (with minimum one year validity)
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.
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 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.
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.