Be more specific in the Sample Scenario

[tschmidtb51]

The current version reads:

As an example, consider the following evolution of a hypothetical impact analysis:

1. A software author becomes aware of a new CVE related to their product. Immediately, the author starts to check if it affects them.
2. The investigation determines the product is affected.
3. To protect their users, the author mitigates the CVE impact via a patch or other method before the vulnerable component issues a patch.

Without VEX data, users scanning the author's software will simply get a third party alert with no details on how the status is evolving. Most critically, when the product is patched (in #3), the alert becomes a false positive.

To inform consumers downstream of the vulnerability evolution, the author can issue a VEX document (in #1) when the CVE is published to let their users know it is under investigation. In #2, when the product is known to be affected, the author can ship a new VEX document, stating the product is affected and possibly some additional advice, like temporary mitigation instructions. Finally when the product is patched, its SBOM can be complemented with a new VEX document informing it is no longer affected by the CVE. Scanners could consume this document and stop alerting about the CVE as it no longer impacts the product.

I have a few comments here:

• The new VEX document in #2 could actually be an update of the VEX document issued in #1. (This also makes sense as you only have to discover the VEX once and then get the latest info whenever you retrieve the VEX.)
• If you patch a product, it is actually not longer the same product as its version changed (and there should be a new SBOM as it is a new version). The old version is still vulnerable... (as you can't change what is already shipped). This is important as otherwise someone that didn't patch would retrieve the latest VEX for that product saying that it is not vulnerable when in fact his version (since unpatched) is affected.

[luhring]

Thanks!

The new VEX document in #2 could actually be an update of the VEX document issued in #1. (This also makes sense as you only have to discover the VEX once and then get the latest info whenever you retrieve the VEX.)

I think this is true — but I also think it's just an implementation detail of the VEX data distribution model the supplier happens to use. I think considering the new document to be an update of the first is fine, but it doesn't matter whether the supplier is literally updating an existing resource or regenerating a new resource that includes additional data. And the consumer's means of fetching the latest VEX data doesn't necessarily need to be aware of the difference here, as long as it can reliably fetch the latest VEX data.

If you patch a product, it is actually not longer the same product as its version changed (and there should be a new SBOM as it is a new version). The old version is still vulnerable... (as you can't change what is already shipped). This is important as otherwise someone that didn't patch would retrieve the latest VEX for that product saying that it is not vulnerable when in fact his version (since unpatched) is affected.

This is a good point. I think this could be more clear. (Also feel free to send a PR!)

[tschmidtb51]

I think considering the new document to be an update of the first is fine, but it doesn't matter whether the supplier is literally updating an existing resource or regenerating a new resource that includes additional data.

I disagree. It makes a difference in terms of the timestamps (see #18) and document Ids. If it's a new document id needs a new ID, if the old one is updated the last_updated timestamp must change.

[puerco]

I think both cases are correct, you can update the impact status by issuing a new document, or by updating both. As Dan says it is just a detail of how you implement it and as Thomas mentions here, there are changes you need to do to the document contents.

Perhaps the documentation should mention both scenarios: What happens if you forge new documents (issue new document IDs, creation timestamp, etc) and what happens when you update an existing document (bump last_updated timestamp, increase the document version, etc).

I think both ways of issuing VEX data will be frequent so it is not overkill to show samples for both.

[tschmidtb51]

Please also see my comment in #30 and #29 (based on #25) - both are related.