Keywords— Software Supply Chain Security, Open-Source Software Security, Vulnerability Management, Vulnerability Databases, Software Composition Analysis, Software Bill of Materials, Software Component Identification, Identity and Version Models, Vulnerability Intelligence.

1 Introduction↩︎

Free and open-source software underpins much of modern software. Applications often consist of numerous external libraries and frameworks distributed through independent package ecosystems and maintained by separate projects. This reuse shortens development cycles but also creates complex direct and transitive dependencies. A vulnerability in a single component can therefore propagate to many dependent applications [1], [2]. Studies of the npm, RubyGems, and Maven ecosystems have shown that transitive dependencies can substantially increase the exposure of software systems to known vulnerabilities [3], [4].

Identifying such vulnerabilities is a central task in vulnerability management for modern software supply chains. Software Composition Analysis (SCA) tools identify the components contained in a software artifact and compare them with publicly available vulnerability information. Comparative studies show, however, that different tools can produce substantially different results even for comparable analysis targets [5], [6]. The differences concern not only the number of reported vulnerabilities, but also component detection and mapping. Assessments of relevant version ranges and assignments to specific packages may likewise differ [7], [8]. Such discrepancies are often attributed to individual databases or tool implementations. In many cases, however, they arise earlier because the underlying information is created and repeatedly transformed within a distributed ecosystem.

From its initial discovery to its application in vulnerability management, vulnerability information passes through a series of organizational and technical processing stages. Throughout this process, it is coordinated, published, validated, and enriched by multiple information sources. It is also transferred between different identity models and interpreted within a specific application context. Available vulnerability knowledge therefore does not originate from a single source, but results from the interaction of independent actors and information systems. The literature examines many parts of this process. Existing work addresses inconsistencies in public vulnerability reports [9], the linking of heterogeneous information [10], and the construction of broad vulnerability datasets [11]. Further studies investigate the mapping of software components to vulnerability records [8] and the limitations of current SCA methods [12]. Less attention has been paid to how these parts interact within a common information flow and how that interaction produces divergent analysis results.

This paper examines the open-source vulnerability ecosystem as a connected information process. Its focus is not on individual databases or analysis tools, but on the creation, transformation, and interpretation of vulnerability information. Figure 1 outlines the processing stages discussed below. The flow begins with the discovery and reporting of a vulnerability. Once a Common Vulnerabilities and Exposures (CVE) identifier has been assigned, the published record is taken up by different information systems, enriched, and linked to further sources. Alongside this primary flow, secondary relationships connect package data, vendor and project advisories, and other public databases. Scanners and analysis tools combine these inputs in the local application context. The figure also shows that separate technical decisions are made at several transitions. These decisions can later produce divergent analysis results. The figure therefore serves both as an overview and as a reference point for the argument developed throughout the paper.

The remainder of the paper is organized as follows. Section 2 explains how vulnerability information is created, integrated, and interpreted. Section 3 examines the main causes of divergent analysis results, including heterogeneous information sources, different identity and version models, temporal change, and context-dependent assessment. Section 4 discusses the implications for research and practice. The final section summarizes the main findings.

2 The Open-Source Vulnerability Ecosystem↩︎

The processing steps shown in Figure 1 are discussed below along the flow of information. The process begins with the emergence of information about a vulnerability. This information is subsequently integrated into other information systems and interpreted in relation to a specific application context.

2.1 Origin of Vulnerability Information↩︎

The information flow begins with the discovery of a previously unknown vulnerability. Relevant reports may originate from security research, open-source projects, or operational practice. Following an initial report, the technical cause and possible consequences are examined. It must also be determined which products or versions are involved. Disclosure is often coordinated so that the responsible projects or vendors can develop appropriate countermeasures before publication [13]. Such processes are frequently supported by Product Security Incident Response Teams (PSIRTs). Their tasks range from receiving and assessing a report to coordinating remediation and publishing security advisories [14]. Examples include Siemens ProductCERT, which investigates vulnerability reports concerning Siemens products and publishes corresponding security advisories; the Microsoft Security Response Center (MSRC), which handles reports concerning Microsoft products and services and coordinates their disclosure; and the Red Hat Product Security Incident Response Team, which coordinates vulnerability and incident response management for the Red Hat portfolio [15]–[17]. Different assessments may already arise at this stage because technical information can initially be incomplete and several parties may be involved in its validation.

A confirmed vulnerability must be assigned an unambiguous reference for information to be exchanged across organizational boundaries. The CVE system provides globally unique identifiers for this purpose [18]. These identifiers are assigned and published by authorized CVE Numbering Authorities (CNAs), each of which is responsible for defined products, projects, or other areas of scope [19]. The Apache Software Foundation is one example. As a CNA, it records vulnerabilities in the projects under its responsibility and can assign the corresponding CVE identifiers.

A CVE record provides the common reference point for subsequent processing. It contains at least the information required for identification and publication, although it may include additional structured information depending on the responsible CNA. Typical elements include a description of the vulnerability, information about the relevant product and versions, and references to vendor advisories, patches, or further technical information [20]. Figure 2 illustrates these relationships using CVE-2021-44228 (Log4Shell) as an example. It also shows that a CVE record cannot be considered in isolation. Information supplied by the CNA is adopted by downstream information systems, supplemented, and prepared for different purposes.

The National Vulnerability Database (NVD) plays a central role in this subsequent enrichment by adding structured metadata to published CVE records [21]. This metadata includes ratings based on the Common Vulnerability Scoring System (CVSS) [22], mappings to the Common Weakness Enumeration (CWE) [23], and product and platform references based on the Common Platform Enumeration (CPE) [24]. A common CVE reference can therefore give rise to several interconnected and differently enriched representations. These representations form the basis for further processing of vulnerability information.

2.2 Integration and Transformation of Vulnerability Information↩︎

The information flow does not end with the publication of a CVE record. Other information systems adopt the available information, supplement it, and adapt it to their respective purposes. A concise vulnerability description is therefore transformed into several representations that provide different technical perspectives on the same issue. While the National Vulnerability Database mainly enriches a CVE record with standardized metadata and product references, other sources focus on published software packages, particular package ecosystems, or national coordination processes.

The Open Source Vulnerability Format (OSV) uses a package-oriented data model and describes affected versions within specific package ecosystems [25]. The GitHub Advisory Database provides comparable information for GitHub and supported package managers [26]. Regional information systems supplement this global body of knowledge through their own coordination, publication, and assessment processes. These include the European Vulnerability Database (EUVD) [27], Japan Vulnerability Notes (JVN) and JVN iPedia [28], as well as the Chinese databases China National Vulnerability Database (CNVD) [29] and China National Information Security Vulnerability Database (CNNVD) [30]. Vendor and project advisories remain important primary sources because they often provide precise information about affected versions, backports, workarounds, and available fixes [13], [31].

4pt

Table 1 summarizes the information sources considered, the identity models they use, and their respective contribution and technical focus. In the Identity column, identity denotes the mechanisms used by an information system to uniquely identify software entities and relate them to vulnerability information. The sources differ not only in the metadata they provide but also in the underlying identity models on which they are based. Further ambiguities arise from project renaming, forks, and distribution-specific variants. Backports make version information particularly difficult to interpret. Security fixes may be applied to older versions without fundamentally changing their original version designation [31]. The integration of vulnerability information is therefore not a simple copying process but a continuing transformation between different information and identity models. The following subsection discusses how this information is interpreted for a specific software artifact.

2.3 Interpretation of Vulnerability Information↩︎

Vulnerability information available in public information systems initially has no direct relation to a specific software system. A local analysis is required to connect it to the software components actually in use and place it within an application-specific context. This step marks the transition from generally available vulnerability knowledge to a concrete security assessment.

The software components contained in a software artifact must first be identified. Their names and versions are then normalized, mapped to suitable records in public information systems, and compared with the version ranges specified in those records. Figure 3 illustrates this process from the analysis of a software artifact to the generation of a local vulnerability finding.

The mapping cannot rely solely on a name or version number. Public information systems use different identity models to represent software and vulnerabilities. Product-oriented sources commonly rely on product identifiers, whereas package-oriented sources use package identities such as the Package URL (PURL) or ecosystem-specific package identifiers. Many records additionally reference alternative identifiers originating from vendor advisories (e.g., RHSA, DSA, USN), project-specific databases, or other public vulnerability repositories [25], [26], [31]–[33]. Together, these identities form a network of cross-references that supports the correlation of vulnerability information across heterogeneous sources [24], [25], [34]. Within a software artifact, software components may appear as binary files, software packages, container contents, or entries in a software bill of materials (SBOM). Their reliable mapping therefore requires additional information such as the package ecosystem, namespace, vendor, version, and the resolution of alias relationships between different identity models and advisory records [8], [10].

Once the mapping has been established, the available information must be assessed in relation to the application context, such as the actual use and reachability of a component and the criticality of the affected system. The resulting finding therefore combines public vulnerability information with locally determined component and context data. Section 3 examines the stages of this process at which differing analysis results may arise.

3 Causes of Divergent Analysis Results↩︎

The processing described in the previous section involves several transformation and decision steps. Differences between analysis results may already arise from the selection and current state of the information sources used. Further discrepancies can result from identity and version resolution or from the final assessment within a particular application context. The following subsections examine these causes in more detail.

3.1 Heterogeneous Information Sources↩︎

Although many publicly available information sources use the same vulnerability identifiers, they differ in purpose, scope, and the metadata they provide. These differences reflect the distinct roles that the sources perform within the open-source vulnerability ecosystem. Some adopt information from primary sources, while others supplement or reassess it. Differences between analysis results may therefore originate in the available knowledge base rather than in the analysis of the software system itself. Previous research has shown that public vulnerability information can vary in completeness, consistency, and structure [9].

The heterogeneity concerns both the content and the time at which information becomes available. Some information systems focus on standardized descriptions and assessments, whereas others provide detailed information about package versions, project-specific characteristics, or distribution-specific modifications. For CVE-2021-44228 (Log4Shell), for example, CVE and NVD provided a general description and assessment, while package databases and project advisories supplied more precise information about Maven versions, updates, and mitigation measures. Vendor and project advisories may also publish information about backports, workarounds, or recommended actions before these details have been fully incorporated into public databases. Regional systems add national or regulatory perspectives to the information available from global sources. Several internally consistent but differently detailed and time-dependent representations of the same vulnerability may therefore coexist.

For automated analyses, this means that identical software artifacts may produce different results solely because different information sources are used. The differences may concern not only the number of vulnerabilities identified but also the version ranges classified as vulnerable, additional references, or severity assessments. The integration of heterogeneous information therefore remains a central challenge for current vulnerability management systems and continues to be addressed in research [10], [11]. Even where the underlying information is identical, however, differences may arise from the identity and version models used for mapping software components.

3.2 Identity and Version Models↩︎

The mapping of vulnerability information to software components described in Section 2.3 may produce different results depending on the identity model used. Public information systems, package ecosystems, and software artifacts use their own namespaces, identifiers, and version conventions. No consistently unambiguous mapping exists between these representations. The same Log4j component may, for example, appear in a software artifact as log4j-core-2.14.1.jar, in the Maven ecosystem as org.apache.logging.log4j:log4j-core:2.14.1, and in a product-oriented database as the CPE name cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*. A correct analysis requires these representations to be recognized as referring to the same software component. If the connection is missing or a name is assigned to the wrong component, the resulting findings will differ.

Further difficulties arise from project renaming, forks, distribution-specific packages, and inconsistently maintained namespaces. Version schemes are also not always directly comparable. A numerically higher version number does not necessarily indicate a more recent security state when fixes have been backported to an older release [31]. A purely numerical comparison may therefore classify a maintained distribution version as vulnerable even though the relevant correction has already been applied.

Empirical studies indicate that the reliable mapping of vulnerability information to the software components actually in use remains one of the main challenges in automated vulnerability analysis. Incorrect or incomplete identity resolution can produce both false-positive and false-negative results and directly affects subsequent assessments. Current research therefore examines methods for identifying software components more precisely and linking them across package ecosystems and information models [6], [8]. Even where the mapping is correct, however, analysis results remain dependent on the time of analysis.

3.3 Temporal Dynamics↩︎

Vulnerability information is not static but develops throughout its lifecycle. After initial publication, descriptions may be extended, version ranges refined, references added, and assessments revised. A vulnerability analysis therefore represents the state of information at a particular point in time. Even when the same software components are examined, analyses performed at different times may produce different results [7], [21].

This dynamic also results from information systems maintaining and updating their data independently. New findings do not become available in all sources at the same time. Vendor and project advisories may appear before their contents have been fully incorporated into public databases, while downstream systems may add assessments, references, or version information only gradually. Temporary differences in the available information may therefore occur, and the same vulnerability may be described differently depending on the source and the time of analysis [9], [21].

Changes over time concern not only the description of a vulnerability but also its assessment. Further investigation may reveal additional information about relevant versions, practical exploitability, or available countermeasures. Such information may alter the priority assigned to a finding. Vulnerability management is therefore not a one-time analysis but requires the information base to be updated and reassessed continuously [7], [35]. Even when the information is current and consistent, the final result still depends on the application context.

3.4 Context-Dependent Interpretation↩︎

Even when identical vulnerability information is available at the same time and the software components have been mapped unambiguously, the results must still be assessed within the relevant application context. The risk associated with a vulnerability depends on the properties of the specific system, its operating environment, and the protective measures in place. The same vulnerability may therefore receive different priorities in different organizations or applications despite an identical information base [35].

The technical severity of a vulnerability can initially be expressed using the Common Vulnerability Scoring System (CVSS) [22]. CVSS assigns a severity score on a scale from 0.0 to 10.0, where higher values indicate a greater technical impact. For example, Log4Shell (CVE-2021-44228) received the maximum base score of 10.0 (Critical) because it enables unauthenticated remote code execution under common deployment conditions. This score, however, does not by itself determine the significance of the vulnerability for a specific software system.

Further information may therefore be included in a risk-oriented prioritization. The Known Exploited Vulnerabilities Catalog (KEV) identifies vulnerabilities for which active exploitation has been observed in practice [36]. A typical KEV entry contains the CVE identifier, the affected vendor and product, the date on which the vulnerability was added to the catalog, and a required remediation action. For example, the Log4Shell vulnerability (CVE-2021-44228) is listed in the KEV catalog together with the recommendation to apply the vendor-provided security update.

The Exploit Prediction Scoring System (EPSS) estimates the probability that a vulnerability will be exploited within the following 30 days by assigning a score between 0 and 1, where higher values indicate a greater likelihood of exploitation [37]. For example, a vulnerability with an EPSS score of 0.95 is considered substantially more likely to be exploited than one with a score of 0.02, even if both have the same CVSS severity.

The Vulnerability Exploitability eXchange (VEX) is a machine-readable format that allows software suppliers to communicate whether and under which conditions a known vulnerability affects a specific product [38]. A typical VEX statement references a vulnerability (e.g., CVE-2021-44228), the affected product, an exploitability status such as affected, not affected, or under investigation, and a corresponding justification. For example, a supplier may state that a product contains the vulnerable Log4j library but that the vulnerable code is not reachable in the delivered configuration. Such a statement allows organizations to distinguish between a vulnerable component that requires remediation and one that does not pose an exploitable risk in the given deployment.

A meaningful assessment also requires knowledge about the specific system that cannot be obtained from general vulnerability databases. Relevant information includes the actual use and reachability of a software component within an execution path, existing protective and compensating controls, the criticality of the supported business process, and internal security policies [2], [35]. Analysis tools differ in the information they consider and in the rules by which they derive a final assessment.

Figure 4 illustrates a possible decision process for the context-dependent treatment of a vulnerability finding. The process begins by verifying that the software component is present in the artifact. It then considers reachability and the availability of a fix or workaround. Depending on the result, the finding may be dismissed based on a VEX statement, mitigated through a technical measure, or accepted as a documented risk. Differences between analysis results therefore do not necessarily indicate incorrect data. They may reflect different technical assumptions, contextual information, or prioritization strategies. Empirical comparisons of current software composition analysis tools support this observation, as the tools may produce substantially different results even when they examine the same artifacts [5], [7].

3.5 Summary↩︎

The causes discussed in this section rarely occur in isolation. Heterogeneous information sources, different identity and version models, changes over time, and context-dependent interpretation influence one another and jointly determine the outcome of a vulnerability analysis. They give rise to technical challenges for vulnerability management systems as well as further questions for research and practice, which are discussed in the following section.

4 Implications for Research and Practice↩︎

The preceding sections have shown that divergent analysis results cannot be attributed to individual tools or databases alone. They arise from the interaction of several causes. Differences between results should therefore not be viewed solely as a quality problem of particular tools, but also as a consequence of a distributed information ecosystem whose contents continue to change.

This perspective has implications for both academic research and the practical use of automated vulnerability management systems. Research must address the integration, consistency, and comparability of heterogeneous vulnerability information. In practice, the main challenge lies in establishing reliable processes for handling distributed and changing vulnerability knowledge.

4.1 Implications for Research↩︎

The analysis of the open-source vulnerability ecosystem suggests that future research should examine the complete information flow rather than isolated data sources or analysis tools. Many comparative studies assess differences between tools on the basis of their output without systematically considering the information sources, identity models, and data versions underlying the respective results. Claims about the quality of a method are therefore only partly comparable [5], [7].

Reproducible evaluation methods remain another important research topic. Because vulnerability information is updated continuously, future studies should document the state of the information used, the time of analysis, and the underlying data sources. This documentation is necessary for meaningful comparisons and long-term reproducibility. Reliable reference datasets are equally important. Such datasets should combine different identity models, versions, and contextual information rather than relying exclusively on individual databases or CVE lists [7], [21].

AI-assisted methods may contribute to this work. Named-entity recognition and relation extraction can identify vendor, product, and version information in unstructured advisories and transfer it into common data models. Recent approaches combine these methods with unified identity schemas and graph-based models to resolve inconsistent names and configuration-dependent relationships [39]. Embedding methods and large language models may also help identify semantically related product names, connect aliases, and interpret heterogeneous descriptions [40]. Hybrid methods appear particularly suitable for this purpose, as they combine machine-generated mappings with formal identifiers, version rules, and traceable source references. Their evaluation should consider not only mapping accuracy but also interpretability, stability over time, and the provenance of the information used.

The ecosystem model presented in this paper also indicates that identity resolution and information integration remain open research problems. Consistent mappings between product-oriented and package-oriented identity models are still difficult to establish. The same applies to the inclusion of additional contextual information. Improvements in these areas could make differences between analysis results easier to explain and could increase the reliability of the resulting assessments.

4.2 Implications for Practice↩︎

A Software Bill of Materials (SBOM) is a formal record of the components contained in software and their relationships within the software supply chain [41]. In practice, the ecosystem model presented here means that vulnerability management should not be reduced to matching an SBOM against a single vulnerability database. Vulnerability information originates from different sources, changes over time, and must be interpreted within a particular application context. Analysis results therefore represent a technically justified view of the information available at a given time. Differences between tools or analysis dates are to be expected and should be taken into account when results are assessed.

Organizations should not adopt vulnerability information without examining its origin, currency, and technical interpretation. Documenting the information sources used, the time of analysis, and the software artifacts examined makes decisions easier to trace and repeated analyses easier to compare. Regular reassessment is also necessary because version mappings, technical assessments, and contextual information may change during the lifecycle of a vulnerability [7], [21], [35].

Technical vulnerability information alone does not provide a sufficient basis for sound prioritization. A risk-oriented assessment additionally requires the local context set out in Section 3.4, such as how a component is actually used, whether it is reachable, and how critical the supported business process is. Information from CVSS, KEV, EPSS, or VEX may support this process, but it cannot replace an application-specific assessment [22], [35]–[38]. Figure 4 shows the subsequent decision process, from validating a finding to its technical or organizational treatment.

The decisive factor is therefore not the selection of a single data source or analysis tool, but the ability to combine heterogeneous vulnerability information consistently, keep it current, and interpret it within the relevant application context. The ecosystem model developed in this paper provides a conceptual framework for this task. It also supports the interpretation of divergent analysis results as consequences of a distributed information and decision process.

5 Conclusion↩︎

Free and open-source software forms an essential part of modern software systems. As the number of public vulnerability information sources, package ecosystems, and analysis tools has grown, their evaluation has become more complex. Divergent analysis results should therefore not be regarded as exceptional, but as a structural property of a distributed vulnerability ecosystem that changes continuously.

This paper has described the open-source vulnerability ecosystem as a continuous information flow. The focus was not on individual databases or tools, but on the origin, integration, transformation, and context-dependent interpretation of vulnerability information. On this basis, heterogeneous information sources, differing identity and version models, changes over time, and context-dependent assessment were identified as major causes of divergent analysis results.

The findings show that differences between analysis tools do not necessarily indicate incorrect or incomplete findings. They may also result from differences in the available information, mapping rules, and technical assumptions. Assessments of automated analyses should therefore take into account the information sources used, the time of analysis, and the relevant application context.

Future research should improve the interoperability, traceability, and reproducibility of distributed vulnerability information. Reliable methods for identity resolution, consistent exchange models, and closer consideration of local context are particularly important. AI-assisted methods may contribute to this process by extracting information from unstructured advisories and linking semantically related product and package names. Their outputs, however, should be validated against formal identifiers and version rules to ensure reliable vulnerability matching [39], [40]. In practice, vulnerability management should not be reduced to matching software against a single data source, but treated as a continuous information and decision process.

Note on the Preparation of This Paper↩︎

Large language model tools were used to support individual editorial tasks and the preparation of the figures. The authors retain full responsibility for the content, the selection and verification of sources, the argumentation, and the final version of the paper.

6 List of Abbreviations↩︎

Table [tab:abbreviations] summarizes the abbreviations used frequently throughout this paper.

References↩︎