Understanding the PowerShell PSResource Roadmap and Best Practices

This article is a technical commentary and implementation example created using AI. The published code and procedures are based on primary sources, but the author has not verified their operation on actual hardware. Behavior may vary depending on the environment and version.

As PowerShell automation infrastructure spreads within enterprises, the importance of package acquisition, validation, and distribution has become equal to that of the scripts themselves. Modern security guidelines treat package feeds as part of the software supply chain. Based on the content published in the official blog, this article outlines best practices for PSResourceGet in secure environments and its future roadmap.

[Scheduled for verification in Windows environment]

Overview and Design Philosophy of PSResourceGet

PSResourceGet is a modern package management solution for PowerShell. Its main targets are as follows:

• PowerShell modules, scripts, and DSC (Desired State Configuration) resources

• Multiple repository types, including NuGet-format feeds and OCI registries

• Explicit repository trust settings

• Enterprise scenarios for vetting, mirroring, and approving packages before production use

The core design principle of PSResourceGet lies in supporting multiple repository options and separating “package discovery” from “package consumption.” This separation makes it possible to establish validation, approval, and governance gates without hindering package discovery.

flowchart TD
    A["PowerShell Gallery / Discovery"] --> B["Central Enterprise Private Repository / Review & Approval"]
    C["Microsoft Artifact Registry / MAR"] --> B
    B --> D["Production Systems / PSResourceGet"]

Best Practices and Repository Roles in Secure Environments

Primary sources recommend defining repository role divisions and establishing trust boundaries tailored to your environment.

Microsoft Artifact Registry (MAR)

For PowerShell modules owned and published by Microsoft, the Microsoft Artifact Registry (MAR) serves as a trusted source. MAR features the following:

• A publishing pipeline controlled by Microsoft

• Strong provenance and ownership guarantees

• Operational reliability suitable for enterprise automation

• Improved availability compared to the PowerShell Gallery

OCI-Compliant Registries and Azure Container Registry (ACR)

PSResourceGet supports OCI-compliant registries, allowing enterprises to reuse infrastructure they already trust for container images and similar assets. Azure Container Registry (ACR) is currently supported as a private repository, and adoption of any container registry (such as GitHub Container Registry) is progressing through the use of .NET ORAS libraries.

PowerShell Gallery (Community Repository)

While the PowerShell Gallery is essential as a venue for discovery, experimentation, and community collaboration, from a security perspective it should be treated as follows:

• Do not trust by default

• Community-owned

• Unsuitable for production dependencies

Because the Gallery is not subject to availability SLAs, using it directly from production systems is not recommended. It is best operated as an intake source for development and discovery, promoting only approved packages to the enterprise trusted repository.

Components of the Enterprise Package Flow

In a secure enterprise pattern, a “central private repository” is introduced as the single source of truth for production systems. The package lifecycle is organized as follows:

1. Discovery: Developers find packages from the PowerShell Gallery, MAR, trusted partners, etc.

2. Review and approval: Security posture, licensing, compatibility, and quality are evaluated.

3. Promotion: Approved packages are mirrored or republished to the central repository, where version pinning and scanning are performed.

4. Production consumption: Production systems install and update via PSResourceGet, trusting only the corporate repository.

Additionally, design phase efforts to improve workflows include specifying cross-repository dependencies in .psd1 files and enabling packages republished to the central feed to receive updates from their original feeds.

PSResourceGet 1.3 (vNext) Roadmap

PSResourceGet 1.3 is scheduled to feature updates that strengthen enterprise package management. The preview release, PSResourceGet 1.3-preview1, includes the following updates:

• Adding MAR as a default registered repository

• Adding parallel execution (concurrent execution) for the Install-PSResource workflow

• Adding DSC V3 resources for PSResourceGet

Key Changes and Features

• First-class DSC resource support: Migrating away from legacy mechanisms like RequiredResourceFiles to achieve clear and consistent handling of configuration artifacts.

• Parallel installation and performance improvements: Reducing friction in large-scale automation and CI/CD scenarios.

• ORAS support: Strengthening integration with OCI registries and aligning with the container ecosystem.

• Cross-repository dependencies: Combining policies that permit broad repository access during development while restricting production, thereby reducing the duplication of upstream dependencies.

• End of Windows PowerShell support: Starting with version 1.3, PSResourceGet will focus on PowerShell (Core) and end support for Windows PowerShell. This reduces the complexity of release and validation processes while accommodating cross-platform and cloud-native scenarios.

Conclusion

Primary sources emphasize the importance of setting clear, enforceable trust boundaries based on the recognition that PowerShell packages are part of the supply chain. As a next step, you are encouraged to inventory reachable repositories within your environment, determine a single trusted production feed, and configure PSResourceGet’s trust settings.

References

• PowerShell PSResource Roadmap and Best Practices