Does a dependency remediation clock start at advisory publication or at first scan detection?

## Why the start point is a real argument Everyone agrees the clock stops at remediation and that some deadline applies. Almost nobody writes down where it starts, and the choice moves the reported number more than the deadline itself does. Two candidate starts dominate. **Advisory publication.** The clock starts the moment the vulnerability became public knowledge. This measures *exposure*: the window during which anyone could have known your version was vulnerable and you were still running it. **First detection.** The clock starts when the finding first appeared in your own tooling. This measures *responsiveness*: how fast the owning team acted once told. ## What each choice makes invisible Detection-based clocks have one structural flaw, and it is severe: they charge nothing for the gap between disclosure and discovery. Every source of that gap is a real control failure that the metric now hides — an advisory database that lags, a scan cadence of once a week, a service that fell out of scanning coverage entirely, an artifact that is only scanned at build time and has not been rebuilt in five months. In each case the estate was exposed and the metric says the team responded in two days. The pathological version is a service that is never scanned at all: it can never breach a detection-based SLA, because its clock never starts. Publication-based clocks have a fairness flaw that is real but smaller: they charge teams for time in which they could not have acted. A team can be handed a finding that is already twenty-five days into a thirty-day window through no fault of its own. Handled naively this destroys the metric's credibility with engineers, who correctly point out that they are being scored on something outside their control. ## The resolution: split the metric by owner The fix is not to pick one and live with the distortion — it is to notice that the interval decomposes into two spans with two different owners: - **publication → first detection** is owned by whoever runs the scanning platform: coverage, cadence, and advisory-feed freshness; - **first detection → remediated** is owned by the team that owns the code. Drive the *deadline* from publication, because that is the number describing your actual risk and the number you would have to stand behind externally. Report the two spans separately, so a breach lands on the desk that can fix its cause. A program that only reports the second span will spend years with excellent numbers and a scanning estate quietly rotting. ## The cases that need a written rule **Late introduction.** A service adopts a version that was already publicly vulnerable, months after publication. Starting that occurrence's clock at publication is meaningless — there was no exposure before the dependency existed in the service. Start the occurrence clock at introduction. But note that adopting an already-vulnerable version is a distinct control failure, and the right treatment is to block it at intake rather than to log it as a fast remediation. **Range revision.** An advisory is updated to widen the affected range, so a version you already ship becomes affected weeks after original publication. The honest start is the revision date for the newly-affected versions, not the original publication. **Suppression.** A suppressed finding does not stop the clock. Hiding a finding changes nothing about the exposure, and a program in which suppression pauses the clock will report perfect compliance forever. Only remediation — or a formally recorded, dated decision that closes the item — stops it. **Business days.** Decide explicitly whether the clock runs on calendar or business days. For anything short this is the difference between a comfortable window and an impossible one, and leaving it ambiguous means each team resolves it in its own favour. ## Where the clock stops The stop point deserves the same rigour as the start. Merging the upgrade is not remediation; neither is closing the ticket. Exposure ends when the fixed version is *running* everywhere the vulnerable one ran — which includes the long-lived environments people forget, and any artifact still available for others to pull. Stopping at merge understates the exposure by exactly the length of your release train, which is a number the release train's owner would rather not publish. ## Defining it once The most damaging thing a program can do is change this definition quietly. Moving from detection-start to publication-start will, overnight, turn a quarter of your closed findings into historical breaches; moving the other way erases them. Both are legitimate changes to make, and both must be made in the open: publish the definition alongside the metric, version it, and when you re-baseline, show both numbers for a period. Otherwise the first person to compare two quarters' reports discovers that the improvement was a definition change, and the whole metric loses the credibility it exists to have.