A pseudo-version is a Go module version derived from a specific commit rather than a standard release tag. It can improve traceability, but it also creates a persistence risk if a malicious or abandoned commit is cached and later consumed as if it were a trusted release artifact.
What pseudo-versions are and why they exist
Pseudo-versions are Go module versions generated from a specific commit when a project does not have a suitable release tag. They preserve ordering and traceability across module history, which helps consumers pin dependencies precisely even when maintainers have not cut a formal release.
That convenience comes with a supply-chain trade-off: a pseudo-version can look like a stable, intentional dependency reference even though it is tied to a commit SHA rather than a release process. In practice, that means the trust signal comes from the source repository and commit history, not from the version string itself.
How pseudo-versions work in Go module resolution
Go uses pseudo-versions to express an exact point in history while still fitting the module versioning model. They are especially common when a dependency is consumed before its first tagged release, after a tag has moved, or when a project needs to reference a commit that sits between releases.
The version format is useful because it lets tooling resolve a deterministic dependency without inventing an arbitrary local label. But because the value is derived from commit metadata, its meaning depends on the integrity of the repository, the authenticity of the commit, and the correctness of the module cache or proxy path that supplied it.
Security implications of commit-derived versions
Pseudo-versions can improve provenance, but they also extend the life of whatever commit they reference. If a malicious, compromised, or simply abandoned commit is still available through a cache, proxy, or transitive dependency path, it may be consumed later as though it were an acceptable upstream artifact.
That risk is not unique to Go, but pseudo-versions make it easier to depend on specific untagged history in a way that is less visible than a named release. A build may therefore remain reproducible while still being anchored to a weak or stale trust decision.
Where pseudo-versions fit in dependency governance
Pseudo-versions are best treated as a governance signal, not just a formatting detail. They tell you that the consuming project is depending on a particular commit state, so dependency review should include repository integrity, commit provenance, and whether the module should instead be upgraded to a tagged release.
That is especially important for long-lived systems, where a pseudo-version can survive in manifests long after the original context has been forgotten. Over time, the version string can outlast the human memory of why that commit was chosen.
Risk and Threat Considerations
Pseudo-versions create a persistence and trust risk because they can keep a specific commit reachable in builds long after it should have been reconsidered. If the referenced commit was malicious, abandoned, or later exposed as unsafe, downstream consumers may continue pulling it from a cache or proxy path with no obvious change in the application manifest.
Failure mechanism: A dependency resolver or cache reuses commit-derived module metadata and preserves access to an artifact that never had the governance signal of a formal release, allowing unsafe code to remain in circulation.
Impact: Builds can inherit compromised or obsolete code, and teams may miss the need to review, replace, or re-pin the dependency because the pseudo-version appears precise and legitimate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity | Pseudo-versions depend on provenance and artifact integrity for consumed commits. |
| Recommendation — Verify commit provenance and protect dependency resolution paths with provenance-aware build controls. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Commit-derived dependencies need supply-chain controls over sourced software and components. |
| Recommendation — Apply SA-12 to vet dependency provenance and restrict untrusted module inputs. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Module proxies, caches, and external dependency sources behave like supply-chain providers. |
| Recommendation — Govern third-party dependency sources and review their trust and integrity controls. | ||
| NIST CSF 2.0 | PR.DS-08 — Integrity of Hardware, Software, and Data | Pseudo-versions affect software integrity by anchoring builds to specific commit states. |
| Recommendation — Use PR.DS-08 to preserve software integrity for commit-derived dependencies. | ||
Practitioner Guidance
Why practitioners should care: Pseudo-versions are operationally useful, but they deserve the same scrutiny as any other supply-chain pointer. If your dependency chain contains them, the key question is whether the commit is intentionally pinned, still trusted, and still the best available source of truth.
What to watch for: Repeated pseudo-versions in critical dependencies, long-lived references to untagged commits, and unexpected reuse from caches or internal proxies. Where possible, prefer tagged releases for stable consumption and verify the repository history behind any pseudo-version that remains in use.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org