The Live-Fetch Dependency: Why "@latest" Is a Supply-Chain Decision

Why live fetching keeps appearing

Modern package ecosystems make it trivially easy to run code you have never seen. A single command — npx, pipx, uvx, equivalents in every language — will, in seconds, download a package from a public registry, execute its post-install hooks, and start it as a subprocess. For interactive development and prototyping, this is exactly the right design. For production runtimes, it shifts a substantial integrity decision out of the team's hands.

AI agent stacks have made the temptation worse. The setup instructions for most agent frameworks include an install line that uses @latest, intended to demonstrate the agent running in five minutes. Quick-start configurations get copied into production. The team inherits the demonstration's supply-chain assumptions without ever having reviewed them.

What actually happens on a "@latest" install

When an agent runtime resolves a package version of @latest (or omits the version entirely, which defaults to the same), the steps that follow are these:

1. The client contacts the public registry and asks for the version currently tagged "latest" for the package.
2. The registry returns whatever the package maintainer most recently designated. The maintainer can change this at any time, with no notice and no change-controlled process visible to consumers.
3. The client downloads the tarball. No integrity check is performed against any value recorded by the consuming organisation.
4. The tarball's postinstall script (or equivalent) runs with the user's full filesystem and network access.
5. The package's entrypoint runs as a long-lived subprocess.

At no point in this sequence does the consuming organisation verify that the code being executed is the same code anyone in the organisation has ever reviewed. The trust is delegated entirely to the package maintainer's account hygiene.

The Live-Fetch Dependency anti-pattern

A hypothetical compromise scenario

The following illustrates a plausible failure mode under the Live-Fetch Dependency anti-pattern. The shape is drawn from several reported industry incidents; no specific incident is implied.

On day zero, the maintainer of a small package that appears as a transitive dependency in an agent runtime is phished. The attacker publishes a new version of the package with a modified postinstall script that exfiltrates environment variables, the contents of the user's source-control credentials directory, and the first two kilobytes of every text file in the working directory.

Within minutes, every user who restarts their agent fetches the compromised version. Each user's credentials land at the attacker's collection endpoint. By the time the maintainer notices and publishes a clean replacement, the original release has been resolved by thousands of installations.

Users who pinned to a specific prior version by hash are unaffected. The compromised version's hash does not match what their lockfiles record, and their reproducible install machinery refuses to proceed. They learn about the incident from the news cycle, not from the post-mortem of their own outage.

Pinning is not a productivity tax. It is the difference between learning about an incident in the news and learning about it in your own logs.

The controls that compose into a defence

1. Pin to exact versions.

   For every direct dependency the runtime needs, specify the exact version, not a floating tag. The cost is a small per-quarter review burden; the benefit is reproducibility.

2. Commit a lockfile with integrity hashes.

   The lockfile records the exact resolved version and the cryptographic hash of every direct and transitive dependency. Reproducible install tools (npm ci, pip install --require-hashes) verify the hash before executing.

3. Install reproducibly in continuous integration.

   Build pipelines use the reproducible install variant exclusively. Any drift between the lockfile and the resolved versions fails the build.

4. Enable automated security advisories.

   Tools like Dependabot, Renovate, and equivalent services open pull requests when a pinned version receives a published vulnerability advisory. Pinning is not a substitute for tracking vulnerabilities; the two controls compose.

5. Add an audit gate to continuous integration.

   npm audit, pip-audit, or equivalent run as a build step that fails on findings above an agreed severity threshold. The gate prevents merging known-vulnerable lockfile changes.

6. Generate and publish a Software Bill of Materials.

   A CycloneDX or SPDX SBOM is produced as a release artefact. The SBOM answers the audit question "what is running" without manual reconstruction. CISA and the EU Cyber Resilience Act both treat SBOM as table stakes for software shipped to enterprise customers.

7. Consider a private registry that quarantines.

   For organisations with the engineering capacity, routing all public package installs through a private registry that holds new versions for a quarantine period (often 24–72 hours) catches the most aggressive compromise patterns before they propagate.

SBOM and SLSA: where they fit

Two industry frameworks formalise the controls above and are worth understanding in context.

SBOM (Software Bill of Materials). A machine-readable list of every component in a release with versions, hashes, and licences. SBOM answers "what is in this artefact." It does not answer "how do we know it was built faithfully." Required for software sold to the US federal government under Executive Order 14028, and for software placed on the EU market under the Cyber Resilience Act.

SLSA (Supply-chain Levels for Software Artifacts). An attestation framework defining provenance for built artefacts. SLSA Level 1 requires any build process; Level 2 requires hosted builds (GitHub Actions counts) with signed provenance; Level 3 requires non-falsifiable, isolated, source-verified builds. SLSA answers "how do we know it was built faithfully." Major platform providers and a growing number of regulated customers now expect SLSA Level 2 or higher for shipped artefacts.

SBOM and SLSA address different questions. Both are useful. Neither replaces the upstream discipline of pinning what you depend on.

A practical checklist

• Every direct dependency in the agent runtime configuration is pinned to an exact version. No @latest or unversioned references.
• A lockfile recording exact versions and integrity hashes for every direct and transitive dependency is committed to the repository.
• All installation in continuous integration uses the reproducible-install variant (npm ci, pip install --require-hashes, equivalent).
• Automated dependency-update tooling (Dependabot, Renovate) is enabled and opens pull requests for security advisories.
• A continuous-integration audit gate fails the build on dependency vulnerabilities above the agreed severity threshold.
• A Software Bill of Materials (CycloneDX or SPDX) is produced as a release artefact.
• Build pipelines emit signed provenance attestations sufficient for SLSA Level 2 or higher.
• A supplier inventory records each direct dependency, its source, its named owner, and its review cadence.
• Dependency updates are reviewed by a named human; auto-merge is reserved for the lowest-impact change classes.
• For high-assurance workloads, public package installs are routed through a private registry that applies a quarantine period to new versions.

Test your own codebase in ten minutes

The fastest way to find out whether this anti-pattern is present in your own system is to ask an AI coding assistant to look for it. Run the prompt below in a fresh chat session, on its own — and judge the system by what the code actually does, not by what its documentation claims.

Search the whole repository to find where this applies — do not
wait for me to list files. Ignore generated, vendored, and dependency
folders (build output, node_modules, vendor). Identify every location
the failure mode below could occur, read those files in full before
you judge, and list the search terms you used so I can confirm nothing
was missed.

You are looking for one specific failure mode: the agent (or its
install / startup script) fetches code or container images using
floating references — for example ":latest", "@main",
unpinned package installs at runtime, or "curl ... | sh"
patterns. A pinned version, a lock file, or a content hash counts
as not-present.

Respond with exactly these four sections:
1. VERDICT: one of [present / not present / unclear]
2. EVIDENCE: file path + line numbers + a one-line quote per claim
3. WHY IT MATTERS: two sentences, plain English
4. FIX: a concrete change, with a short before/after code snippet
   if applicable. If "unclear", list the one piece of context you
   need to decide.

Insist on the four-part answer: a verdict with a file path, a line number, and a one-line quote is something you can act on; a verdict on its own is just an opinion. If the result is present, the FIX section is your starting point — pin every dependency to a specific version, lock file, or content hash instead of a floating reference. Re-run the same prompt after the change to confirm the verdict flips to not present.

Conclusion

Live-fetching dependencies is one of the few patterns in production engineering with both a clear failure history and a fully-documented remediation. The supply-chain incidents of the past decade are not rare exceptions; they are the predictable outcome of delegating integrity to whoever last published the package. The controls that prevent them are inexpensive, well-supported in tooling, and required by an increasing range of customer and regulatory frameworks.

Adopt them once. Treat the lockfile as the source of truth. Treat @latest in a production configuration the way you would treat any other unreviewed code change — because that is what it is, evaluated fresh every session.