RHSA vs CVE

[Samuel Folk-Williams]

Hi - this article should help: https://access.redhat.com/knowledge/articles/124913

Feel free to comment there with addition questions as well.

-Sam

----- Original Message -----
> 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.
> ---
> 
> --
> redhat-sysadmin-list mailing list
> redhat-sysadmin-list at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list
>