Two dependency scanners report 61 and 9 findings for one JVM service - how do you adjudicate?

A finding count is not a measurement of a service. It is the output of three things: the dependency set that was scanned, the advisory data the tool was reading, and the matching rules it applied. Two numbers as far apart as 61 and 9 almost always come from the second and third, and the way to settle it is a diff, not an argument about which tool is better. ## Step one: equalise the inputs Before comparing outputs, confirm both tools answered the same question. Did both resolve the same dependency set, from the same lockfile state, on the same artifact? A tool reading a build manifest and a tool reading a built artifact will legitimately see different component lists. If the inputs differ, stop - the finding gap is explained by the input gap and the rest of the analysis is noise. ## Step two: normalise and diff Export both result sets. For every row, produce a key: the alias-normalised flaw identifier, plus the package coordinate and the resolved version. Alias normalisation matters because one flaw commonly appears under a central identifier and an ecosystem one, and a tool that reports both without collapsing them doubles its own count. Now diff the two keyed sets. What you want is not a number but a classified list of differences. ## Step three: classify every delta **Feed coverage.** One tool is reading an ecosystem-native database and the other an enriched central one. The ecosystem database often has the package-level record days before central enrichment produces structured applicability data, and it may carry advisories that never got a central identifier at all. Conversely a central record may exist for a component the ecosystem feed does not cover. This bucket is usually the largest one. **Advisory granularity.** The same flaw can be filed at very different resolutions. One database records that a specific module of a large project is affected in a narrow range; another files the same flaw against the whole project, so every artifact published under it matches. If the coarse record touches fifty artifacts in your graph, one flaw becomes fifty rows. Neither database is lying - one is more precise. Note the granularity difference explicitly, because it will recur every release. **Duplicate identifiers.** Beyond aliases, databases sometimes carry two records for one flaw that were never linked, or a record that has since been retracted as a duplicate. These inflate one side only. **Range interpretation.** Ranges are evaluated against a version scheme, and the edges are where tools disagree: pre-release and build-metadata suffixes, an unbounded introduced event with no fixed version yet, or a version string that does not sort the way the range author assumed. Two tools evaluating the same range can land on different sides of the boundary for the same installed version. **Data freshness.** A local advisory database that has not been refreshed produces both false negatives, for advisories published since, and stale positives, for records corrected or retracted since. Always check when each side last updated, before you conclude anything about matching logic. ## Step four: adjudicate and record Once every delta is classified, the decision is straightforward and is about sources, not tools: which database is authoritative for each ecosystem you build in, and which is a secondary safety net. Write it down with the reasoning, because this argument recurs every time a tool is added or a feed changes. Then present the release meeting a normalised union - the deduplicated flaw list with a disposition per item - rather than either vendor's headline number. A count without a source and a normalisation rule attached is not evidence of anything. ## The trap The instinctive read is that 61 is the thorough tool and 9 is the one missing things, so pick 61 and feel safe. Frequently the reverse is closer to the truth: the larger number is one flaw multiplied by a coarse range, plus alias duplicates, plus rows for components that are not in the shipped artifact at all. Meanwhile the smaller list may contain a real finding the larger one missed entirely, because its feed does not cover that ecosystem. Volume is not coverage. The only defensible position is the classified diff, and the only durable fix is to fix the source configuration so the gap does not reopen next quarter.