I think it's not picky! It's important for us to be clear on how to use these values if we expect them to be used correctly.
I agree the current version is a bit confusing. I almost think the "was removed" verbiage is at odds with the not_affected status itself, regardless of justification.
If the code was vulnerable, and then was patched, that means the status should be fixed:
fixed — These product versions contain a fix for the vulnerability.
I believe the intent behind the not_affected status is that the artifact wasn't exploitable in the first place, despite what a vulnerability scan may have indicated:
not_affected — No remediation is required regarding this vulnerability. A not_affected status required the addition of a justification to the statement.
My current thinking is that more clarity in the spec is needed to disambiguate not_affected and fixed more broadly.
But for this PR... in addition to your justification change, maybe we could also tweak the impact statement too? E.g.
- The vulnerable code was removed with a custom patch
+ The vulnerable code is not included when this component is packaged
WDYT?
Originally posted by @luhring in openvex/spec#13 (comment)
I think it's not picky! It's important for us to be clear on how to use these values if we expect them to be used correctly.
I agree the current version is a bit confusing. I almost think the "was removed" verbiage is at odds with the
not_affectedstatus itself, regardless of justification.If the code was vulnerable, and then was patched, that means the status should be
fixed:I believe the intent behind the
not_affectedstatus is that the artifact wasn't exploitable in the first place, despite what a vulnerability scan may have indicated:My current thinking is that more clarity in the spec is needed to disambiguate
not_affectedandfixedmore broadly.But for this PR... in addition to your justification change, maybe we could also tweak the impact statement too? E.g.
WDYT?
Originally posted by @luhring in openvex/spec#13 (comment)