RHSA vs CVE

[Dmitry Makovey]

Hi everybody,

Background:
we're currently going through external security audit and it's report 
enumerates things in CVE terms which paints things very "black-and-white" - 
they rely on reported package versions vs. actual vulnerabilities. To address 
this I have created a tool: 

https://github.com/droopy4096/rhsa_cve/blob/master/rhsa_cve/rhsa_cve_check.py

what it does is it fetches RHSA mapped to CVE, CPE dictionary and CVE 
databases from RedHat and Mitre.

Problem:
Working on above tool I hav erealized that mappings are "fuzzy" to generate 
reliable report. Example: CVE-2009-3094 maps to 
RHSA-2009:1580,RHSA-2010:0602,RHSA-2009:1579,RHSA-2010:0011,RHSA-2009:1461 

Now here's the trick - using RHSA data above I end up with packages like 
postgresql* in the mix where CVE-2009-3094 specifically refers to a single 
package - httpd (except it can't be reliably extracted from any of the 
official sources as far as I can tell)

The whole purpose of above is to get CVE information, find out which packages 
need to be verified, then generate the script that can be ran on a machine 
checking whether CVE is listed in the changelog as a confirmation that issue 
has been addressed (even though package version has not changed).

Question:
Is there a better way of mapping CVE to RHSA/packages? How are others dealing 
with similar situation? Manual response (esp. that every audit comes up with 
repeats of CVE's we have appealed on the last round) doesn't seem feasible. We 
have increased number of external audits as well so Crafting response to each 
one becomes burdensome.

-- 
Exterminate! Exterminate!
 -- Daleks

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

-- 
    This communication is intended for the use of the recipient to whom it
    is addressed, and may contain confidential, personal, and or privileged
    information. Please contact us immediately if you are not the intended
    recipient of this communication, and do not copy, distribute, or take
    action relying on it. Any communications received in error, or
    subsequent reply, should be deleted or destroyed.
---