Using SBOMs to Secure Industrial IoT Devices
B . Parse SBOMs as they are received , yielding the names of components included in the software product . Using those names , look up each component in a vulnerability database like the US National Vulnerability Database ( NVD ) 11 .
C . Retrieve a list of any open vulnerabilities found in the NVD , for each of the components in a software product . In the NVD , vulnerabilities are identified with a CVE record 12 .
D . Compile these vulnerabilities into a list of open component vulnerabilities for each software product for which the user organization receives SBOMs . These lists should be updated regularly ( preferably daily ) by checking with the NVD . Initially , every vulnerability on the list should be assumed to be exploitable in the product itself , until a VEX document from the supplier changes that designation . Note that the list will change from version to version of the product , as new vulnerabilities are identified , and existing ones are patched . Therefore , if an organization operates multiple versions of one software product , they should maintain this list for each version . 13
E . Parse VEX documents received from suppliers . The primary purpose for which VEXes were developed is to identify component vulnerabilities that are not exploitable in the full product , even though they are exploitable in the component by itself . Therefore , whenever the user receives a VEX stating that a particular vulnerability isn ’ t exploitable in one or more versions of the product , the tool should remove that vulnerability from the list of open component vulnerabilities in the appropriate version ( s ) of that product . This way , the list of vulnerabilities for a product will always include only vulnerabilities that are known to be exploitable in the product .
F . If the above steps are performed regularly ( preferably every day or even continually ), the user organization will be able to obtain , at any time , an up-to-date list of exploitable component vulnerabilities in each of the user-managed software products it operates . This
11
https :// nvd . nist . gov /. In order to identify vulnerabilities for a particular component in the NVD , the user must have a CPE ( Common Platform Enumeration ) name for the component . The format for CPE names is described here :
https :// cpe . mitre . org / specification /. To eliminate the need for SBOM users to go through the often-laborious process of searching for a CPE name on their own , it is the authors ’ opinion that the supplier of the product described in the SBOM should attempt to provide the CPE name for every component listed in the SBOM .
If the developer of a component has never reported a vulnerability for it , there may not be a CPE name for the component . If the supplier of the product cannot find a CPE name for a component in the product , they should create one according to the MITRE specification and include that CPE name in the SBOM . The supplier should try never to leave the component CPE name field empty .
12
13
This list is very sensitive information . It might well provide a “ roadmap for the attacker ” if the wrong party got ahold of it . It should never be transmitted over the internet unencrypted .
76 July 2022