A July 17, 2026 arXiv publication details the reasons why distinct vulnerability scanners analyzing identical software yield varying security issue lists [S1]. Researchers Peter Mandl (Munich University of Applied Sciences) and Paul Mandl (Findustrial GmbH) conclude that a broken scanner is not the root cause. The root issue lies within a decentralized information landscape where vulnerability data undergoes creation, modification, and analysis, allowing discrepancies to emerge at each transfer point [S1][P2].

The scanner problem nobody owns

Identifying known software flaws is a fundamental component of supply chain security [S1]. This process depends on standardized, publicly accessible vulnerability data [S1]. However, when multiple scanners evaluate the same software inventory, they frequently produce conflicting outcomes [S1].

The natural reaction is to fault the scanning tool. The Mandls contend that this is only a partial explanation. The discrepancies do not stem exclusively from specific data providers or tool designs [S1]. Instead, they surface throughout multiple phases of what the researchers term the open-source vulnerability ecosystem [S1].

A chain of handoffs

The proposed model characterizes vulnerability management as a decentralized sequence of data sharing and processing [S1]. Vulnerability information does not appear instantly in its final form. It progresses through phases: initial creation and standardization, followed by data enrichment, and finally context-specific analysis [S1]. Every phase represents a transfer point where data consistency can degrade.

The researchers highlight four primary drivers behind inconsistent scanner results [S1]:

  • Heterogeneous information sources. Various databases and feeds that frequently disagree on the definition of a vulnerability.
  • Divergent identity and version models. Conflicting methods for naming and versioning software, causing one scanner to miss a component that another detects.
  • Temporal change. Vulnerability data evolves as new details emerge, and scanners may capture data at different points in time.
  • Context-dependent assessment. The applicability of a vulnerability depends on the software's deployment environment, and scanners evaluate this context differently.

This work is a theoretical model rather than an empirical analysis [S1]. The publication lacks sample sizes, measured inconsistency rates, or controlled testing. It is an unreviewed preprint [S1]. Its contribution is a guide for locating the origins of a challenge that professionals face but find difficult to articulate.

What it means

If you operate vulnerability scanners and receive conflicting reports, the issue is not necessarily a tool malfunction. The model indicates that the vulnerability data itself traverses a series of modifications, any of which can create inconsistencies [S1].

Consider it similar to a game of telephone. A researcher uncovers a defect and submits a report. A standards organization assigns an identifier. A database adds affected version details. A scanner ingests the database and attempts to align it with your software inventory. Throughout this process, the data can be analyzed differently, updated asynchronously, or mapped to different naming conventions [S1].

Consequently, a scanner reporting fewer vulnerabilities is not necessarily more precise. It might be utilizing a different data snapshot, a different naming convention, or a stricter criteria for contextual applicability. The model provides security teams with terminology to comprehend why their tools conflict, instead of presuming one is correct [S1].

The publication also explores consequences for creating reproducible evaluation techniques [S1], which is crucial for anyone attempting to compare scanners. If the underlying data is inconsistent, comparing scanner outputs is akin to grading two students who took different tests.

What it means for business

A small development team might run a free vulnerability scanner on its dependencies, receive a clean report, and feel secure. A larger group using a commercial scanner on the same code might see numerous flagged issues. Both outcomes could be valid, and both could be flawed, because they rely on different versions of the same foundational knowledge [S1].

For smaller organizations, the key takeaway is to stop viewing scanner results as absolute truth. A clean scan does not guarantee the absence of vulnerabilities. It indicates that the scanner's data sources, naming conventions, and contextual evaluations did not identify any. Using a second scanner from a different vendor and comparing the results is standard practice. This publication clarifies why such comparisons frequently yield conflicting answers and why these conflicts are systemic rather than random [S1].

But this paper's framework suggests that adding more tools without understanding the information ecosystem underneath them may simply add more divergent results to the pile.

For compliance teams, the model poses a critical question: if scanner results are inherently inconsistent due to the way vulnerability data is generated and distributed, how can you establish a defensible standard for sufficient scanning? The publication does not resolve this, but it offers auditors and security managers a framework to explain why two scanners disagree, which is the initial step toward developing policies that accommodate this reality [S1].

What we don't know yet

The publication is a theoretical model lacking empirical evidence [S1]. It introduces no new scanning tools, software, or fixes. The assertions regarding scanner inconsistency and its origins are the authors' analysis, not independently verified results [S1].

Several questions remain unanswered:

  • How frequently do scanners actually diverge in practice, and to what extent? The publication provides no measured rates.
  • Which of the four identified causes contributes most to inconsistency? The model outlines all four but does not prioritize them.
  • Could a unified standard for identity and version models decrease divergence? The publication identifies the issue but offers no solution.
  • Has the model been validated against actual scanner outputs? No experimental validation is included.

The publication discusses implications for reproducible evaluation methods [S1], which suggests the authors view empirical research as a future step. Whether they or others pursue measured data will determine if this model becomes a practical resource for security teams or remains a theoretical guide.

Currently, the value lies in the terminology. If your scanners conflict, the explanation may not lie in the code. It may reside in the sequence of transfers that converted a vulnerability report into a scanner rule.

If this kind of plain-English decode is what you want from security research coverage, subscribe to keep reading.

Sources

More from Not A Tech Guy

Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.