Quality and trust of PowerShell Gallery content have been a concern since the beginning. These issues were somewhat addressed with peer-monitoring via the Report Abuse and Contact Support links on each module details page. We even implemented a new cmdlet, Save-Module, which allowed users to assess a module’s contents before installing it. However, all these scenarios put the onus on the consumer to determine if a module is safe and of high quality.
To improve further, we have begun checking that all modules on the Gallery meet a basic quality bar.
Starting June 26, 2015, all modules in the Gallery are being scanned and assessed against defined safety and quality best practices.
The scan performs the following:
1. Installs the module by using PowerShellGet.
2. Runs an antivirus scan by using System Center Endpoint Protection.
3. Runs the module through PowerShell Script Analyzer. We apply the following error-level rules from the newest PowerShell Script Analyzer module in the PowerShell Gallery:
Rule Name | Description |
PSAvoidUsingUserNameAndPassWordParams | Functions should only take in a credential parameter of type PSCredential instead of username and password parameters. |
PSAvoidUsingComputerNameHardcoded | The ComputerName parameter of a cmdlet should not be hardcoded as this will expose sensitive information about the system. |
PSAvoidUsingConvertToSecureStringWithPlainText | Using ConvertTo-SecureString with plain text will expose secure information. |
PSDSCUseIdenticalMandatoryParametersForDsc | The Get/Test/Set TargetResource functions of DSC resource must have the same mandatory parameters. |
PSDSCUseIdenticalParametersForDSC | The Test and Set-TargetResource functions of DSC Resource must have the same parameters. |
PSDSCStandardDSCFunctionsInResource | DSC Resource must implement Get, Set and Test-TargetResource functions. DSC Class must implement Get, Set and Test functions. |
A module is flagged as noncompliant if the module cannot be installed for any reason, or if PowerShell Script Analyzer returns error-level results or parse errors. Owners of noncompliant modules will receive emails containing the results of the scan, and asking them to unlist the module, resolve the issues, and republish.
A module fails compliance with high priority if the module contains anything that could damage or compromise a user’s computer (such as viruses, malicious software or code, etc.). High-priority noncompliant modules are manually unlisted, and deleted after two weeks, if the issue cannot be resolved with the module owner.
PowerShell Script Analyzer is new and evolving. As a result, there are very few rules we will require to pass, while we take comments on both the tool and on this process. If you would like to provide feedback to PowerShell Script Analyzer, please visit their GitHub website: https://github.com/PowerShell/PSScriptAnalyzer .If you are planning to publish a new module, you should run it through PowerShell Script Analyzer yourself. You can download the module from the PowerShell Gallery using Install-Module PSScriptAnalyzer.
Our main goal is to help consumers of the Gallery content know that the modules on the Gallery have passed basic tests, so that they feel more comfortable downloading them. In the future, we intend to publish the results of the scans we run on the Module page, so that consumers of the module will know what to expect when they run Script Analyzer on the items they acquire.
After today’s announcement, we expect contributors to rise to the challenge and meet, if not exceed, this quality bar. This security scan is the first step in shaping the PowerShell Gallery to contain high quality and trusted modules that all users will feel confident using.
As always, we are open to your comments and feedback.
Thanks,
Rebecca Roenitz [MSFT]
PowerShell Gallery Team