Your platform wants to auto-close unreachable dependency findings across 400 services — what do you require first?

## Why the request is reasonable At four hundred services the queue is dominated by findings that will never be exposures, and a team that reviews all of them reviews none of them properly. Automating the obvious no-risk cases is genuinely the right direction; the judgment is in *what automation is allowed to conclude* and *for how long*. ## Close is the wrong verb Closing destroys the queue's memory. The safer construction is **deprioritize with an expiry**: the finding stays in the inventory, drops out of anyone's working set, and is re-decided automatically on the next build of that artifact. Two properties follow. First, the decision is never older than the code it describes. Second, if the automation is later found to be wrong about a class of cases, you can re-open that class, which you cannot do once the records are gone. ## Key the decision to what it actually depends on The single most damaging design error here is keying a suppression on *(advisory id, package name)*. That key survives everything: a refactor that introduces a call to the vulnerable function, a version bump, a component moving from a local toolchain into the shipped runtime path, a service acquiring a new entry point. The note keeps suppressing while the fact it recorded stops being true, and nobody re-reads it because it is no longer in anyone's queue. Bind it instead to everything the claim rests on: the package identity and resolved version, the artifact or commit digest analysed, the analyser and its entry-point set, and a timestamp. Any change to those invalidates the suppression by construction, which turns a stale-note problem into a re-analysis problem — a much better problem to have. ## What each record must retain A year from now someone — an auditor, a customer's security reviewer, an engineer during an incident — will read one of these decisions cold. It has to answer, on its own: which artifact and version it applies to; who or what decided, and when; the evidence, meaning the static verdict together with the entry points modelled and any runtime observation with the window it covered; the stated condition that would flip it; and the expiry. A row that says only "unreachable" is unauditable and, in a conversation with a customer about why a shipped artifact contains a known-vulnerable component, indefensible. ## Carve-outs, decided in advance Automation should refuse to act where being wrong is expensive: - **Exposure.** Internet-facing and multi-tenant services, where the attacker position is cheap to occupy and the asset is somebody else's data. - **Language and stack.** Dynamic imports, reflection-driven wiring and plugin architectures make static unreachability least trustworthy; the tool's error rate is not uniform across the estate, and the policy should not pretend it is. - **Active exploitation.** Anything the industry is currently seeing used goes to a human regardless of the verdict. - **Thin evidence.** A verdict with no runtime corroboration in a stack where corroboration is available is not the same input as one with it. ## Ownership and appeal The platform team owns the mechanism; the service owner still owns the risk. That split has to be explicit, or the first wrong suppression becomes an argument about whose fault it was during an incident. Give service owners the ability to opt a repository out, give security an override, and publish what the automation did per service so the decision is visible rather than silent. ## Measure the right thing The tempting metric — findings suppressed — rewards exactly the failure mode you fear. Measure instead the **false-suppression rate**: sample a percentage of auto-deprioritized findings each month, review them by hand, and publish how many were wrong. That number is what tells you whether to widen the automation, tighten the carve-outs, or stop. Pair it with time-to-remediate on the findings that *did* stay in the queue, since the whole justification for the programme is that attention moved to them. ## The answer an interviewer is listening for Not "no". A principal who blocks the automation has not solved the scale problem. What distinguishes the answer is treating the verdict as a perishable, attributable claim rather than a permanent fact, and building the mechanism so that its own errors are detectable and reversible.