This PR addresses an issue brought up by @p0lr in Issue #343. In that issue @p0lr points out that we're using deprecated CPE values and that the NIST database that we're already using indicates that the values are deprecated.
I've adjusted the matching logic in update_cpes.py so that these deprecated CPEs aren't added when we build our list of NIST issued CPEs.
I've also restructured cpe-remap.yaml so that we remap values are specific to a CPE type (a, o, h). This will allow us to remap certain older records that use the same .product value but for which the CPE would be different between service.product and os.product.
For example in the fingerprint below we couldn't have created a remap for ILOM under oracle because it would have then generated (or tried to generate) the same CPE for both hw.product and os.product.
Description
This PR addresses an issue brought up by @p0lr in Issue #343. In that issue @p0lr points out that we're using deprecated CPE values and that the NIST database that we're already using indicates that the values are deprecated.
I've adjusted the matching logic in
update_cpes.py
so that these deprecated CPEs aren't added when we build our list of NIST issued CPEs.I've also restructured
cpe-remap.yaml
so that we remap values are specific to a CPE type (a
,o
,h
). This will allow us to remap certain older records that use the same.product
value but for which the CPE would be different betweenservice.product
andos.product
.For example in the fingerprint below we couldn't have created a remap for
ILOM
underoracle
because it would have then generated (or tried to generate) the same CPE for bothhw.product
andos.product
.With the new system we can remap them independently which will help us generate CPEs for existing values without having to change them.
Motivation and Context
Correctness of results.
How Has This Been Tested?
Execution of
cpe-remap.yaml
, rspec, etc.Types of changes
Checklist: