Using SBOMs to Secure Industrial IoT Devices
software using organization to “ look over the shoulder ” of the supplier by identifying potentially risky components in a product , then having a conversation with the supplier about how they will mitigate those risks through patching or other means . Even if the supplier does not provide a patch for a vulnerability , in many cases there are other mitigations a user organization can apply to reduce the risk due to the vulnerability .
There are currently two mature , full-featured SBOM formats : CycloneDX 3 and SPDX 4 . Both can be represented in multiple forms , including spreadsheets . However , the two most widely used representations of both formats are JSON and XML .
There is another , even more recently developed , document type called VEX ( an acronym for Vulnerability Exploitability eXchange ), which is tied closely with the SBOM concept . VEX documents were developed to solve a specific problem that became apparent only as SBOMs became more widely produced and used for software vulnerability management purposes .
The problem is that a high percentage ( perhaps over 90 %) of vulnerabilities that are found in components of a software product are not in fact exploitable in the product itself . This means that an attacker will not be able to utilize that vulnerability to compromise the product . It also means that someone scanning an instance of the product for that vulnerability will not find it .
Of course , most security professionals will ask , “ Why is it a ‘ problem ’ that a vulnerability isn ’ t exploitable in a product ? Isn ’ t that a good thing ?” While it is a good thing , there ’ s also a problem : The software user currently has no way of knowing , when they find that a component of a product contains a serious vulnerability , whether or not the vulnerability is exploitable in the product itself . This means that software users may waste a lot of time scanning for and patching vulnerabilities that aren ’ t exploitable .
Moreover , if users don ’ t know which vulnerabilities aren ’ t exploitable , they are likely to overwhelm the support lines of their suppliers with calls about non-exploitable vulnerabilities . This will increase the suppliers ’ support costs , as well as the level of frustration of support staff members . If nothing were done about this , it could ultimately result in SBOMs no longer being distributed or used .
There are many reasons why a component vulnerability might not be exploitable in the product itself . A common example is that , even though a developer included one or two modules of a library that contains four modules in their product , they did not implement the module that is subject to the vulnerability . Therefore , an attacker trying to exploit that vulnerability to compromise the product will never succeed .
July 2022