How systemic cyber risk management in software supply chains works with BOMs

#1 - A Lack of Awareness, Fit, and Expertise

SBOMs are indeed valuable but can present skewed complexity-value tradeoffs to certain consumers (e.g., B2B consumers), many of whom may either be unaware of what to do with the plethora (i.e., complexity) of information in it or not get what they want in the SBOM they have access to. One of the main reasons for this is that the tools (e.g., spreading across in-house, commercial, and open-source categories) to generate SBOMs and formats (e.g., SPDX and CycloneDX schemas) for SBOM data representations are extremely inconsistent and non-interoperable across businesses; do not translate to clear actionable information (e.g., how does an AI model/code in the SBOM communicate SSSC risk); and most importantly lack a good tool support market for consumers to make best use of SBOM information due to lack of sufficient demand. In addition, some stakeholders (e.g., those associated with OSS projects) in the software supply chain are currently not aware of SBOMs. Moreover, many software vendors and system software developers face challenges in producing SBOMs because they either do not have the right tools to generate SBOMs for many practical application settings (e.g., SBOMs for embedded C/C++ code, binaries) and/or do not have sufficient knowledge/expertise about security best practices applicable to software supply chains, and consequently might make ‘irrelevant’ SBOMs. 

Also read: Considering insurance to manage IoT-driven catastrophic cyber-risk

Action Items Mitigating Challenge – Awareness can be somewhat created by ‘enforcing’ compliance measures on SBOM stakeholders and improving education about SBOMs concerning SSSC. There should be SBOMs specific to binaries and programming languages with no package managers. A similar approach should be adopted for AI/ML frameworks (with appended training datasets) - BOMs formatted to standard schemas for better interoperability. On top of all this, SBOMs should be structured (e.g., in a top-down tree-like fashion) to be easy to browse/search and walk through, irrespective of the number of data fields. 

#2 - Increase in Data Field Complexity

SBOMs should ideally fit the needs of the application at hand. There are some fields in every SBOM that are commonly agreed upon (e.g., version numbers, license number, software components) – however, there are other fields that should be there for the purpose of improved SSSC (e.g., a link to software vulnerability database such as the NVD, AI/ML model provenance, dataset version, dataset biases, hardware part numbers) and cannot be made uniform across each SBOM due to their case based applicability – at the same time adds to the inherent issue of incompatibility and lack of interoperability between SBOM standards if added. On the flip side, the cost of increased SBOM complexity is increased with the addition of non-generic fields. 

Action Items Mitigating Challenge – SBOMs should have concise, easy-to-read specifications with fields marked as mandatory (e.g., commonly agreed upon fields) and recommended (e.g., link to vulnerability databases). Optional SBOM fields must be tagged as ‘optional’ if there are special cases where such fields are useful so that they can be of use to the general SBOM user. 

#3 - SBOM ‘Noise’

SBOMs should ideally contain all the relevant fields (from SBOM generator tools) necessary for an enterprise’s security decision-making team to make effective informed decisions (both for itself and for downstream enterprises in a software supply chain) from SBOM field dependencies and relevant data fields. In contrast, the currently available SBOMs are ‘noisy’ – either incomplete and/or inaccurate. Alternatively, SBOMs in current practice are of mixed quality as per popular consensus among SBOM stakeholders, and all the direct and transitive software (and related websites) dependency information is often missing, i.e., incomplete. Often, a dependency is removed from repositories such as package managers if they are not maintained or are known to be malicious without keeping an entry for the malware (like CVEs for vulnerabilities). Without malware codes not created in practice, it is challenging for SBOM developers to get security threat insights from dead dependency references. In addition, a dependency that is vulnerable is not necessarily a contributor to insecure software, i.e., it will be inaccurate for SBOMs to say that such a dependency will contribute to an exploitable software end product probability 1. This ‘false’ perception of inaccuracy often disincentivises creators not to produce SBOMs as the correctness requirement becomes very strict. Another source of inaccuracy is for SBOMs not to be altered in transit/sharing between one enterprise to another. 

Also read: Cyber-security management landscape of the Indian automation industry: Overview, challenges, action

Action Items Mitigating Challenge – It is better not to have an SBOM that is incomplete or inaccurate (due to the confusion it creates with users and in the downstream supply chain) than to have one. Suppose SBOMs are indeed generated using the right tools. In that case, they should be integrated with build automation that not only captures as many dependencies as possible (and that too in binaries and AI/ML models). Tools should be developed to boost the verification of SBOMs, or third-party certification processes should be put in place to verify whether dependency information in an SBOM is the same as that when created from source code and binaries. One could also think of a third-party or government-centralised database of provenance information for software/project repositories that are currently not hosted but enable SBOM developers to get information on them.  

#4 - Mis-classifying Software Vulnerabilities

Correctly classifying vulnerabilities (positive or negative) from elements in the SBOMs that affect the vulnerability of the end software product is an extremely difficult challenge. It is often the case that Common Vulnerabilities and Exposures (CVEs) identified in an upstream component do not impact the vulnerability of the software end product simply because these upstream CVEs are not used during the compilation or run-time of the end product. This practice results in false positives. Consequently, consumers might perform vulnerability analysis and find hundreds and thousands of non-critical vulnerabilities (concerning run-time or compile-time) in software components just to pressurise the vendors to upgrade libraries on these components and divert their attention and time from fixing critical vulnerabilities. As another orthogonal case, there is the practice of developers cutting and pasting code from software libraries (including LLMs in modern AI systems) instead of importing the library originating the corresponding piece of code. This practice results in false negatives as it omits known vulnerabilities associated with the code that might spring from other elements of the library that are not imported. 

Action Items Mitigating Challenge – Vulnerability-Exploitability eXchange formats allow software suppliers to check whether a vulnerability will affect the end product. However, such tools are not perfect, though they are recommended over a no-check procedure. Prevention of the ill-practice of copy-pasting should be encouraged by proper education of SBOMs are their impact on downstream software supply chain security. 

#5 - Privacy Issues

Potential privacy issues with threats to intellectual property (IP) exist. However, suppose the SBOMs are not AIBOMs, DataBOMs, or BOMs related to CPS environments. In that case, the threat to IP is insignificant unless SBOMs are shared publicly, and also because many critical IPs are usually not captured in dependencies or data fields. In the case of the increasingly popular AIBOMs, DataBOMs, or BOMs in relation to CPSs, there is the possibility of privacy breaches as the datasets on which these BOMs are built contain personally identifiable information (PII) and proprietary information. Such breaches will help business competitors and bad actors who can catalyse the launch of litigation cases and exploitation of vulnerabilities against the concerned risk-averse business. 

Action Items Mitigating Challenge – Privacy issues can be resolved using Differential Privacy (DP) and k-anonymity privacy-preserving tools though there are yet to be standardised and widespread in the enterprise industry.

Ranjan Pal of MIT Sloan School of Management, Michael Siegel of MIT Sloan School of Management,and Prof. Bodhibrata Nag of Indian Institute of Management Calcutta