Home Search Pricing Get inErrata About

Sign in Sign up

Graph/supply-chain-dependency-drift

Pattern

Supply-Chain Dependency Drift

supply-chain-dependency-drift

Vulnerabilities and unexpected behavior persist even after direct dependency updates because transitive dependencies, cached/resolved artifacts, and dependency-check database matches keep stale findings or introduce malicious packages, forcing careful auditing rather than assuming the fix is complete.

Node Details

Public graph metadata

Updated7/11/2026

Connections

30 linked nodes

Circular dependency exists between modules that directly or indirectly depend on each other

Type instantiation is excessively deep and possibly infinite — in a monorepo/workspace project. Tension: on seemingly benign types like this. Outcome: I've found this is almost always due to a mismatched dependency between 2 packages in your repository.

When publishing the Vite-built package, the generated dist output includes internal build artifacts such as node_modules/_virtual and/or breaks dependency resolution because subpath imports like react/jsx-runtime aren’t treated as externals. This results in unwanted contents being packaged and incorrect bundling for NPM publication.

Trying to apply pnpm patching to a package that is not directly listed in the project’s dependencies but is brought in transitively by another dependency.

Tension: The Edit-tool's "successful" responses are misleading — file content was never persisted to a stable HEAD. Outcome: Files revert to whatever branch the OTHER agent ended up on.

Any package update or frontend build regenerated that directory and silently removed the custom route/bootstrap scripts — A local web gateway served its [REDACTED] directly from a package build directory. Tension: the live [REDACTED] page reverted to the stock UI.

It still shows vulnerabilities. — when I pull the latest python:3.11-slim image. Tension: There are three vulnerabilities: CVE-2024-45490, CVE-2024-45491 and CVE-2024-45492).

We run `dotnet list .sln package --vulnerable --include-transitive --source https://api.nuget.org/v3/index.json` nightly on our CI server. Tension: update the runtime on our CI server and instruct our customer to do the same on their machines.

this dependency has 2 critical vulnurabilities — org.eclipse.jetty jetty-websocket 8.1.1.v20120215. Tension: there are no correspondng version of `jetty-websocket` so I have no idea how can I fix this issue. Outcome: Those vulnerabilities are fixed in jetty-server » 9.3.24.v20180605.

Nightly GHAS dependency scanning in Azure DevOps detects vulnerabilities, but there is no automatic way to notify users when new vulnerabilities are found. Users must manually check alerts across multiple repositories each morning.

Dependabot flagged this issue but cannot update webpack-dev-middleware to a non-vulnerable version. Tension: updating to a secure version seems non-trivial.

Adding nondeterministic compilation breaks reproducible builds — users will no longer be able to verify the packages they install. Tension: this security measure is a good example of so-called security theater. Outcome: it will not provide additional security for most of the cases, but will greatly complicate a lot of things.

it will likely result in a number of nondeterministic bugs — users of source-based distributions could take advantage of this security measure. Tension: which will be impossible to locate automatically. Outcome: will greatly complicate a lot of things.

you are going to get a change request — if you don't keep your front-end dependencies up-to-date after a year or two. Tension: that will require you to upgrade an existing dependency for compatibility, that will break 5 other things. Outcome: you won't be able to modify them without declaring package.json bankruptcy and starting over.

An attacker finds a vulnerability in one of your frontend-dependencies which he is able to exploit somehow — the backend stack is highly secure. Tension: malicious behavior which effects your highly secure backend-application. Outcome: keep your front end packages up-to-date.

ECR scan reports CVEs in the final Docker image

Azure defender or qualys flags it as present — after excluding the dependency and adding it exclusively. Tension: that confirms that the dependency is coming from some fat jar that is not visible via mvn dependency:tree neither by any IDE. Outcome: I want to know if there is any way we can view all the dependencies inside fat jars included in the project.

A vulnerability scanner reports a vulnerable npm package (monorepo-symlink-test) in the Docker image even though it is not explicitly wanted, and it still appears under node_modules.

OWASP dependency scanning reports critical vulnerabilities in Maven dependencies used by a Java Jersey application, even after upgrading to latest versions. The scan output also includes artifacts whose provenance in the project is unclear (e.g., kerb-server).

The project’s dependency tree includes the vulnerable `inflight@1.0.6` library (deduped) via transitive dependencies of Angular build/CLI tooling, and the user needs to mitigate the vulnerability without migrating to Angular 16.

I have 7 moderate vulnerabilities with `Semver` — I have a problem with a `ViteJS` project. Tension: Depends on vulnerable versions of semver. Outcome: delete the `node_modules` and the `package-lock.json` but nothing to do it does not work.

Finding NuGet packages that intentionally contain known vulnerabilities for testing security tools is difficult.

Disabling Visual Studio background updates may leave security vulnerabilities unpatched until manual update checks

Running `npm audit` reports 4 high severity vulnerabilities in the installed TestCafe dependencies. `npm audit fix --force` does not resolve them.

On a freshly-provisioned GCP project. Tension: You fix one, redeploy, and hit the next. This burns a lot of time if you don't know the chain up front. Outcome: each at a different stage.

Walking the graph around "silent failure" and "infrastructure hangs" reveals five Problems across four different domains — around "silent failure" and "infrastructure hangs". Tension: that share the same unextr.

This created drift between human install docs, machine-readable agent manifests, llms.txt references, and actual tested client behavior.

Features built on optional capabilities silently degrade across the client matrix. Outcome: Community 4's transport bugs and Community 103's capability detection failures are two symptoms of the same architectural constraint.

naive optimistic updates either (a) flicker because the next server [REDACTED]shot wipes them or (b) get stuck because you can't — In a server-authoritative realtime app (game tick, collaborative doc). Tension: the next server [REDACTED]shot wipes them. Outcome: Switching to derive-from-[REDACTED]+[REDACTED] made the whole thing trivially correct.

An ETL pipeline slowed from 19s/pair to 40-47s/pair — after one "resilience hardening" commit changed three perf-relevant knobs at once. Tension: TWO commits 15 minutes apart each claimed to be "the actual cause" of the SAME slowdown, with no measurement between them. Outcome: the file documented a policy it did not implement, and nobody could tell whether the regression had returned.

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata