The customer of an IoT or IIoT device should require the device manufacturer to develop and follow a Component Security Management Program , including the following provisions 19 :
1 . Register the device in the National Vulnerability Database with its own CPE name .
2 . Provide , to each device customer that has signed an appropriate non-disclosure agreement ( NDA ), a complete software bill of materials ( SBOM ) for the device , in either the CycloneDX or SPDX format . The SBOM must list every software or firmware product installed in the device , including that product ’ s CPE name and version number . A new SBOM must be issued – along with a new version number – whenever a software update is issued for the device .
3 . Whenever a vulnerability in one of the software or firmware products installed in the device is determined not to be exploitable in one or more versions of the device , the manufacturer should provide a VEX document to each customer , informing them of this fact . 20 . All other component vulnerabilities will be considered by the customer to be exploitable ; the customer will hold the manufacturer responsible for ensuring they are patched or otherwise mitigated .
4 . Forward all SBOMs and VEX documents received from suppliers of software or firmware installed in the device to customers of the device , as long as the customer has signed whatever NDA is required by the software or firmware supplier .
themselves . It is unacceptable for a manufacturer to leave a product in their device if it contains a serious unpatched vulnerability .
The above applies to open source software products , but a similar risk applies to proprietary software : since proprietary software is almost always provided as compiled binaries , if the supplier of a software product installed in the device goes out of business , the device manufacturer will have no way to patch a serious vulnerability . One important risk-reduction measure a manufacturer can take is to require that the product supplier ( perhaps for an extra cost ) provide the source code for any product provided as binaries . That way , if the supplier goes out of business , the manufacturer can fix the product themselves .
19
These provisions are not intended to be legal language , although they can form the basis for contract terms .
20
A single VEX document can list the exploitability status of multiple vulnerabilities in one product or in multiple products . However , given how new the VEX concept is , it is better now to confine one VEX to one product , although addressing multiple vulnerabilities for one product in a single VEX is completely acceptable .
Journal of Innovation 79