Original text:
4.1. <del> Micro Coding Wizards (MCW) is a small, fictional, software development company providing software solutions to help manage a fleet of electric vehicles (EV) for corporations.  MCW's software solution, MCWManager, is an asset management platform specifically designed to manage electric vehicle fleets.  MCWManager tracks usage, charge level, range, and other important characteristics of each EV in the fleet.  The US Department of the Interior (DOI), a government agency has expressed interest in licensing the MCWManager software to manage a fleet of 20 Electric Vehicles, spread across the Western Region, which includes States west of the Rocky Mountains. MCW has been informed by DOI that their software will be subject to Cybersecurity Executive Order (EO) 14028 recommendations from NIST and will need to supply "Software Bill of Materials" (SBOM) and a "Vulnerability Disclosure Report" (VDR) NIST attestation to the DOI prior to procurement. </del> 4.1.1. <del> A software producer, in this case MCW, creates a digitally signed SBOM, listing all the components contained in the final "distribution package" which a software consumer downloads in preparation for deployment within their digital ecosystem.  The following steps are performed by the Software Producer: Create the "final SBOM" listing all the components contained in the final distribution package of a software product, which the customer will install into their environment.  The SBOM must follow NTIA minimum elements for SBOM's and other NTIA and NIST recommendations for SBOM, to meet Executive Order 14028 and OMB M-22-18 requirements.  (Co)SWID, SPDX or CycloneDX SBOM formats are acceptable for this artifact. </del>  <del> Digitally sign the SBOM artifact. Place the SBOM and digital signature artifacts within an access- controlled location, i.e. a customer portal, and provide the end consumer with a link to these artifacts for downloading to the customers environment. </del>  4.1.2. <del> A software consumer, in this case DOI, obtains a digitally signed SBOM artifact from a software vendor, which initiates the following risk assessment process: Produce a SHA-256 hash value for the SBOM artifact. Verify the digital signature over the SBOM artifact and identify the signing key used to sign the SBOM, referred to as the SKID (Secret Key ID), assuming the signature is verified successfully. Submit an inquiry to a trusted SCITT Registry requesting confirmation that a trust declaration is present in the registry for the combination of SHA-256 hash value and SKID associated with the SBOM. If a trust declaration is on file with the SCITT trusted registry then continue with the risk assessment, otherwise inform the consumer that the SBOM hash and SKID combination are not registered, and the risk assessment ceases. Continue with the risk assessment by performing a vulnerability search for each SBOM component, identifying any CVE's that are reported. </del>  <del> 4.2. MCW has been informed by DOI that their software will be subject to Cybersecurity Executive Order (EO) 14028 recommendations from NIST and will need to supply "Software Bill of Materials" (SBOM) and a "Vulnerability Disclosure Report" (VDR) NIST attestation to the DOI prior to procurement. </del>  <del> 4.2.1. </del>  <del> A software producer, in this case MCW, participates in a Vulnerability Disclosure Program, and generates a Vulnerability Disclosure Report listing all the known vulnerabilities and mitigations, which a software consumer downloads in preparation for deployment within their digital ecosystem.  The following steps are performed by the Software Producer: </del>  <del> Participate in a Vulnerability Disclosure program. </del>  <del> Generate a Vulnerability Disclosure Report (VDR) listing all the known vulnerabilities and mitigation plans to meet Executive Order 14028 and OMB M-22-18 requirements. </del>  <del> Digitally sign the VDR artifact. </del>  <del> Place the VDR and digital signature artifacts within an access- controlled location, i.e., a customer portal, and provide the end consumer with a link to these artifacts for downloading to the customers environment. </del>  <del> 4.2.2. </del>  <del> A software consumer, in this case DOI, obtains a digitally signed VDR artifact from a software vendor, which initiates the following risk assessment process: </del>  <del> Produce a SHA-256 hash value for the VDR artifact. </del>  <del> Verify the digital signature over the VDR artifact and identify the signing key used to sign the VDR, referred to as the SKID (Secret Key ID), assuming the signature is verified successfully. </del>  <del> Submit an inquiry to a trusted SCITT Registry requesting confirmation that a trust declaration is present in the registry for the combination of SHA-256 hash value and SKID associated with the SBOM. </del>  <del> Consumer checks SBOM against NIST NVD.  If vulnerabilities have been reported within NVD and not in the producer provided VDR, then raise an issue with the producer for report accuracy. </del>  <del> If a trust declaration is on file with the SCITT trusted registry then continue with the risk assessment, otherwise inform the consumer that the VDR hash and SKID combination are not registered, and the risk assessment ceases. </del>  <del> Continue with the risk assessment by performing a vulnerability search for each SBOM component, identifying any CVE's that are reported. </del>  <del> 4.3. </del>  <del> Consistent with the NIST Guidance and by the timelines identified below, agencies are required to obtain a self-attestation from the software producer before using the software. </del>  <del> 4.3.1. </del>  <del> An acceptable self-attestation must include the following minimum requirements: </del>  <del> The software producer's name. </del>  <del> A description of which product or products the statement refers to (preferably focused at the company or product line level and inclusive of all unclassified products sold to Federal agencies). </del>  <del> A statement attesting that the software producer follows secure development practices and tasks that are itemized in the standard self-attestation form. </del>  <del> Self-attestation is the minimum level required; however, agencies may make risk-based determinations that a third-party assessment is required due to the criticality of the service or product that is being acquired, as defined in M-21-30. </del>  <del> 4.3.2. </del>  <del> TBD </del> 

Reviewer comments:
Please note the template is based on: https://rfc-URL We would like to stick to this template and progress this document!

Revised text:
4.1.  4.1.1.  <ins> Firmware is ubiquitous.  It is in phone, watch, TV, alarm clock, baby monitor, WiFi devices and possibly even in light bulbs if one uses LED lamps.  In any given desktop or Personal Computer (PC) there is a BIOS or UEFI type firmware that people are familiar with, but there are also scores of other hidden firmware blobs running on small controllers which power things like managment engines, keyboards, network cards, hard disks, SSD's etc. </ins>  <ins> Firmware is powerful, it runs in a highest previlege level possible and is often the bedrock on which the security story of the devices it powers. </ins> 4.1.2.  <ins> Personal health monitoring devices, i.e., eHealth devices are typically battery driven and located physically on or under user control to monitor some bodily function, such as temperatire, blood pressure or pulse rate.  These devices typically connect to the Internet through an intermediary base statation, using wireless technologies.  This connection is used to report the monitored data and also to update the firmware on the health monitoring system. This public network and open distribution system produces its own security challenges. </ins>  <ins> Today, the best-in-class firmware vendors who supply the firmware also provide an update framework, which verifies the integrity and authenticity of firmware updates before allowing them to be installed. </ins>  <ins> 4.1.2.1. </ins>  <ins> Even with a robust firmware update system the following problems remain as given below: </ins>  <ins> How does the client applying the firmware update on the system know, that the received firmware is not faulty or even malicious ? </ins>  <ins> What if the signing identity used to assert the authenticity of the firmware is somehow used to sign unintended updates (whether through outright compromise as in the Realtek identity used to sign the Stuxnet worm)? </ins>  <ins> How can one ascertain that the released firmare is not subverted or compromised due to an insider risk - be it malicious or otherwise ? </ins>  <ins> How the publisher themselves even know that there deliverable has been compromised in some way, can they trust their key protection or audit logging ? </ins>  <ins> How the update client on an instance of health monitoring system know that they have been given the same update as all other devices or one especially crafted for just a small subset of fleet of devices ? </ins>  <ins> 4.2. </ins>  <ins> ### Introduction </ins>  <ins> Software Integration is a complex activity.  It essentially implies combining various different software components coming from a a range of suppliers and producing a combined executable to be given to a Device Manufacturer.  Then the executable is loaded into the device, as part of device assembly. </ins>  <ins> The complexity adds a level of security vulnerability into the delivered software. </ins>  <ins> 4.2.1. </ins>  <ins> SoftAuto Ltd and Smart Cars Ltd are two different companies that source developed integrated software that can be loaded into autonmous vehicles they produce.  Both these companies, source integrated software solution from Micro Coding Wizard (MCW) a fictitious company that sells integrated software solutions that can be loaded into specific vehicle product.  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 is been sold and is been actively used by Customer-Y. </ins>  <ins> 4.2.2. </ins>  <ins> While the software is been running on the automated vehicle, a periodic vulnerability scanning software detects some known security issue with one of the component.  Customer-Y is prompted with a "Warning Indictor" on the dashboard.  As a result, Customer-Y reports the problem to Smart Cars Ltd. </ins>  <ins> Smart Cars Ltd, while not very sure what could be the problem, under panic communicates to MCW and requests them to look into the problem. </ins>  <ins> MCW does 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 any tampering by the Vendor OS-X. </ins>  <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>  <ins> Vendor OS-X attempts to show that it did all the steps correctly. It does disclose information about the binary they delivered.  In addition to this, they also demonstrated the build environment and the architecture, they used during the build. </ins>  <ins> However there is no "Verifiable Proofs" of the statement made by Vendor OS-X. </ins>  <ins> MCW, Smart Cars Ltd., and Customer-Y now has to trust without any means of verifying the claims made by Vendor OS-X. </ins>  <ins> Vendor OS-X thinks there is some mistake on the part of MCW that has led to this situation. </ins>  <ins> The deadlock continues, with no clear resolution. </ins>  <ins> This eventually leads to loss of reputation and company closure for Vendor OS-X. </ins>