Advertisement
Guest User

cvescan vs oval

a guest
Feb 16th, 2022
40
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.07 KB | None | 0 0
  1. # CVESCan vs OVAL
  2.  
  3. * Not all CVEs which exist in the cvescan database are present in the OVAL file
  4. ** This is particularly true for all CVEs which don't have a released patch yet, as OVAL only holds patch information (even though that's not a big problem since the cvescan tool ignores those entries anyway);
  5. ** but also for some that should be present, e.g. CVE-2009-4016 (picked at random), possibly being due to the fact that the CVE was never included into an USN (but still exists and has patches).
  6. * There is no clear distinction between normally-available and ESM packages, everything is just labelled as "long term support", so to distinguish we would have to try to match the "esm" substring into package versions, which could be error prone (a more solid alternative is to just look at the advisory date and infer the support state given the Ubuntu release cycle, but it'd be better if that information was explicit anyway).
  7. * There is different wording for issue severity ("severity" in OVAL vs "priority" in cvescan), and the reason is that data in the OVAL is indexed by USN, hence every entry can contain more than one CVE, and the severity scoring is blanket-assigned to the whole USN. This is not great because it means that there is effectively a loss of information regarding individual CVEs, e.g. USN-4147-1 is marked "medium" in OVAL but some of its CVES, e.g CVE-2019-15212, are actually "low" priority. I hope that `severity = max(priorities)`, so that there is no risk of downgrading a high to a medium, but cannot really tell without doing some deeper analysis.
  8. * This grouping also creates problems in associating the right version check to a certain CVE, as all checks are put in the same "criterion" list without distinction about what CVE they are actually solving. E.g. CVE-2019-15538 and CVE-2019-15220 are grouped on the same bionic USN, but actually have different patched versions.
  9. * There is no source-distribution info, only binary package names, which makes matching kernel vulnerabilities quite a lot more challenging because of how the naming convention for kernel packages is.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement