Why does transitive depth dominate a dependency scanner's finding count?

### The counting unit is the resolved graph A scanner does not read your manifest and stop. It matches advisories against the **resolved** set of components - everything the resolution actually produced. Your manifest is the seed; the closure is the inventory. This is why the two numbers people quote about a project are almost never the same number: 'we have twelve dependencies' describes a file, and 'we have four hundred components' describes what was installed. The compounding is mechanical. Each direct dependency brings its own direct dependencies, which bring theirs. Even modest fan-out compounds quickly over a few levels, and the deeper levels contain far more distinct packages than the top one. So the *population* of the queue is dominated by depth, purely by arithmetic. A useful worked shape: a Go module log-shipper distributed as a CLI that customers install on their own servers, with two direct imports and roughly four hundred modules in the resolved graph. Nearly the whole scanner queue for that binary is packages the authors never typed. ### Rows are not components Before drawing any conclusion from a queue size, deduplicate. The same vulnerable package reached by six different paths is one component to upgrade, not six findings, and one package with four advisories is one upgrade too. Teams that report raw rows get numbers that swing wildly for reasons that have nothing to do with risk - a new service onboarded, a scanner changing how it enumerates paths - and lose the ability to say whether things are getting better. Report: - distinct affected components, - distinct advisories, - how many are in the deployed artifact versus build or test only, - age of the oldest unresolved one. ### Depth does not mean safe, and it does not mean dangerous The common wrong instinct is to sort by depth and treat level four as background noise. Depth is a statement about how the package entered your project, not about what it does. A deep package can be the exact library parsing untrusted input on the request path, because a thin wrapper you depend on may be delegating all of the real work downward. Equally, depth does not make something scarier. Severity comes from the flaw, presence comes from scope, and reachability comes from what executes; depth contributes to none of the three. ### The resolved graph can also over-state what ships The graph is a superset of what runs, and by different amounts in different ecosystems. In Go, the module graph includes modules needed to build the tests of packages you import, while the linker includes only packages actually imported transitively by the binary you built. A module can appear in the requirements and contribute nothing to the shipped binary. Scanning at module granularity therefore over-reports for a compiled binary, and analysis of the built artifact itself gives a tighter answer. In interpreted ecosystems, the opposite exposure applies: what is installed on disk is present and loadable whether you import it or not. ### Depth changes who has to act This is the practically important consequence and the one interviewers push on. You do not usually own a package four levels down. The clean fix is that the intermediate maintainer releases a version depending on the fixed one and you take the parent bump. That is out of your control, so: - Time-to-fix becomes a distribution. Some findings close in an hour with a parent bump; some sit until an upstream release exists; a few require your ecosystem's override mechanism, which is a resolver decision with its own trade-offs. - The right metric is not 'time from advisory to zero findings' but something you actually control, such as time from advisory to a decision recorded on each affected service. - Batching matters. Bumping one parent frequently closes several deep findings at once, so scheduling by parent rather than by finding is what shrinks the queue. ### What to say in an interview Get the sequence right: the count is a property of the resolved graph; deduplicate to components; separate what is in the deployed artifact from what is build- or test-only; then rank what remains by severity, exposure and what the affected code actually does. Depth is a fact about the shape of the graph, and it belongs in your capacity planning, not in your risk ranking.