Code change:
3.8. <del> ### Introduction Software Integration is a complex activity.  It implies combining various software components from multiple suppliers and producing an integrated package deployed as part of device assembly and provisioning. </del> <ins> Software Integration is a complex activity.  This typically involves getting various software components from multiple suppliers and producing an integrated package deployed as part of device assembly. </ins> <del> Integration complexity creates a higher risk of security vulnerabilities to the delivered software. </del> <ins> Car manufacturers source integrated software for their autonomous vehicles from third parties that integrates software components from various sources.  Integration complexity creates a higher risk of security vulnerabilities to the delivered software. </ins> 3.8.1. <del> SoftAuto Ltd and Smart Cars Ltd are two different companies that source third-party integrated software for the autonomous vehicles they produce.  Both these companies source integrated software solutions from Micro Coding Wizard (MCW), a fictitious company that sells integrated software solutions.  MCW assembles the OS from Vendor OS-X that is built on top of firmware released by Component Vendor-A and then integrates a package manager and some open-source libraries to make the final software product.  The assembled software is loaded onto a car manufactured by Smart Cars Ltd. The car has been sold and is actively used by Customer-Y. 3.8.2. </del> While the software runs on the automated vehicle, periodic vulnerability scanning software detects a known security issue <del> with one component.  Customer-Y is prompted with a "Warning Indicator" on the dashboard.  As a result, Customer-Y reports the problem to Smart Cars Ltd. </del> <ins> with one component.  End User gets a "Warning Indicator" on the dashboard.  As a result it reports the problem to the car manufacturer.  It is then subsequently notified to the integrator. </ins> <del> Smart Cars Ltd, has little insight into the root cause of the error, communicates to MCW, and requests them to look into the problem. MCW does an initial investigation and suspects that the binary received from Vendor OS-X has some problems.  It demands specific environment and architectural details associated with the built operating systems binary to ascertain that the software was produced without tampering by Vendor OS-X. </del> <ins> Integrator analysis leads to a suspected issue with the supplied Operating System (OS) software from an Independent Software Vendor (ISV).  It demands specific environment and architectural details associated with the built OS binary to ascertain that the software was produced without tampering by Vendor </ins> Unfortunately, there is no way for the integrator to know if the binary was compromised, so the integrator is concerned they may have delivered malware unknowingly to their customers. <del> Vendor OS-X attempts to show that it did all the steps correctly. It does disclose information about the binary they delivered.  In </del> <ins> ISV attempts to show that it did all the steps correctly.  It does disclose information about the binary they delivered.  In </ins> addition, they also reveal their build environment and the architecture they used during the build. However, there are no "Verifiable Proofs" of the statement made by <del> Vendor OS-X. MCW, Smart Cars Ltd., and Customer-Y now have to trust without the ability to verify the claims made by Vendor OS-X. Vendor OS-X thinks there is some mistake on the part of MCW that has led to this situation. The deadlock continues, with no clear resolution. </del> <ins> ISV.  All the stakeholders, in the ecosystem (end user, car manufacturer and the integrator) has to trust without any ability to verify the claims made by the ISV. </ins> This eventually leads to a loss of reputation and company closure for Vendor OS-X.

Related discussion:
text: 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