Generative Pre-Trained Transformers, Natural Language Processing and Artificial Intelligence and Machine Learning (AI/ML) in Software Vulnerability Management: automations in the Software Bill of Materials (SBOM) and the Vulnerability-Exploitability eXchange (VEX)

1. Introduction

This article addresses problems associated with cyber vulnerability management, going into details about Common Security Advisory Framework (CSAF), and the relationship between the Software Bill of Materials (SBOM) and the Vulnerability Exploitability eXchange (VEX) and the implementation. The main aim of the article is to present solution for automation in the SBOM/VEX implementation process, because asset owners operate with priorities related to revenue, uptime, maintenance, but cybersecurity is not one of their key priorities. Regulatory requirements can be priority, especially if they are related to safety, asset owners will have to comply with the regulation, but it’s not their main priority for operations. Since cybersecurity is not a priority, it’s also quite down on the list of operations. This article is covering only a small part of the cybersecurity operations, which is the updates and patch management. Narrowing the focus even more, from the three different types of patches (1) feature update, (2) bug fixes, and (3) security fixes, the topic of interest in this article is most closely related to security fixes. The reason is that for the first two patches, there is a routine maintenance schedule, but for the security fixes, it is difficult to allocate any other time than the time of resolution.

1.1. Data Sources

Although the number of records was very limited, the results were extremely interesting. We discovered that VEX has been considered for use in the US Nuclear Industry [6], for resolving software supply chain insecurities in vehicles [7], and the most interesting document was a Bachelors thesis on the ‘Development of an API to request security advisories for CSAF 2.0’ [8]. The document is surprisingly detailed, and given more time, this effort could have solved the CBOM/VEX integration and automation problem. Bachelors’ thesis is however a very short project, and as a rule, 8-12 weeks are allowed maximum. Nevertheless, the thesis presents a solid grounding on building the API proposed in this paper. The Google search on "software bill of materials" resulted with 367 records, and the most relevant records are included in the case study research as secondary data sources on specific issues, but there is no solution to the SBOM/VEX automation problem in current literature.

1.2. Methods for Analysis

To analyse the data records, the case study research method is applied, in combination with grounded theory to categorise data records into axes. The emerging solutions are derived from multiple sources and verified through workshops with the study participants. Experimental testing of the solutions was conducted in the Oxford e-Research Centre.

2. Brief Literature Rreview of Cybersecurity Reports on VEX and SBOM

2.1. What is Software Supply Chain Cyber Risk

Software Supply Chain can be defined as the collection of components, libraries, tools, and processes used to develop, build, and publish the software. In supply chain manufacturing, there is a well-established concept of a ‘bill of materials’ (BOM) [9]. In more recent developments, the same principles are applied to software supply chains. The ‘Cyber Supply Chain Management and Transparency Act of 2014’ [10] proposed that US government agencies obtain SBOMs for all new software. This led to the ‘Internet of Things Cybersecurity Improvement Act of 2017’ [11], and more recently, ‘The US Executive Order on Improving the Nation’s Cybersecurity of May 12, 2021 [12] ordered The National Institute of Standards and Technology (NIST) to issue guidance on ‘providing a purchaser a Software Bill of Materials (SBOM) for each product.’

2.2. What Is the Software Bill of Materials (SBOM) and How Does It Help with Cyber Risk Assessment

The Software Bill of Materials (SBOM) can be defined as a nested (machine-readable) inventory for software, a list of ingredients that make up software components and dependencies, and their hierarchical relationships [13,14]. The main use cases include supply chain assets and vulnerabilities management via sharing and exchanging SBOMs, but because of ‘the diverse needs of the software ecosystem, there is no one-size-fits-all solution’ [15]. The problem with sharing and exchanging is that ‘To fully realize the benefits of SBOMs and software component transparency, machine processing and automation are necessary’ [15]. In Error! Reference source not found., we can see the hierarchy of automation in different formats (SPDX, CycloneDX, and SWID), specifications, and tools that are still under development.

2.3. Background to the Vulnerability Management Problems

SBOM enables us to identify potentially vulnerable components, but a vulnerability associated with a software component is not necessarily exploitable. The current CVE index has over 191633 vulnerabilities [16], with 32760 new vulnerabilities published in 2022, and around 22,000 published in 2021. Organisations cannot perform cybersecurity risk management for all known vulnerabilities, and risk management is based on their cyber risk tolerance, which is based on the likelihood and severity (frequency and magnitude) of the risk materialising. If a vulnerability is not assessed for exploitability, it is impossible to predict likelihood. Just one Windows vulnerability opened the door for WannaCry ransomware attacks via the EternalBlue exploit, while the Mirai botnet that spread through the exploitation of multiple vulnerabilities. From this, we can conclude that all vulnerabilities need to be risk assessed, and according to CVE, almost 11% of all vulnerabilities can be categorised as ‘critical’ [17] because they enable hackers to compromise apps and data of users of the same hardware. In early 2020, the first critical vulnerabilities in a major cloud infrastructure were discovered - disproving ‘the assumption that cloud infrastructures are secure’ [18]. Vulnerabilities also need to be risk assessed because around 75% of attacks in 2020 used vulnerabilities were at least two years old [19] and high-risk vulnerabilities are present on the network perimeters of 84% of companies [20].

2.4. What Is the Vulnerability Exploitability eXchange (VEX) and How Is It Different from SBOM and CVE

The examples above explain why each vulnerability needs to be assessed for exploits. From the volume of vulnerabilities in the CVE index, we can easily understand why the risk assessment process needs to be automated. From the most severe vulnerability of 2021, the Log4j, we can understand why vulnerabilities need to be assessed for exploits – while most cybersecurity professionals wasted vast amount of time risk assessing if Log4j was exploitable on their system, in many cases, it was not exploitable, and yet, it is extremely likely that a high number of Log4j vulnerable applications remain online [21]. To help prevent this in the future, the Vulnerability Exploitability eXchange (VEX)[22] was created in 2021. VEX’s providess the SBOM’s with transparency and an up-to-date view of the status of vulnerabilities. Software suppliers can issue a VEX to prevent non-exploitable vulnerabilities being investigated. VEX has been implemented as a profile in the Common Security Advisory Framework (CSAF) [23].

3. Survey of Secondary Data on Rethinking VEX and SBOM

Utilisation Problem

At present, SBOMs are used extensively by software developers, and given how useful SBOMs have been for them, developers are very keen on distributing the reports to end users (i.e., organisations where the primary business is not software development). The problem is that end users are not using SBOMs in any meaningful way, and when they get the reports, they don’t know what to do with them. Furthermore, without transparency, and without the end users requesting for SBOMs, it is quite possible that most of the software developers are not even using SBOMs to secure their software products. Without a reporting mechanism for the utilisation of SBOMs, we simply cannot know. However, from discussions with software developers on various meetings and conferences (e.g., with CSAF, NTIA, CISA), we know that developers have been very successful in using SBOMs, but that is not commonly known by end users. The motivation for this article, is not to determine the value of SBOMs in securing end users’ networks, that topic has been covered extensively in year 2021/22. Determining the value of SBOMs is not a primary or major obstacle at present. The motivation for this article is to determine what will persuade end users to start using SBOMs, and the key to this is to determine what is the real value in SBOMs for end users. One specific use case is the automated use of SBOMs for CVE (vulnerability) management. Although there are few tools designed to manage the software development process of vulnerability management, what is missing is ‘easy-to-use and low cost tools and third party services… passing vulnerability data to the vulnerability and configuration management tools that are now deployed by end users – is currently being addressed by nobody’ [26]. The most useful tool that could be found in open source at present (that ingests, analyses, monitors, and produces real-time intelligence reports from SBOMs and VEX documents), is the Dependency-Track [27].

4. Conclusions

Although CSAF has made some significant contributions towards the improvement of machine readable SBOM and VEX records, which is a crucial step in the automation process, NIST already has all 200k CVE descriptions available for download in JSON format (nvd.nist.gov). Without designing the second phase of the automation process, we struggle to see the rationale for CSAF. The CSAF Security Advisories (profile 4) are essential to helping consumers manage software risk using automation. The main difference between the CSAF and current mitigation strategies, is that the CSAF is machine-readable and allows for rapid and automatic mitigation.

The new version of CSAF released in December 2022 is more than just a JSON file readable in a machine format. The standard specifies how the new CSAF documents, and their distribution system can be discovered. The VEX profile in CSAF addresses the main problem that emerged with the introduction of SBOMs, it provides negative advisories that can be inform the customer that a specific product version they use and is listed in a SBOM, might not be affected at all by a certain vulnerability, because it might have been patched, resolved or simply the system is not affected.

The main benefit of CSAF is the ability to respond to false positives from security scanners. Although not well known in the European cybersecurity circles, the most recent CSAF standard version is stable and already in use by Cisco, Oracle, Arista, Siemens, Red Hat, BSI, and other organisations.

Areas for Further Research

The OASIS Standard is the language reference for the CSAF version 2.0 and is designed to automate the exchange of Security Advisories formulated in JSON. NFT is a JSON string. Future research should investigate if the security of product naming can be solved by naming software products as non-fungible tokens (NFTs). Generative AI will also provide many solutions to the product naming and different file formats problems. Generative Pre-Trained Transformers can be personalised and specialised to be specific for the VEX problems, and prevent the reports being disseminated for vulnerabilities that should have been patched yesterday, which seems to be the case with manual patching.