Original text:
3.3. <del> A released software product is accompanied by a set of complementary statements about it's security compliance and is deemed trustworthy by both producers and consumers.  After some time, new statements produced and published by third-parties show that a software component used in the software product contains a potential weakness. Over time, a statement from another third-party illustrates that the weakness is exposed in the software product in a way that it is an exploitable vulnerability.  The producer of the software product now provides a statement that confirms the linking of software component </del>  vulnerability with the software product and also issues an advisory <del> statement on how to mitigate the vulnerability ad-hoc.  Later, the </del>  producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that <del> inhibits exploitation.  A second update of the software product includes a patch to the affected software component created by the software product producer.  A third update includes an updated version of the formerly insecure software component.  For this release, both the software product and the affected software component are deemed secure by the producer and consumers. </del>  A consumer of a released software wants: <del> to know where to get these statements from producers and third- parties related to the software product in a timely and </del>  unambiguous fashion, how to attribute them to an authoritative issuer,

Reviewer comments:
NAME the revisions seem to place greater emphasis on package managers, removing the original intent. The original intent was much broader and could be applied to a wide swath of software distribution, i.e. GitHub, app stores, and package manager repos.
Sure, we can broaden the scope. Not a problem!
We had a detail discussion about this between me and Henk. Basically, I was all for the support of going to depict a real world example for each of the situation. However, this makes the document excessively long and verbose. We should make a judgment as a team as to: Where should the Use Case document reside ? Some members feel within Arch. Document, some feel as a separate RFC. Given the number of scenarios, should we abstract it to generic use case or we depict a specific example, next to each of them ? Is too long a document (when a separate RFC) acceptable to the group ?
NAME NAME NAME I have redone the PR post our meeting today. Please have a look..
This has been resolved now!
great improvements

Revised text:
3.3.  <ins> This use case is a specialization of the use case above. A released software product is often accompanied by a set of complementary statements about it's security compliance.  This gives enough confidence to both producers and consumers that the released software has a good security standard and is suitable to use. Subsequently, multiple security researchers often run sophisticated security analysis tools on the same product.  The intention is to identify any security weaknesses or vulnerabilities in the package. Initially a particluar analysis can identify itself as a simple weakness in a software component.  Over a period of time, a statement from another third-party illustrates that the weakness is exposed in the same software component in a way that it is an exploitable vulnerability.  The producer of the software product now provides a statement that confirms the linking of software component </ins> vulnerability with the software product and also issues an advisory  <ins> statement on how to mitigate the vulnerability.  At first, the </ins> producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that  <ins> inhibits exploitation.  Later, A second update of the software product includes a security patch to the affected software component from the software producer.  Finally, A third update includes a new release (updated version) of the formerly insecure software component.  For this release, both the software product and the affected software component are deemed secure by the producer and consumers. </ins> A consumer of a released software wants:  <ins> to know where to get these security statements from producers and third-parties related to the software product in a timely and </ins> unambiguous fashion, how to attribute them to an authoritative issuer,