FAQs
Frequently Asked Questions
(1) What is the difference between OVAL v1 and OVAL v2 feeds?
The difference between OVAL v1 and v2 is strictly structural. In OVAL v2 content is separated into streams instead of flat files or "everything" zip files.
(2) Why are OVAL v1 files deprecated?
Red Hat is no longer actively improving OVAL v1 and at some point OVAL v1 feeds will completely go away.
You will notice that OVAL v1 content is still being generated, but not for much longer. Our goal was content parity between OVAL v2 and OVAL v1; which we've achieved and thus why we'll be deprecating OVAL v1 soon.
(3) Is there OVAL v3 on the roadmap?
Currently there is no OVAL v3 on the roadmap.
Red Hat OVAL roadmap includes adding additional content to the OVAL v2 feed; namely container first (non-rpm) content. No ETA can be provided at this time.
(4) Comparison of OVAL v1 and OVAL v2 feeds revealed discrepancies in RHSAs(from RHEL 6,7,8) in the package: "kpatch-patch". There are RHSAs that exist in OVALv1 but are missing in OVAL v2 . Why is that?
As per Red Hat Product Security, Red Hat is no longer producing OVAL data for kpatch errata.
To test vulnerability of a given flaw we'd have to compare a combination of installed kernels, installed kpatches, running kernel version, and boot config. It is not meaningful to write tests based on the kpatch rpm version alone. DevOps team feels that OVAL tests written based on the kpatch rpm version alone can lead to false positives. What is seen in the OVAL v1 feed, for package “kpatch-patch” is likely just leftover data.
Red Hat is considering kpatch in OVAL v2 files referencing the kernel; but it is not on the roadmap at this time.
(5) Why are there RHSAs without CVEs?
Examples:
Very rarely you will see a Red Hat Security Advisory (RHSA) without a CVE.
RHSA-2018:0007 and RHSA-2018:0023 were regarding the “Spectre and Meltdown vulnerabilities”. The fix was for multiple architectures and spread across multiple errata, so for tracking purposes the CVE field was left blank (to prevent a 1:1 mapping). The guidance is if the CVE field is blank in the advisory then
this is an exception and
this is very very rare, ie. an outlier.
(6) Would OVAL v2 definitions be available in JSON format similar to what's available here ?
Currently there is no plan to provide OVAL 2 definitions via JSON. We might add them to the roadmap in the future as we work through current priorities.
(7) Unpatched vulnerabilities, within OVAL v2 streams, are published in 2 different files. Example from RHEL7:
rhel-7-including-unpatched.oval.xml.bz2
rhel-7-extras-including-unpatched.oval.xml.bz2 ; what is the difference between the two?
The RHEL Extras channel is intended to give customers access to select, rapidly evolving technologies. These technologies may be updated more frequently than they would otherwise be in a Red Hat Enterprise Linux minor release. RHEL extras is essentially a separate CPE than RHEL.
More information on RHEL “Extras” can be found here .
(8) Does Red Hat plan to add CVSSv3 to all backdated RHSAs?
No, Red Hat does not plan to add CVSSv3 base score to backdated RHSAs.
(9) For the patched vulnerabilities stream each rpminfo_test has object_ref and state_ref. Regarding tests for unpatched vulnerabilities stream, in OVAL v2, some rpm_infotest(s) omit the state_ref section.
(a) Why is there a difference between the two?
(b) When the state isn't listed, does that mean all versions are affected?
(a) In a "fixed" or "patched" OVAL definition there is a fix released for the erratum. So the tests are essentially checking if "$version < whatever the erratum released" is installed. The state_ref is where the "< $version" test is specified. In the "unfixed" or "unpatched" OVAL definitions there is no version to work with, so it's a simple "X is installed" test. Hence there is no state_ref. (b) It means the same thing as us putting an "affected" entry on a CVE: it indicates that Red Hat evaluated the latest version for that product and found it vulnerable. It means Red Hat doesn’t have a fix yet. It doesn't necessarily mean that old versions are also affected. Red Hat doesn’t evaluate all the old versions.
(10) Is there a 1:1 mapping between CPE and Red Hat platform (product)?
Yes, these mappings can be found here. These mappings are maintained by Red Hat Product Security.
(11) Does the platform title here represent a repository?
No, the title doesn't always represent a repository as there is not necessarily 1:1 relationship between platform and repository. This is why we maintain repository to cpe mapping JSON.
Last updated