Re: Dealing with CVEs that apply to unspecified package versions

[Jerome Athias <athiasjerome () gmail com>]

Yes the CVE form could help. (from my experience, first versions of a CVE
sometimes do not include the exact CPE versions, the CPE are (or should be
used as) at that time a pattern (e.g. "starts with") (still helpful) and
are then sometimes (and we should understand/recognize the time/effort
needed) revised/detailed over time
OVAL could help to circumvent that issue (e.g. patterns/regex, hashes, etc.)

imho, the root cause (or main issue) is:
CVRF (or OASIS CSAF/CVRF) or CVE schema are lacking in their
models/schemas/trees what is needed to automatically handle software
components/dependencies
e.g. of what would be needed:
http://schemas.dmtf.org/wbem/cim-html/2.46.0+/CIM_SoftwareElement.html




On Wed, Mar 15, 2017 at 11:47 PM, Kurt Seifried <kseifried () redhat com>
wrote:

> On Wed, Mar 15, 2017 at 2:05 PM, Leo Famulari <leo () famulari name> wrote:
>
> > On Wed, Mar 15, 2017 at 12:27:47PM -0700, Seth Arnold wrote:
> > > I suspect the solution is for people who rely upon these scanning tools
> > to
> > > do the leg work themselves on the packages they care about. (i.e., the
> > > packages that annoy them the most.)
> >
> > I think those of us who find these tools useful should work to improve
> > the CVE database by adding the "fixed-in-version" information as it
> > becomes available.
>
> This is a major goal of
>
> 1) using the JSON format with richer data [a]
> 2) allowing other people (e.g. CVE Mentors) to edit the data
>
> [a]
> https://github.com/CVEProject/automation-working-group/blob/
> master/cve_json_schema/DRAFT-JSON-file-format-v4.md
>
>
>
> --
>
> Kurt Seifried -- Red Hat -- Product Security -- Cloud
> PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> Red Hat Product Security contact: secalert () redhat com