Design approved package registry and trusted publishing controls
Implementation Effort: Medium – Standing up governed Azure Artifacts feeds, enabling upstream sources as a scan-before-promote buffer, and moving publishing to trusted OIDC credentials is a multi-step effort across platform and security teams. User Impact: Low – Registry governance and publishing controls are configured by administrators; developers keep installing packages, now routed through the approved feed, without direct prompts. Lifecycle Stage: Build
Overview
Use approved package registries and trusted publishing controls so developers consume packages only from verified, governed sources and publishing workflows do not depend on stored registry credentials. Route package consumption through a controlled feed such as Azure Artifacts or another approved repository manager, and use GitHub Packages for internal package hosting where it fits the package lifecycle.
Every package a developer installs from a public registry is an implicit trust decision.
Threat actors exploit this by publishing typosquatted or malicious packages to registries such as npmjs.com, NuGet.org, and PyPI, knowing that a single poisoned dependency can compromise build systems, inject backdoors, or exfiltrate credentials.
Azure Artifacts upstream source controls let administrators govern which externally sourced packages are saved into a feed, helping prevent dependency confusion and giving the organization a central point for audit, caching, and blocking decisions.
For organizations on Azure DevOps, Azure Artifacts is the recommended implementation of this control. Stand up organization- or project-scoped feeds that support the package types you use (npm, NuGet, Maven, Python, Cargo, and universal packages), and point developer and pipeline package managers at the feed instead of public registries. Enable upstream sources on each feed so the feed becomes the single front door to public registries — packages are cached and recorded as they are first requested, giving you an inventory of exactly what entered the organization and a place to block specific packages or versions.
Use feed views (such as @Local, @Prerelease, and @Release) to separate ingested-but-unvetted packages from those promoted for general consumption, scope feed permissions so only approved identities can publish or promote, and apply retention policies so the feed does not grow unbounded while still preserving versions that builds depend on.
Where the package lifecycle is internal-only, GitHub Packages remains a fit for hosting first-party packages, but third-party consumption should route through the governed Azure Artifacts feed.
Use the feed as a quarantine buffer rather than a pass-through proxy. Configure upstream sources so externally published packages are pulled into an internal Azure Artifacts feed (or another repository manager that supports upstream sources) and held for scanning before they are promoted for developer or build consumption. Run dependency and vulnerability scanning against newly ingested versions, and apply a hold or review gate so a package version that was published moments ago — a common malware-injection window — is not consumed immediately across the organization. Promote a version only after it clears scanning and any review policy, and block or remove versions that fail. This scan-before-promote pattern means a single poisoned upstream release does not reach builds before the organization has a chance to detect it, and it pairs with the dependency scanning and software composition analysis controls (Dependabot and SCA) that evaluate what is already in the dependency graph.
For package publishing, use trusted publishing with OpenID Connect or workload identity federation where the ecosystem supports it so CI/CD workflows obtain short-lived credentials instead of stored registry secrets. Protect publishing workflows with branch protection, environment approvals where appropriate, and publisher-scoped permissions so only approved repositories, branches, and workflows can release packages. Where supported, pair trusted publishing with signed releases or provenance attestations so consumers can verify who published the package and from which workflow it originated.
Without approved registries and trusted publishing controls, organizations have limited visibility into what code enters the dependency graph and limited assurance over who published internal packages. Tight publisher scoping, verified package sources, and short-lived publishing credentials reduce the blast radius of stolen registry credentials or malicious upstream packages. By routing consumption through verified, governed sources and scoping publishing to short-lived, least-privilege credentials, this task supports Verify explicitly and Use least privilege access.
This task aligns with Microsoft's Secure Supply Chain Consumption Framework (S2C2F), which Microsoft contributed to the OpenSSF. S2C2F defines eight practices — Ingest, Scan, Inventory, Update, Audit, Enforce, Rebuild, and Fix/Upstream — across four maturity levels. Establishing approved registries and upstream source controls implements the S2C2F Ingest and Enforce practices, while trusted publishing and provenance attestations support the Audit practice. Organizations can use the S2C2F maturity model to benchmark their current state and plan incremental improvements toward higher supply chain assurance.