Picky change to example justification in the spec

[garethr]

I feel like the statement

The vulnerable code was removed with a custom patch

fits vulnerable_code_not_present:

The vulnerable component is included in artifact, but the vulnerable code is not present. Typically, this case occurs when source code is configured or built in a way that excluded the vulnerable code.

better than component_not_present:

The product is not affected by the vulnerability because the component is not included. The status justification may be used to preemptively inform product users who are seeking to understand a vulnerability that is widespread, receiving a lot of attention, or is in similar products.

The statement specifically states "vulnerable code was removed" via a patch. Rather than the whole component being removed.

[luhring]

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?

[tschmidtb51]

If the code was vulnerable, and then was patched, that means the status should be fixed:
[...]
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:

100% true.