Dependency Risk & SCA

A lockfile line names the exact package version, the source it is fetched from and the bytes accepted as that release. Editing it swaps different executable code into the build, with no source-file diff to review.

Scope says where a package is needed, so it decides whether the package is in the artifact you deploy. A test-only library is absent from production and a production attacker cannot reach it.

Check how many people really maintain it, whether releases and patch fixes still ship, whether it publishes a way to report a flaw privately, what the license is, how large the transitive tree is, and how much of it you actually need.

EPSS estimates the probability a vulnerability will be exploited in the wild within 30 days. A score of 0.08 means roughly an 8 percent chance. It forecasts likelihood, not how damaging the flaw is.

A time-boxed suppression hides a finding until an expiry date, after which it returns to the queue for a fresh decision. A permanent ignore removes it for good, so a stale or wrong judgment is never re-examined.

It matches each resolved package version in your dependency tree against an advisory's affected version range for that same package identity. That is version arithmetic. It never inspects whether your code calls the vulnerable function.

You do not choose that version. An intermediate library in your graph declares which version of the flagged package to pull, so until that library raises or widens its constraint, your build keeps resolving the vulnerable one.

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.

Confirm both read the same resolved dependency set, then diff the lists by alias-normalised identifier. Every difference resolves to a feed gap, a coarser range, an un-collapsed duplicate, or stale data. The bigger number is not the safer one.

A miss on a name in your own namespace must be a visible build error, never a fetch from somewhere else. Failing closed stops the build; failing open quietly succeeds with an artifact nobody in your organisation published.

The hash is compared with the bytes fetched from the source named in that same entry. An attacker who edits both simply records a hash matching their own payload. Lockfile hashes detect tampering in transit, not a tampered lockfile.

Reachability asks whether your application ever executes the vulnerable code. Exploitability asks whether an attacker in some position can drive that code with input they control. Code can be reachable and still not exploitable.

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.

Treat KEV membership as a hard remediation trigger and work it now. Listing means exploitation has actually been observed in the wild - evidence, not a prediction - and it overrides a severity band, which rates the flaw, not attacker behaviour.

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.

A cooldown makes a newly published version unresolvable for a fixed period, often around 72 hours, so a malicious or hijacked release has time to be reported or pulled before any of your builds consume it.

Findings are counted against the resolved graph, not the manifest. Each direct dependency drags in its own closure, so a two-import project can resolve to hundreds of modules. Depth predicts volume, not severity.

Deduplicate on the finding's identity — the advisory plus the package identity and affected version — not on the scan result. Track one item with one accountable owner, keeping the twelve service occurrences as child records.

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.

Distributions backport security patches into their own package revision and keep the upstream version number. Matching that version against an upstream advisory range reports it vulnerable; only the distribution's own advisory feed records that the fix is already present.

Only the enforced path is protected. A laptop installing without hash checks accepts whatever a compromised mirror or proxy serves, and the next regeneration writes those bytes' digest into the repository - which CI then enforces faithfully forever.

A build-scope dependency executes on the build machine, under the build's identity, with the source tree, network and deploy credentials in reach. It never sees production, but it can take those credentials or alter the artifact.

Decide on blast radius and on what compromising that maintainer would later buy an attacker. This code sits on the path that authorises money movement, so either fund real review and vendor it, or write only the narrow part you need.