Enhancing Software Vulnerability Management with Visualization Data

2.1 Structure of visualization data and its application in vulnerability management

Visualization data refer to data that visualize the structure of software products or systems. As shown in Fig. 1, visualization data encompass a wide range of information, including configuration information (software and hardware components), risk information (such as vulnerability data), and status information (such as actual usage patterns) [3].

Fig. 1. Composition of visualization data [3].

This section focuses on the use of two specific formats: a software bill of materials (SBOM), which represents configuration information, and Vulnerability Exploitability eXchange (VEX), which handles vulnerability information, to demonstrate how visualization data can be applied in vulnerability management.

An SBOM is a list of components and their associated information included in a software product. The National Telecommunications and Information Administration (NTIA) defines the minimum elements of an SBOM as supplier name, component name, version of the component, dependency relationship, author of SBOM data, timestamp, and other unique identifiers within the categories of Data Fields, which should be considered by organizations implementing SBOMs, as well as automation support and practices and processes [4, 5].

VEX is a machine-readable security advisory used to provide information to user organizations from software vendors and other stakeholders about whether a software product is affected by known vulnerabilities. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) outlines the minimum requirements for information that should be included in a VEX document [6], and in Japan, discussions are underway on using VEX for vulnerability management.

As mentioned earlier, four key actions in vulnerability management were introduced. Among these, the use of visualization data in particular is expected to contribute to the actions of investigating the presence of security issues and considering the impact of vulnerabilities and direction of countermeasures.

The “Guide of Introduction of Software Bill of Materials (SBOM) for Software Management Ver.2.0 (Draft)” published by the Ministry of Economy, Trade, and Industry (METI) introduces processes such as vulnerability identification, vulnerability response prioritization, information sharing, and vulnerability response [5]. In this context, vulnerability identification refers to the process of identifying vulnerabilities within the software, vulnerability response prioritization involves evaluating vulnerabilities and determining the priority of responses, information sharing refers to sharing vulnerability information both inside and outside the organization, and vulnerability response involves taking some form of action to mitigate the identified vulnerabilities.

2.2 Investigation and analysis of vulnerability impact based on visualization data

When using visualization data in vulnerability management, there are two main perspectives: conducting investigation and analysis of vulnerability impact based on visualization data and using visualization data to understand vulnerability information. The former involves the users of the visualization data using elements such as software component information to carry out the vulnerability identification process. The latter refers to users leveraging the vulnerability information embedded within the visualization data to gather the necessary information for the vulnerability response prioritization process. When applying visualization data, it is effective to first determine which use case is more suitable for the organization then explore the appropriate method of utilization. The relationship between these perspectives is illustrated in Table 1.

Table 1. Examples of vulnerability management actions and processes with visualization data.

In the following sections, how the elements of visualization data can be applied in each case is introduced.

First, let us discuss the use case of conducting investigation and analysis of vulnerability impact based on visualization data. In the vulnerability identification process, the goal is to collect information on the names of software affected by vulnerabilities and the specific versions that are vulnerable then investigate whether these software versions are used within the organization. When using visualization data to identify vulnerabilities, one can cross-reference the collected vulnerability information with software component information, such as an SBOM, which is one of the elements of visualization data.

In practice, when security operators within an organization perform this task, it is effective to establish a system that automatically cross-references the vulnerability information with the information listed in the SBOM by consulting services that provide vulnerability information, vulnerability databases, and various software vendor websites.

Figure 2 illustrates an example of the sequence of software vulnerability management steps when conducting investigation and analysis of vulnerability impact based on visualization data involving both security operators and system administrators.

Fig. 2. Software vulnerability management when conducting investigation and analysis of vulnerability impact based on visualization data.

Steps (1) to (4) correspond to the vulnerability identification process, step (5) corresponds to information sharing, and step (6) corresponds to the vulnerability response process. If a large number of vulnerabilities are detected in step (3), it may be necessary to establish priority indicators for responses in step (4) to execute vulnerability response prioritization and limit the scope of step (5) accordingly. Another important consideration when using visualization data is to recognize that after step (6) is executed, the software component information collected in step (1) may need to be updated. An example of a vulnerability response could involve changing the version of a software component. In such a case, if the version information in the component data collected in step (1) differs from the version information after step (6), future vulnerability responses might not be handled appropriately. Therefore, it is crucial to continue updating the component information as software configurations change, even after the initial collection and aggregation of data.

The expected benefits of this approach include reducing the labor required for vulnerability identification by the security operator/system administrator and mitigating the residual risk of vulnerabilities. In a proof-of-concept conducted by METI, it was reported that using SBOMs for vulnerability management reduced management labor by approximately 70% compared with traditional manual management methods [7].

2.3 Understanding vulnerability information using visualization data

Next, let us examine using visualization data to understand vulnerability information, as illustrated in Fig. 3. When applying visualization data to this scenario, it is expected to contribute significantly to the vulnerability response prioritization process.

Fig. 3. Using vulnerability information as visualization data.

In this process, vulnerability information is used in conjunction with system security settings and the security controls of access control devices. Software vulnerabilities often become a threat only when specific conditions are met. Information that confirms these conditions (such as settings or designs) needs to be verified by system administrators or users, while security operators must accurately convey the vulnerability information. There are also cases in which a software product may not be affected even if a vulnerability is found. In such cases, the software vendor must disclose this information, and users need to understand and respond appropriately. In Log4Shell (CVE-2021-44228), for example, even after the Log4j vulnerability was disclosed, it was necessary to determine whether the software products in use were affected. In such situations, there is a need for a system that uses visualization data to distribute impact information specific to each software product.

Specifically, product vendors would investigate the configuration of software components included in their software products and assess the impact of any vulnerabilities within those components on the overall software product. The results of this investigation would then be published as visualization data. This enables users to determine the impact without needing to directly consult the product vendor. Without the use of visualization data, however, software users would need to confirm with the product vendor whether a vulnerable software component is included in the product and, if so, whether it poses any impact.

With the increasing adoption of open source software (OSS), the number of OSS components used in a single software product is also on the rise. When managing vulnerabilities using visualization data, there is a concern that the more software components are used, the greater the number of detected vulnerabilities. In this context, when conducting investigation and analysis of vulnerability impact based on visualization data, verifying whether each software component’s vulnerability in the software product actually requires action could be extremely time-consuming. Therefore, it is considered effective to use visualization data to share information on whether action is needed for software component vulnerabilities for each product, enabling more efficient vulnerability management.

2.4 Exchanging visualization data elements between companies

Managing software vulnerabilities using visualization data involves combining various types of information. Visualization data represent a subset of the information necessary for software vulnerability management, and security operators may need to gather additional information beyond the visualization data when required. In the collection of visualization data, there are elements that are exchanged between organizations and elements that are collected within an organization for use in vulnerability management.

Among the visualization data used for vulnerability response prioritization, information such as the security settings of the system on which the software operates or security control information from access control devices such as firewalls should not be shared externally to prevent leakage of sensitive information to attackers. Therefore, it is preferable to collect and use these data within the organization that uses the visualization data, rather than exchanging them between contracting organizations (companies).

Among the visualization data used for vulnerability response prioritization, vulnerability information investigated by the software product vendor is necessary for the organization using the software to conduct its own impact assessment. Therefore, this information should be disclosed externally in an appropriate manner. VEX falls under this category. One example under consideration is for software vendors to provide VEX information to a vulnerability database, enabling users to access the information through the database [8].

Among the visualization data used for vulnerability identification, information such as SBOMs should be exchanged between companies to confirm responsibility for vulnerability management within the supply chain. However, issues such as the increased workload for the vendor in verifying vulnerabilities and contractual models that arise from delivering or publishing SBOMs are still under discussion, and no unified policy has been established yet. Therefore, depending on the contracts and development models with suppliers, the first step toward efficient software vulnerability management is to establish a system within the organization that uses visualization data.