PowerShell is a critical automation and configuration platform across enterprises—and as that automation grows, how you source, validate, and distribute PowerShell packages becomes just as important as the scripts themselves.
Modern security guidance increasingly treats package feeds as part of the software supply chain. For PowerShell, that means being deliberate about which repositories you trust, how packages get promoted into your environment, and what your production systems are allowed to install at runtime.
Below, I outline PSResourceGet best practices for secure environments, then highlight roadmap investments that reinforce secure-by-default package management.
PSResourceGet Best Practices
If you aren’t already familiar, PSResourceGet is the modern package management solution for PowerShell, designed for:
- PowerShell modules, scripts, and DSC resources
- Multiple repository types, including NuGet-style feeds and OCI registries
- Explicit repository trust configuration
- Enterprise scenarios where packages are curated, mirrored, and approved before production use
A core design principle of PSResourceGet is to support multiple repository options so that you can separate package discovery from package consumption. That separation enables validation, approval, and governance gates—without blocking package discovery.
In practice, the best outcomes come from defining a small set of repositories with clear roles (discovery vs. production), then configuring PSResourceGet trust settings to enforce those boundaries.
Trusted Sources: Microsoft Artifact Registry (MAR)
For Microsoft-owned and Microsoft-published PowerShell modules, Microsoft Artifact Registry (MAR) is the trusted source
MAR provides:
- A Microsoft-controlled publishing pipeline
- Strong provenance and ownership guarantees
- Operational reliability suitable for enterprise automation
- Improved availability guarantees compared to PowerShell Gallery
MAR is positioned as the default trusted source for Microsoft-owned content, removing ambiguity about where Microsoft modules should be sourced from and reducing reliance on community mirrors for first-party artifacts.
PSResourceGet supports OCI-compliant registries, enabling enterprises to use the same infrastructure they already trust for container images and other artifacts.
This allows organizations to:
- Reuse existing identity, RBAC, auditing, and networking controls
- Centralize PowerShell packages alongside other enterprise artifacts
- Apply consistent supply chain governance across technologies
Today we only have support for Azure Container Registry (ACR) as a private repository, but we are working to adopt the .NET ORAS library which will enable support through any container registry (GitHub Container registry is an exciting one).
The PowerShell Gallery: A Community Repository
The PowerShell Gallery remains a critical part of the PowerShell ecosystem. It enables discovery, experimentation, and community collaboration. PowerShell would not be anywhere close to where it is today in terms of reach and popularity without all of the amazing package contributors.
From a security perspective, however, the PowerShell Gallery should be treated as:
- Untrusted by default
- Community-owned
- Unsuitable for direct production dependency
Because the Gallery is community-focused and doesn’t fall under any SLAs for availability it should not be treated as a guaranteed, controlled dependency for production workloads. We do our very best to make the gallery a dependable platform (and are in the midst of many infrastructure improvements) but for most environments, it is not recommended to use the PowerShell Gallery directly from production systems.
Instead, the Gallery should be treated as an intake and discovery source, with packages promoted into trusted enterprise repositories only after review and approval. At Microsoft we do this through Azure Artifacts feeds and a gated central feed system.
Private Repositories and Centralized Approval
A secure enterprise pattern is to introduce a central private repository that acts as the only trusted source for production systems.
This repository:
- Is fully controlled by the enterprise
- Contains only vetted and approved packages
- Provides predictable availability and performance
- Is explicitly configured as trusted in PSResourceGet
Azure Artifacts and private Azure Container Registry instances are commonly used for this role.
Example Enterprise Package Flow
- Discovery
Developers discover packages from:
- PowerShell Gallery (community)
- Microsoft Artifact Registry (Microsoft-owned)
- Trusted partners or internal teams
- Review and approval
Packages are evaluated for:
- Security posture (signing, provenance, vulnerabilities)
- Licensing and compliance
- Compatibility and quality
- Promotion to an enterprise feed
Approved packages are:
- Mirrored or re-published into a central enterprise repository
- Version-pinned (and optionally scanned) before broader rollout
- Production consumption
Production systems:
- Use PSResourceGet for installs and updates
- Trust only the enterprise repository
- Do not depend on external feeds at runtime
Limitations to this workflow
We are in the design phase of two improvements to this workflow that we hope will make it easier to use and maintain. The first is allowing cross-repository dependencies to be specified in a psd1 and handled in an appropriate manner by PSResourceGet. The second is to allow packages that have been re-published to a central feed to be able to get updates from their original feed. Check out the RFC for cross-repository dependencies here.
Roadmap for PSResourceGet 1.3 (vNext)
PSResourceGet 1.3 continues the shift toward enterprise-friendly package management: clearer trust defaults, better support for modern registries, and features that reduce friction when you scale installs across fleets and CI/CD.
We are excited to announce that PSResourceGet 1.3-preview1 is available with the following updates:
- Add MARas default registered repository
- Add concurrent (parallel) execution for Install-PSResourceworkflows
- Add DSC V3 resource for PSResourceGet
First-Class DSC Resource Support
Earlier iterations of package management relied on mechanisms such as RequiredResourceFiles for Desired State Configuration scenarios.
The roadmap moves toward:
- Native DSC resource support
- Clear, consistent handling of configuration artifacts
- Better integration with modern DSC workflows
This simplifies authoring, improves clarity, and reduces special-case behaviors in package management.
Microsoft Artifact Registry as a Default Repository
To reduce ambiguity and improve trust defaults, MAR is expected to become a default repository for Microsoft-owned PowerShell packages.
This:
- Makes trust boundaries explicit
- Reduces reliance on community mirrors for first-party content
- Aligns PowerShell with broader Microsoft artifact distribution patterns
Concurrent Installs and Performance Improvements
Enterprise automation often installs multiple packages at scale.
Upcoming work focuses on:
- Supporting concurrent package installs
- Improving performance and reliability
Reducing friction in large-scale automation and CI/CD scenarios
ORAS Support
ORAS support improves how PSResourceGet works with OCI registries by using the ORAS client library for pushing and pulling PowerShell artifacts. This strengthens compatibility with enterprise registry implementations and helps align PowerShell packages with the broader OCI ecosystem.
Cross-Repository Dependencies
Cross-repository dependency support reduces the need to copy every upstream dependency into the same feed during development. In enterprise environments, this is most useful when paired with policy: allow broader repository access for dev/test but restrict production to approved repositories only.
Dropping Support for Windows PowerShell
Future versions of PSResourceGet (beginning with 1.3) are aligned with the broader PowerShell platform direction, focusing on PowerShell (Core).
Removing Windows PowerShell support allows:
- Reduced complexity in release and validation process
- Support for ORAS library and other new features
- Alignment with cross-platform and cloud-native scenarios
This reinforces the expectation that modern automation environments standardize on supported, actively developed runtimes.
Why This Matters
Together, these investments reinforce our direction:
- PowerShell packages are part of the enterprise supply chain
- Trust boundaries must be explicit and enforceable
- Production automation must be deterministic and reliable
- Community innovation and enterprise governance can coexist
PSResourceGet is evolving to make secure-by-default behavior the easiest path forward—so teams can move fast and keep trust boundaries explicit.
Next steps: If you manage PowerShell in an enterprise, inventory which repositories your automation can reach today, decide what your single trusted production feed should be, and set PSResourceGet trust configuration to enforce that model. Then, build a lightweight intake process (review, scan, approve, promote) for anything sourced from the broader community.
0 comments
Be the first to start the discussion.