skip to content

Dependency scanning can run in the editor, a pull request, the registry or at runtime — what does each placement buy?

level: middleimportance: should knowfreq 55%

answer

  1. Different artefact exists at each point
  2. Attribution early, artifact truth later
  3. A digest can be re-scanned; a branch cannot
  4. Runtime shows what nobody rebuilt
  5. Dedup on purl, not on finding id

basics

~20 s

Each placement trades speed against truth. Editor and pull-request scans read what you declare and give feedback before a change lands. Registry and runtime scans read the built artifact and what is deployed, which is the inventory that matches production.

solid answer

~50 s

Editor-time SCA hints as you add a dependency: fastest feedback, weakest authority, easy to ignore. A pull-request scan reads the manifests and lockfiles the change resolved, so it can say exactly what the diff introduced — the right place to catch a new vulnerable dependency before review ends. A registry-side scan runs against the pushed artifact by digest, so for the first time you are assessing the thing that will actually be deployed rather than the source that produced it. A runtime scan inventories what is currently running, the only view that reflects age: an image untouched for months accumulates new advisories with nobody changing a line. The catch is that one vulnerable package surfaces at three or four of these points, so you need a shared identity — a purl for language packages, distribution package identity for OS ones — or the same finding gets triaged repeatedly.

go deeper

for a junior

Be ready to say that scans can run before the build and after it, and that the earlier ones read your declared dependencies while the later ones read the artifact that was produced.

for a middle

Explain what artefact exists at each point and what can therefore be inventoried there, and why an immutable digest is a better subject for a finding than a branch or a tag.

for a senior

Demonstrate the deduplication problem and your answer to it: one package identity, one triage decision, carried across every placement instead of re-argued at each.

for a principal

Own the placement portfolio for an estate — what you pay for at each point, which placements you can drop, and how you keep an honest statement of coverage when part of the build is outside your control.

## Placement is a coverage decision, not a preference The same class of tool produces very different value depending on where in the lifecycle you run it, because at each point a different thing exists to be inventoried. Reasoning about placement well means being able to say, for each point: *what artefact exists here, what can be read from it, and what can be done about a finding at this moment?* ## Editor time An SCA hint in the editor fires as a developer adds or bumps a dependency. What exists here is a manifest edit, often before resolution. The value is cost: the cheapest possible moment to pick a different library. The limits are real — it is advisory, it covers only the ecosystem the plugin understands, and there is no enforcement point. Treat it as a convenience, never as a control you can claim. ## Pull request Here a full resolution exists: the change's lockfiles can be resolved and diffed against the base branch. A tool like OSV-Scanner run over the resolved lockfiles reports the application dependency graph precisely, including transitives the author never named. The distinctive value is *attribution* — you can say "this pull request introduces it", which is what makes a finding actionable rather than ambient. This is also where the signal is scoped: dev-only dependencies are identifiable and can be ranked lower. What is missing at this point: everything about the artifact. There is no image yet, no base layer, no compiled binary. ## Registry, on push Once a build has produced an artifact and pushed it, an image scanner such as Trivy or Grype can inventory the real thing: the OS package database in the layers, plus recognisable language artefacts on disk. Crucially, the subject is now a **digest** — immutable content — so a finding attaches to a specific artifact rather than to a moving branch. This is the first point at which you are assessing what will actually run. Registry-side scanning has a second property that CI-time scanning does not: it can be re-run later against the same unchanged digest. Advisory data changes; the artifact does not. Re-scanning an old digest is how you learn that something you shipped two months ago is now known-vulnerable. ## Runtime A runtime scan inventories what is deployed right now. Its unique contribution is **reality**: it covers images nobody rebuilt, workloads deployed from a registry you forgot about, and the difference between what the pipeline produced and what the cluster is running. It is also the worst place to find a problem, because remediation from here is a deployment, not a code review. ## The same finding, several times A vulnerable library that entered via a pull request will be reported by the pull-request scan, by the registry scan of the image built from it, and by the runtime scan of the workload running that image. That is not three problems. The practical requirement is a shared identity to deduplicate on: | Component kind | Identity to key on | | --- | --- | | Language package | a purl, e.g. `pkg:npm/[email protected]` | | OS package | distribution package name plus version, as the distro's advisory feed names it | | Artifact | the image digest, not the tag | Deduplicating on a scanner's own finding identifier fails, because those differ per tool and often per run. Keying on package identity also lets one triage decision — accepted, not applicable, scheduled — follow the package across every placement instead of being re-argued at each one. ## What to say when asked to choose Don't rank the placements; map them. Pull-request scanning gives attribution and prevents new debt. Registry scanning gives artifact truth and re-scannability. Runtime scanning gives the honest picture of the estate, including what nobody has touched. Editor hints are goodwill. If forced to pick two, most teams get the most from pull-request plus registry, with a periodic re-scan of deployed digests standing in for continuous runtime coverage.

  • The same package is flagged in the pull request, the registry and at runtime. How do you avoid triaging it three times?
    Key the finding on package identity — a purl for language packages, the distribution's package name and version for OS ones — and attach the triage decision to that identity rather than to a scanner-issued finding id, which varies by tool and run. Then one "not applicable" or "accepted until date" decision travels with the package everywhere it appears.
  • Your builds run on a managed platform you cannot instrument. Where do you scan?
    On both sides of the box you do not control: the repository before the build, and the registry or runtime after it. Accept the honest limit — the repository scan describes source, the registry scan describes an artifact, and nothing you ran proves one produced the other, so bind decisions to the pushed digest rather than to the branch.
  • Why is re-scanning an unchanged image digest worth doing?
    Because the artifact is fixed but advisory data is not. A digest that scanned clean at push can be known-vulnerable weeks later with no change on your side. Periodic re-scans of deployed digests are how that becomes visible without waiting for the next build.

saying these in an interview costs you the question

  • Thinks a green pull-request scan means the deployed image is clean
  • Believes editor-time hints count as an enforced control
  • Cannot say what a registry scan sees that a manifest scan cannot
  • Deduplicates on the scanner's finding id rather than package identity
  • Assumes findings only change when the code changes

context

resolving links…