depproof: unmaintained flag doesn't change the remedy; only 3 of 933 findings lacked a fix version

One of these flags resolves to [email protected]. It arrives four levels down, chosen by nobody in the project, declared under build and test scope, with CVE-2023-28155 filed against it and no fix version published ^[6]. Its maintainers deprecated it formally, so this one is a declaration and not something the scan inferred ^[7]. depproof lists two options: replace whatever pulled it in, or write down that you accept it ^[8].

Most flags are not that clean. The scan asks three public sources what they know about every resolved component: deps.dev for release history and npm deprecation, OpenSSF Scorecard for project activity, endoflife.date for published support windows ^[9]. Those feed five rules applied in order, first match winning, so a maintainer's own declaration outranks anything the scan merely observed ^[10]. Rule 4 catches a component for being old and quiet, and it requires both halves, because release age by itself marks every finished library as abandoned ^[11]. Where Scorecard has no data the second half cannot be applied, and 82 of that rule's 960 components fell back to release age alone ^[12].

Rule 4 carries the bulk of the count: 960 of 1,202 is 79.9% ^[20]. The fallback cases are 82 of 1,202, or 6.8% of every flag in the sample ^[21]. That slice is the one most exposed to the objection depproof raises against itself, which is that a small single-purpose package can sit four years without a release because it is finished ^[4]. Their defence is that the signal answers a different question, whether a fix is coming if an advisory lands tomorrow, and that a finished library and an abandoned one answer it the same way ^[5].

Whether 13.4% describes your build depends on how deep your graph resolves. The npm figure comes from deep transitive trees in two large JavaScript projects, and the post says so in one line: "The mix here is ours, not yours" ^[13].

Findings concentrate more narrowly than components, at 57 of 933 ^[15]. Three findings in 933 is 0.32% ^[22]. depproof went looking for the acute case, a vulnerability in production with nowhere to upgrade to, and did not find it once ^[17]. "On this sample the maintenance signal is a statement about a project's future, not about today's remedy," the post says ^[18].

That matters because the escalation path assumes the opposite. Someone is paged, a patch window opens, teams stop what they were doing, and every step of it assumes a fixed version exists ^[24]. The standard advice to upgrade assumes a maintainer exists, noticed and shipped, and a normal findings report does not tell you which kind of package you are holding ^[25].

In my view the signal belongs in the component inventory you consult when picking a dependency, and in the accepted-risk register. On this sample the flag changed the available remedy three times out of 933 findings, and two of those three were build-and-test dependencies ^[16].