Code change:
A few edits for brevity and conciseness Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution Signed-off-by: Steve Lasker
A VDR is a living document that can be linked to an SBOM document directly, see SPDX V2.3 K.1.9; URL
Is there a proposed change associated with this comment?
Feels like an agreement to the "Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution" above?
Thanks NAME I'd suggest the thing we want to capture with SCITT is the continual evolution of information. It's not ok to just update a document as there's no way to know what the state of the document was at a previous date. Example: Jan 1, 2022 - the software was deployed and the VDR showed (all is good). A SCITT claim was submitted, attesting to that current state Jan 10, 2022, the software was deployed, as there were no known issues. A SCITT claim On March 1, 2022 a new vulnerability was discovered that applied to the previous released and deployed software On March 2, 2022, a security auditor might ask: "Why did you deploy the net-monitor:v1` software when there's clearly a security problem? The system has the VDR report from Jan 10, when the software was deployed, to indicate no known vulnerabilities were known at that point. SCITT and the underlying evidence store will need to provide the most recent version of an artifactType, with the ability to query the history as well. Does this give you what you're looking for?
Steve, each new VDR will have a different hash value, so any/all of the VDR artifacts can be checked for trustworthiness, but the "most current VDR should always be registered in SCITT, IMO.
No additional changes are needed, just replace VEX with VDR and we're good to go.

Related discussion:
text: Makes a claim to establish its own identity as a producer of the overall SBOM. <del> The issuer in certain situations can make further claims (example claims that relate to steps that might assist independent building of the software components, to arrive at the final deliverable). </del> <ins> The issuer may make further claims, fo example: claims that relate to steps that might assist independent building of the software components. </ins> <del> Once all the claim construction is complete, make a CBOR data payload of all the claims. </del> <ins> Place all claims in a CBOR data payload for submission to SCITT. </ins> <del> Signs the payload using SCITT recommended signing scheme.  For now this will be COSE signing. </del> <ins> Signs the payload using COSE signing. </ins> <del> Submits the COSE signed object to the transparent registry. </del> <ins> Submits the COSE signed object to the SCITT instance. </ins> <del> Receives the return receipts (A COSE Countersignature object, </del> <ins> Receives the return receipts: A COSE Countersignature object, </ins> containing the inclusion proofs, the original COSE payload and a <del> signature from the transparency service). </del> <ins> signature from the transparency service. </ins> <del> Producer would then ship the software along with the return </del> <ins> Producer would then distribute the software along with the return </ins> receipts to the Software Consumer. 4.1.2. <del> A software consumer, in this case DOI, receives the software </del> <ins> A software consumer, in this case DOI, consumes the software </ins> deliverable along with return receipts from the Producer. The Consumer may choose to verify that the received software