* Pete Allor: > It is why I would advocate for a CVSS review (as we do at Red Hat) and > then assign a 'Severity Rating' as that now involves how the component > is used within our software which changes HOW a > customer/downstream/user should actually view that CVE.
But is this really how it works these days? For example, if we use a component to render the in-program documentation (traditionally called “online help”, but we would consider this offline today), and the upstream for this component documents publicly that a vulnerability is being actively exploited for (user-initiated) remote code execution, we must fix the component even if it's just used in an offline documentation viewer. CVSS impact review does not change that, as far as I know. Hence the suggestion of a fork, so that upstream's exploitation announcements do not carry over 1:1 to the product. I think this fix-regardless-of-impact requirement is new. Legitimate-looking sources for inflated impact ratings have been around for more than a decade, on the other hand. Thanks, Florian
