PowerShell is a important automation and configuration platform throughout enterprises—and as that automation grows, the way you supply, validate, and distribute PowerShell packages turns into simply as essential because the scripts themselves.
Trendy safety steering more and more treats package deal feeds as a part of the software program provide chain. For PowerShell, which means being deliberate about which repositories you belief, how packages get promoted into your atmosphere, and what your manufacturing methods are allowed to put in at runtime.
Beneath, I define PSResourceGet finest practices for safe environments, then spotlight roadmap investments that reinforce secure-by-default package deal administration.
PSResourceGet Greatest Practices
In case you aren’t already acquainted, PSResourceGet is the trendy package deal administration answer for PowerShell, designed for:
- PowerShell modules, scripts, and DSC sources
- A number of repository sorts, together with NuGet-style feeds and OCI registries
- Specific repository belief configuration
- Enterprise eventualities the place packages are curated, mirrored, and permitted earlier than manufacturing use
A core design precept of PSResourceGet is to assist a number of repository choices so to separate package deal discovery from package deal consumption. That separation allows validation, approval, and governance gates—with out blocking package deal discovery.
In apply, the most effective outcomes come from defining a small set of repositories with clear roles (discovery vs. manufacturing), then configuring PSResourceGet belief settings to implement these boundaries.
Trusted Sources: Microsoft Artifact Registry (MAR)
For Microsoft-owned and Microsoft-published PowerShell modules, Microsoft Artifact Registry (MAR) is the trusted supply
MAR gives:
- A Microsoft-controlled publishing pipeline
- Robust provenance and possession ensures
- Operational reliability appropriate for enterprise automation
- Improved availability ensures in comparison with PowerShell Gallery
MAR is positioned because the default trusted supply for Microsoft-owned content material, eradicating ambiguity about the place Microsoft modules ought to be sourced from and decreasing reliance on neighborhood mirrors for first-party artifacts.
PSResourceGet helps OCI-compliant registries, enabling enterprises to make use of the identical infrastructure they already belief for container photographs and different artifacts.
This permits organizations to:
- Reuse current identification, RBAC, auditing, and networking controls
- Centralize PowerShell packages alongside different enterprise artifacts
- Apply constant provide chain governance throughout applied sciences
At present we solely have assist for Azure Container Registry (ACR) as a personal repository, however we’re working to undertake the .NET ORAS library which is able to allow assist via any container registry (GitHub Container registry is an thrilling one).
The PowerShell Gallery: A Group Repository
The PowerShell Gallery stays a important a part of the PowerShell ecosystem. It allows discovery, experimentation, and neighborhood collaboration. PowerShell wouldn’t be wherever near the place it’s at the moment by way of attain and recognition with out all the superb package deal contributors.
From a safety perspective, nevertheless, the PowerShell Gallery ought to be handled as:
- Untrusted by default
- Group-owned
- Unsuitable for direct manufacturing dependency
As a result of the Gallery is community-focused and doesn’t fall underneath any SLAs for availability it shouldn’t be handled as a assured, managed dependency for manufacturing workloads. We do our best to make the gallery a reliable platform (and are within the midst of many infrastructure enhancements) however for many environments, it’s not really helpful to make use of the PowerShell Gallery immediately from manufacturing methods.
As an alternative, the Gallery ought to be handled as an consumption and discovery supply, with packages promoted into trusted enterprise repositories solely after overview and approval. At Microsoft we do that via Azure Artifacts feeds and a gated central feed system.
Personal Repositories and Centralized Approval
A safe enterprise sample is to introduce a central non-public repository that acts as the one trusted supply for manufacturing methods.
This repository:
- Is absolutely managed by the enterprise
- Comprises solely vetted and permitted packages
- Gives predictable availability and efficiency
- Is explicitly configured as trusted in PSResourceGet
Azure Artifacts and personal Azure Container Registry situations are generally used for this position.
Instance Enterprise Bundle Move
- Discovery
Builders uncover packages from:- PowerShell Gallery (neighborhood)
- Microsoft Artifact Registry (Microsoft-owned)
- Trusted companions or inside groups
- Evaluation and approval
Packages are evaluated for:- Safety posture (signing, provenance, vulnerabilities)
- Licensing and compliance
- Compatibility and high quality
- Promotion to an enterprise feed
Authorised packages are:- Mirrored or re-published right into a central enterprise repository
- Model-pinned (and optionally scanned) earlier than broader rollout
- Manufacturing consumption
Manufacturing methods:- Use PSResourceGet for installs and updates
- Belief solely the enterprise repository
- Don’t rely upon exterior feeds at runtime
Limitations to this workflow
We’re within the design section of two enhancements to this workflow that we hope will make it simpler to make use of and keep. The primary is permitting cross-repository dependencies to be laid out in a psd1 and dealt with in an applicable method by PSResourceGet. The second is to permit packages which have been re-published to a central feed to have the ability to get updates from their authentic feed. Try the RFC for cross-repository dependencies right here.
Roadmap for PSResourceGet 1.3 (vNext)
PSResourceGet 1.3 continues the shift towards enterprise-friendly package deal administration: clearer belief defaults, higher assist for contemporary registries, and options that scale back friction if you scale installs throughout fleets and CI/CD.
We’re excited to announce that PSResourceGet 1.3-preview1 is out there with the next updates:
- Add MARas default registered repository
- Add concurrent (parallel) execution for Set up-PSResourceworkflows
- Add DSC V3 useful resource for PSResourceGet
First-Class DSC Useful resource Help
Earlier iterations of package deal administration relied on mechanisms resembling RequiredResourceFiles for Desired State Configuration eventualities.
The roadmap strikes towards:
- Native DSC useful resource assist
- Clear, constant dealing with of configuration artifacts
- Higher integration with trendy DSC workflows
This simplifies authoring, improves readability, and reduces special-case behaviors in package deal administration.
Microsoft Artifact Registry as a Default Repository
To cut back ambiguity and enhance belief defaults, MAR is anticipated to turn into a default repository for Microsoft-owned PowerShell packages.
This:
- Makes belief boundaries specific
- Reduces reliance on neighborhood mirrors for first-party content material
- Aligns PowerShell with broader Microsoft artifact distribution patterns
Concurrent Installs and Efficiency Enhancements
Enterprise automation typically installs a number of packages at scale.
Upcoming work focuses on:
- Supporting concurrent package deal installs
- Bettering efficiency and reliability
Decreasing friction in large-scale automation and CI/CD eventualities
ORAS Help
ORAS assist improves how PSResourceGet works with OCI registries through the use of the ORAS consumer 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 assist reduces the necessity to copy each upstream dependency into the identical feed throughout improvement. In enterprise environments, that is most helpful when paired with coverage: permit broader repository entry for dev/take a look at however prohibit manufacturing to permitted repositories solely.
Dropping Help for Home windows PowerShell
Future variations of PSResourceGet (starting with 1.3) are aligned with the broader PowerShell platform path, specializing in PowerShell (Core).
Eradicating Home windows PowerShell assist permits:
- Diminished complexity in launch and validation course of
- Help for ORAS library and different new options
- Alignment with cross-platform and cloud-native eventualities
This reinforces the expectation that trendy automation environments standardize on supported, actively developed runtimes.
Why This Issues
Collectively, these investments reinforce our path:
- PowerShell packages are a part of the enterprise provide chain
- Belief boundaries have to be specific and enforceable
- Manufacturing automation have to be deterministic and dependable
- Group innovation and enterprise governance can coexist
PSResourceGet is evolving to make secure-by-default conduct the simplest path ahead—so groups can transfer quick and maintain belief boundaries specific.
Subsequent steps: In case you handle PowerShell in an enterprise, stock which repositories your automation can attain at the moment, resolve what your single trusted manufacturing feed ought to be, and set PSResourceGet belief configuration to implement that mannequin. Then, construct a light-weight consumption course of (overview, scan, approve, promote) for something sourced from the broader neighborhood.
