TL;DR: Go’s module ecosystem preserves integrity through proxy caching and checksum verification, but Boost Security shows that those controls do not establish trust, leaving room for repojacking, domain takeover, dependency confusion, typosquatting, and cached malicious pseudo-versions to persist undetected. The practical lesson is that supply-chain governance must extend beyond hashes to ownership, namespace, and lifecycle controls.
NHIMG editorial — based on content published by Boost Security: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- Boost Security found 63,386 packages hosted on deleted GitHub accounts that were still cached and available in the Go Proxy.
- The research identified 9,571 hijackable zombie repositories that were currently being imported as dependencies in public Go projects.
Questions worth separating out
Q: What breaks when Go module ownership is not continuously governed?
A: When ownership is not continuously governed, a trusted module path can be reclaimed, redirected, or impersonated after the original maintainer disappears.
Q: Why do immutable package caches still create supply-chain risk?
A: Immutable caches preserve what was downloaded, but they do not prove the package came from a trustworthy publisher.
Q: How can security teams know if an external dependency has become unsafe?
A: Look for ownership changes, unexpected redirects, script hash drift, and administrative activity that does not match the supplier’s normal pattern.
Practitioner guidance
- Inventory module publishers and ownership states Map every Go dependency to its current repository owner, domain owner, and account status so deleted or renamed identities are visible before build time.
- Block private dependency fallbacks to public resolution Enforce GOPRIVATE and related build policies so internal modules cannot silently resolve from public registries when developers are on the wrong network or using incomplete config.
- Review pseudo-versions and dangling commits Search for dependencies pinned to pseudo-versions or commit hashes that may survive after a source cleanup or force-push.
What's in the full report
Boost Security's full analysis covers the operational detail this post intentionally leaves for the source:
- The step-by-step repojacking, domain takeover, and dependency confusion examples used to demonstrate how Go packages can be hijacked.
- The Gobelin detection approach for identifying deleted GitHub accounts and repojackable module paths before they reach production builds.
- The full pseudo-version and dangling-commit discussion, including how malicious code can persist after source cleanup.
- The research methodology behind the counts of hijackable packages, zombie repositories, and public go.mod exposures.
👉 Read Boost Security's analysis of Go module hijacking, proxy immutability, and trust gaps →
Go modules, proxy immutability, and the trust gap teams miss?
Explore further
Integrity is not trust, and supply-chain teams are still conflating the two. Cryptographic verification tells you that a module has not changed since it was cached, but it does not tell you whether the original publisher still owns the namespace or whether the artifact was ever trustworthy. That distinction matters because module paths now function like machine identities in the software supply chain. Practitioners should treat publisher identity as a governed asset, not a naming convention.
A question worth separating out:
Q: Who is accountable when a build pipeline imports a hijacked module?
A: Accountability usually sits with the team that owns dependency governance, CI policy, and release validation together. If ownership records, private resolution rules, and publisher reviews are not maintained, the organisation has accepted a supply-chain identity risk. Frameworks such as NIST CSF and supply-chain controls require that responsibility be explicit, monitored, and periodically revalidated.
👉 Read our full editorial: Go module integrity hides a broken trust chain for supply chains