Blog — Omni Line

Supply-chain controls when AI agents install dependencies — Omni Line

Sign in

Get started

Sign in

Back

The install path got faster than review

Software supply-chain attacks are not new. Typosquats, compromised maintainer accounts, and delayed CVE disclosure have been routine for years. What changed is who initiates the install and how often .

Coding agents, IDE copilots, and autonomous “fix this / scaffold that” loops do not stop at suggesting code. They edit lockfiles, run package managers, open pull requests, and—when given shell access—execute npm install, pip install, go get, or whatever the prompt needs to make the tests green. Humans still merge; agents still create the dependency graph that lands in CI and production.

If your only controls are “an engineer glances at package.json” and “Dependabot opens a weekly PR,” you are defending a review process that agents can outpace. The durable control plane is the registry choke point : the place every ecosystem client resolves names and downloads bits. That is where vulnerability checking and install-time policy belong.

What “supply chain” means here

For package-consuming teams, the relevant supply chain is not a vendor questionnaire. It is the path from a package name + version to bytes on a builder :

A client asks a registry for metadata (which versions exist, which one a range resolves to).

The client downloads an artifact (tarball, wheel, module zip, …).

Build and runtime trust that artifact.

Attackers abuse that path in familiar ways:

Pattern<br>What happens

Typosquat / brandjack<br>Near-name package publishes malware; an agent (or autocomplete) picks the wrong name

Compromised publish<br>A real package ships a bad version; clients that float ranges pick it up

Known vulnerable version<br>Not malware—just a CVE still present in what you resolve

Malicious advisory (MAL-…)<br>OpenSSF and ecosystem feeds flag packages/versions as intentionally hostile

Vulnerability databases such as OSV aggregate ecosystem advisories (including malicious-package ids). A scanner that never influences resolve and download only produces reports. A supply-chain system that strips blocked versions from metadata and 403s artifact GETs changes what clients can install—even when an agent never reads the report.

Why the agentic era raises the stakes

Agents optimize for “make it work,” not “is this package safe?”

An agent rewarded for green tests will add a dependency that unblocks compilation. It will not, by default, ask whether lodash-adjacent names are typosquats, whether the version is hours old on a compromised account, or whether OSV already lists a MAL- advisory. That is not a moral failing of the model; it is the objective function of “fix the build.”

Volume breaks human review

A senior engineer can carefully vet three dependency changes in a PR. Ten agent-generated PRs in a day, each touching transitive trees across npm and PyPI, will not get the same attention. Reviewers skim diffs; lockfile noise wins.

Parallelism multiplies blast radius

Multiple agents (or one agent with broad CI credentials) can pull the same bad version into many repos before anyone correlates the failure. The shared control must sit above the individual repo: org-wide registry policy, not per-repo scanner config that drifts.

Laptop scanners are necessary but insufficient

Running npm audit or an IDE plugin on a developer machine helps the person who remembers to look. It does not stop:

A CI job that resolves against the public registry with a broad range

A colleague who installed before the advisory landed in their local tool

An agent session that never opened the audit UI

Controls at the registry apply to every client that uses that registry URL—humans, CI, and agents alike.

Constraints you actually design for

Before picking tools, write down the constraints. They decide where enforcement can live.

Constraint<br>Design implication

Polyglot stacks (npm + PyPI + Maven + …)<br>One policy plane beats five vendor UIs with different severity vocabularies

CI must stay fast<br>Prefer background scans + serve-time enforcement over synchronous “scan every GET”

Agents and humans share credentials carefully<br>PATs for automation; least privilege so a compromised agent token cannot publish

Not everything is in OSV<br>Docker images and generic blobs need different scanners—do not pretend package OSV covers OCI

Air-gapped networks<br>Outbound calls to api.osv.dev may be impossible; plan for mirror/egress or accept degraded mode

False positives kill adoption<br>Default-block malicious advisories; make severity thresholds an explicit org decision

A practical control design

Think in three layers. Miss one and agents walk around the others.

1. Inventory where packages actually live

You cannot protect versions you never indexed. Hosted private packages, proxy caches of upstream, and virtual aggregates should be known to one system of record. Ad-hoc curl to the public registry from CI is...