Why does a dependency update policy need both a scheduled sweep and advisory-driven upgrades?

## Two triggers, not two names for the same thing An update policy is mostly a question of what causes a version to change. There are two honest triggers and they behave differently enough that a policy naming only one is incomplete. **The scheduled sweep is time-driven.** On a fixed cadence -- weekly is the common choice for a service, less often for something with an expensive release path -- you take whatever upstream moved and see what your tests say. Nothing external prompts it. The unit of work is *everything that changed since last time*. **The advisory-driven upgrade is event-driven.** A disclosure lands describing a defect in a version range, that range includes something your build actually resolves, and that fact starts work now. The unit of work is *this package, to at least this version*. Nobody consulted you about the timing. ## What only the sweep can catch The strongest argument for a sweep is coverage of things that never announce themselves. - **Silent fixes.** A maintainer notices a bad input path, fixes it, ships a release with a one-line changelog. No identifier, no advisory, no alert anywhere. You get it by moving forward or you do not get it at all. A large share of upstream security work looks like this. - **Advisory lag.** Even where a disclosure eventually exists, it is written and published after the fix. The window between *fixed upstream* and *documented publicly* is time in which a sweep protects you and an event trigger has nothing to fire on. - **Transitive drift.** Your direct dependencies change what they depend on. A sweep re-resolves the graph and surfaces that movement; an advisory only fires on the specific package it names. - **Decay signals.** A package that has not shipped in two years, or a release that was yanked, is information about future risk. It shows up as *nothing moved* in a sweep and never as an event. ## What only the advisory trigger can do A sweep has a floor on its response time equal to its own period. If you sweep weekly and review takes two days, your worst case from *fix available* to *fix shipped* is a bit over nine days -- fine for routine currency, not fine for something with a working exploit. The event trigger exists to break that floor: it is allowed to interrupt, it is allowed to skip the batch, and it is the only path with an externally imposed deadline. Its defining property is that **you do not choose the timing**, which is exactly why it must be routed away from the routine queue rather than merged into it. A disclosure-driven bump that lands as item sixty-one behind cosmetic noise has had its whole reason for existing removed. ## Why either alone fails **Sweep-only** leaves the response-time floor above, and it treats an urgent item as ordinary work -- which, when the sweep is a single grouped change, also couples the urgent bump's schedule to the slowest thing in the batch. **Advisory-only** is the more common and more damaging failure. It is superficially attractive: you only do work someone can justify, so nothing is spent on churn. But it means every version in your estate is exactly as old as the last time someone warned you about it, which is usually very old. When the disclosure finally lands, the fixed version is several minors or a major ahead, its own dependencies have moved, and your tests have never run against any of it. You are performing a migration under a clock. Advisory-only also inherits every blind spot in the first list: everything fixed silently, everything not yet documented, everything that decayed rather than broke. The honest framing is that the sweep is what makes the advisory-driven path *fast*. Currency is not a separate goal from security -- it is the precondition for responding quickly. ## Setting the cadence Cadence follows the cost of a release, not a rule of thumb. A web service that deploys on merge can sweep weekly and absorb the churn. A mobile application whose dependency bumps each cost a store review cycle -- and whose users then update on their own schedule -- has a much more expensive unit of change, so a weekly sweep buys little and a monthly one with a tightly scoped set buys more. The asymmetry is worth stating explicitly in an interview: for anything that ships to a client you cannot redeploy, the *fix reaching the user* is the slow step, so a policy that shortens only the merge step is optimising the wrong end. What both paths share is that they end in evidence, not intention: a version actually resolved, a test suite actually run, a build actually deployed. A policy that says how often you will look but not what merges is only half written.