Original text:
devices or one specially crafted for just a small subset of a fleet of devices? <del> 3.8. ### 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>  <del> Integration complexity creates a higher risk of security vulnerabilities to the delivered software. </del>  <del> 3.8.1. 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. </del>  <del> 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. Smart Cars Ltd, has little insight into the root cause of the error, communicates to MCW, and requests them to look into the problem. </del>  <del> 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>  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>  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>  This eventually leads to a loss of reputation and company closure for Vendor OS-X.

Reviewer comments:
Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!

Revised text:
devices or one specially crafted for just a small subset of a fleet of devices?  <ins> 3.9. </ins>  <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>  <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>  <ins> 3.9.1. </ins> While the software runs on the automated vehicle, periodic vulnerability scanning software detects a known security issue  <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>  <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.  <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  <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.