The Package Registry Is Now The Incident Scene

In the last few weeks, the software supply-chain story has become less abstract and much more operational.

Recent reporting describes a coordinated TrapDoor campaign across npm, PyPI, and Crates.io that used npm install hooks, PyPI import-time execution, Rust build.rs, credential theft, persistence, lateral movement, and hidden AI-assistant prompt files such as .cursorrules and CLAUDE.md. GitHub also confirmed that attackers stole data from thousands of internal repositories after a compromised employee device involving a poisoned VS Code extension. SANS covered the Axios npm compromise, where poisoned registry releases mattered even when the normal source repository did not tell the full story. TechRadar reported another Mini Shai-Hulud npm wave affecting hundreds of packages and introducing developer-environment persistence.

Those events point at the same uncomfortable truth:

When a malicious package advisory drops, the urgent question is not "do we have a perfect SBOM?" It is "which machines, build runners, caches, mounted images, and storage estates had that exact package or version on disk?"

That is the question VersionGopher is being built to answer.

What changed

Package registries used to feel like plumbing. They were important, but quiet. Developers installed packages, CI systems restored caches, virtual environments came and went, and everyone moved quickly because that is how software gets built.

Now the package manager is part of the threat path. The attacker does not need to breach your perimeter first if they can convince a developer workstation, CI runner, extension host, or build system to fetch and execute the wrong thing.

The recent attacks show several patterns that matter to operators:

npm packages can execute through lifecycle hooks such as postinstall.
PyPI packages can execute when imported, not just when installed.
Rust crates can execute build logic through build.rs.
VS Code and related developer extensions are a real workstation attack surface.
AI coding assistant context files can become an attack surface when hidden Unicode or instruction payloads are planted in project files.
GitHub source alone may not prove what was installed from a registry.
Caches, virtual environments, build directories, and mounted workspaces are evidence, even when they are not proof of runtime execution.

That last sentence is the important one. Evidence is not the same as conclusion. VersionGopher should preserve the evidence and help humans make the right conclusion.

Dogfooding made this concrete

While testing VersionGopher's package-risk capability against our own local agent development environments, a dogfooding scan surfaced hundreds of exact PyPI package identities and multiple OSV package advisory matches. The scan included package metadata from development virtual environments and package-manager caches, including examples such as idna, paramiko, and pip.

That did not mean the workstation was compromised.

It meant VersionGopher could answer a better question: "where did exact package and version evidence exist, and what kind of path context did it have?"

VersionGopher package-risk evidence from a dogfooding scan

The distinction matters. A package found in a virtual environment is different from a package found in a cache. A package found in a build runner is different from a package found in an abandoned directory. A known malicious package is different from a normal vulnerable package. A MAL-* advisory is different from a garden-variety vulnerability advisory.

VersionGopher keeps those lanes separate.

The product shape

VersionGopher package-risk scanning is intentionally evidence-first:

Record package artifacts without running package managers.
Identify exact npm and PyPI package identities from bounded metadata peeks where safe.
Keep OSV package advisory matches separate from NVD/CPE CVE matching.
Show all OSV package matches under Package Advisories.
Reserve Malicious Packages for OSV MAL-* malicious-package advisories.
Preserve path context so an analyst can distinguish cache, virtual environment, installed metadata, lockfile, repository config, and other artifact classes.
Record AI prompt-risk files and hidden Unicode markers without storing private prompt bodies.
Include package-risk summaries in assessment reports without claiming proof of execution.

That is the right level of humility for this problem. Presence on disk can be extremely important, but it is not the same thing as execution. A good tool should not blur that line just to sound dramatic.

What this means for buyers

The recent news gives security teams a very practical test.

Pick a package advisory from a real campaign. Ask:

Do any developer laptops have that package or version?
Do any CI runners have it in a workspace, cache, or virtual environment?
Do any mounted images, NAS shares, or data-lake staging areas contain it?
Is it a known malicious package, an ordinary vulnerable package, or just package inventory evidence?
Can we produce a report that shows what was found, where it was found, and what the tool is not claiming?

Most organizations cannot answer those questions quickly.

VersionGopher is designed to make that answer boring.

Sources worth reading

The bottom line

The package registry is no longer just a source of dependencies. It is part of the incident scene.

VersionGopher is not trying to become a sandbox, EDR, or package manager. It is staying in its lane: fast, portable, metadata-only software evidence. That lane is now directly in the path of some of the most active supply-chain risk buyers care about.