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.

[juncas2205-debug]

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)

[juncas2205-debug]

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)