Clarify upstream trust description in documentation

[ciaracarey]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
cloudsmith-docs	Ready	Preview, Comment	Apr 8, 2026 3:09pm

[Copilot]

Pull request overview

Updates the Upstream Trust documentation to broaden/clarify the threat model it claims to mitigate.

Changes:

• Expands the opening definition to mention “dependency confusion” in addition to “namesquatting”.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The addition of “dependency confusion” here makes the description internally inconsistent: later in this document the feature is described only as namesquatting protection (e.g., “protected from namesquatting” and “protects against namesquatting”). Either update the rest of the page to consistently describe both threats (and distinguish them), or remove “dependency confusion” to avoid over-claiming / confusing readers. Also consider aligning the dependency confusion description with the definition used elsewhere in the docs (src/content/formats/python-repository.mdx around the Dependency confusion note).

Suggested change

	Upstream trust is a supply chain security feature that prevents dependency confusion or namesquatting attacks where bad actors hijack your internal package name in public repositories. By designating upstream sources as trusted or untrusted, you control which sources are permitted to serve versions of packages that exist in your private repository or other trusted sources.
	This is particularly important for organizations that publish private packages alongside public open-source dependencies. Without upstream trust, a malicious actor could publish a package with the same name as your private package to a public registry, potentially tricking your build systems into pulling the attacker's version instead of your own.
	Upstream trust is a supply chain security feature that protects against namesquatting attacks where bad actors publish packages using the same names as your internal packages in public repositories. By designating upstream sources as trusted or untrusted, you control which sources are permitted to serve versions of packages that exist in your private repository or other trusted sources.
	This is particularly important for organizations that publish private packages alongside public open-source dependencies. Without upstream trust, a malicious actor could publish a package with the same name as your private package to a public registry, potentially tricking your build systems into pulling the attacker's package instead of your own.

[nicholasmccrea]

I’d probably keep it scoped to namesquatting for now. Dependency confusion covers a few different attack vectors, and upstream trust only protects against namesquatting really.