More clearly distinguish vulnerabilities in dependencies

[raboof]

Based on the discussion in #9

[rjb4standards]

One key requirement of the EU CRA is for suppliers to check for vulnerabilities before releasing a product to market.

What type of artifact will be used to provide an attestation that a product has been checked at the SBOM component level and is free of vulnerabilities before going on the EU market>

[raboof]

Yes - I meant to cover that with "Organizations MAY publish a statement on a web page specifying whether advisories for 3rd-party dependencies affect their product. If so, they SHOULD provide a machine-readable version.". I put it as a 'MAY' for now because while it'll definitely be part of a manufacturers' due diligence to assess whether the advisories for the components in their product affect them, exactly how they do that and report on it seems at the edge of what's in scope of the vulnerability management spec.

I imagine VEX and VDR will be useful for this, but I wanted to keep this PR focused on making the distinct flows/scenario's clearer, rather than getting into technical specifics. We might further tune that in a subsequent PR?

[rjb4standards]

A VEX is a "negative security advisory", indicating that a product is not affected by a vulnerability. A VDR is an attestation by a software supplier showing they have checked each SBOM component of a specific product for vulnerabilities; some product have no vulnerabilities to report. A VEX and a Security Advisory MUST have a vulnerability ID which limits its use to reporting only on known vulnerabilities.

[raboof]

Fixed conflict with main branch.