Remediation & Upkeep

Mitigating in place removes the attack path without changing the dependency version: disable the vulnerable feature by config, or block the network route that reaches it. Use it when the patch will take longer than the exposure is tolerable.

Four options: delete the dependency, replace it with a maintained equivalent, patch it yourself and own that patch forever, or contain it behind a control that blocks the vulnerable path. Deletion is often cheapest and rarely even costed.

They build different inventories. An image scanner lists what it can find inside a built image, mostly OS packages installed by the distro. Manifest and lockfile SCA reads the dependency graph your build resolved. Each misses what the other finds.

An unread update queue means known fixes sit unapplied, and the one bump carrying a security fix looks exactly like the 59 routine ones. It also grows upgrade distance, so the next urgent patch becomes a large, risky jump.

Order by exposure, not by score. Services that are internet-reachable and feed attacker-controlled input into the vulnerable code path go first, then internally reachable ones, then batch and build-only workloads. The score is identical across all 180, so it cannot rank them.

Only evidence that actually exercises the changed dependency. A green build proves the covered paths still work and nothing about the rest, so the unattended-merge rule must stay narrow enough that your tests cover the risk it takes.

Upgrading the intermediate library. An exclusion is written against a specific coordinate on a specific path, so when that library changes how it pulls the package, the exclusion stops matching, the vulnerable version returns, and nothing in the build fails.

You become that package's maintainer. You own review of a patch nobody upstream will check, every future flaw in the same code with no advisory to warn you, and the gap between what your build actually ships and what your inventory claims it ships.

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.

They have different triggers and catch different things. A scheduled sweep is time-driven and keeps you close to upstream, including fixes that never get an advisory. An advisory-driven upgrade is event-driven, jumps the queue, and runs on somebody else's clock.

Run two tracks. Land a local override now, scoped and tested, with an owner and a removal trigger tied to the upstream change. In parallel push the pull request itself: minimal diff, tests, the advisory cited, escalated through the project's security contact rather than a public thread.

Freezing stops other changes so the fix is the only thing moving; pinning holds the dependency at an exact known-good version so a rebuild cannot drift; rolling forward ships the fix through the normal train. Choose by exposure and by how much unrelated change the fix drags along.

Cut the attack path and the blast radius: pre-filter or transcode documents before the parser sees them, run it unprivileged, network-denied and resource-capped one document at a time, alert on crashes, and give the control an owner and a review date.

No. An update bot is a remediation channel, not a detector: it proposes version changes where a newer version exists and it can rewrite a manifest. Up-to-date and not-vulnerable are overlapping sets, not the same set.

A merged pull request and a closed ticket prove intent, not state. Proof is a chain: the fixed version inside a built artifact, that artifact identified by digest, that digest running in every environment, and a re-scan of the running inventory returning no matches.

No. A manifest-based scanner found nothing because no lockfile ships beside the binary. The result describes the scanner's input, not the artifact. Go binaries embed their module list, so an artifact-level scan still enumerates them.

You lose the one-to-one mapping between a symptom and a single change. Bisecting now happens inside the batch rather than across history, and reverting is all-or-nothing, so undoing one bad member also undoes nineteen good ones and reopens their exposure.

Establish real exposure first, then treat it as a decision that leaves engineering: isolate or move the workload if the exposure is real, otherwise accept the risk formally with a named owner, a written justification, an expiry and a review trigger — and press the vendor through the contract.

Split the problem. Replace the component in the next release so new installs are clean. Then decide separately what you owe the machines you cannot reach: a customer advisory with manual steps, a costly new update path, or accepted risk with a declared end of support.