Renovate keeps every dependency current — does that replace a vulnerability scanner?

## Detector versus actuator The cleanest framing for this whole question is a control-loop one. A **detector** builds an inventory of what you have and matches it against advisory data to tell you what is exposed. An **actuator** changes the system. An update bot such as Renovate is squarely an actuator: it watches registries for newer releases, and where it can parse and rewrite a manifest, it opens a pull request. Some bots additionally consume advisory data to prioritise, but the output is still the same — a proposed version change. A team that has automated the actuator and skipped the detector has automated the *cheap* half. Remediation being easy is genuinely valuable — it is often the difference between patching in a day and patching in a quarter — but it does not tell anyone what is wrong. ## The four gaps to name **No newer version, no signal.** If a maintainer has published no fixed release, there is nothing for the bot to propose, so it stays quiet. That silence is indistinguishable from "nothing to do", and it covers precisely the hardest cases: abandoned packages, end-of-life majors, and advisories published faster than fixes. A detector reports the advisory whether or not a fix exists; a bot cannot. **Latest is not patched.** A package can sit at its newest published version and still be subject to an open advisory. "Current" is a statement about the registry's release list; "not vulnerable" is a statement about advisory data. Conflating the two is the single most common wrong answer here. **Only what a manifest expresses.** The bot works where it can read and rewrite a declaration. That leaves out vendored source trees, files copied in by a build step, artefacts with no manifest at all, and — importantly — the OS packages installed inside a base image. A bot may bump the base image's tag, which is a manifest edit; it does not tell you which system packages inside that image carry advisories. **Proposed is not deployed.** The bot's state is a queue of pull requests. What is deployed is a different question with a different answer, and only an inventory of artifacts or running workloads settles it. A team reporting dependency risk from the bot's dashboard is reporting intent. ## Where the two meet The useful arrangement is a loop, not a choice: | Role | What it answers | | --- | --- | | Detector — inventory-based scan of manifests and artifacts | What do I have, and what of it is subject to a known advisory? | | Actuator — update bot | Here is a change that would move a component to a newer version. | The detector defines the work; the bot makes most of that work nearly free. When they disagree — the detector reports an advisory the bot cannot act on — that is not a tooling bug, it is the loop working: you have found a case that needs a human decision, which is usually one of removing the dependency, mitigating around it, or accepting the risk with an expiry. ## Why interviewers ask this Because the failure is organisational rather than technical, and it is common. A team wires up a bot, the pull requests flow, the dashboards look busy, and "dependency vulnerability management" gets ticked off. Then someone asks which services are exposed to a specific advisory published this morning, and there is no answer, because nobody ever built an inventory. The bot could never have answered that question — not because it is configured badly, but because it is not that kind of tool. ## How to answer Give the one-line distinction — detector versus actuator, current versus not-vulnerable — then the concrete gap you would worry about most, which is the silent case where no fix exists. Finish with the arrangement: keep the bot, because cheap remediation is what makes a detector's output actionable, and add an inventory-based scan of what you build and what you run so the programme has a source of truth that does not depend on somebody else publishing a release.