Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
PowerShell has several features designed to improve the security of your scripting environment.
Execution policy
PowerShell's execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts. This feature helps prevent the execution of malicious scripts. You can use a Group Policy setting to set execution policies for computers and users. Execution policies only apply to the Windows platform.
For more information see about_Execution_Policies.
Use of the SecureString class
PowerShell has several cmdlets that support the use of the System.Security.SecureString class.
And, as with any .NET class, you can use SecureString in your own scripts. However, Microsoft
doesn't recommend using SecureString for new development. Microsoft recommends that you avoid
using passwords and rely on other means to authenticate, such as certificates or Windows
authentication.
PowerShell continues to support the SecureString class for backward compatibility. Using a SecureString is still more secure than using a plain text string. By default, PowerShell doesn't show the unprotected value of a SecureString object. However, SecureString can be easily converted to a plain text string. For a full discussion about using SecureString, see the System.Security.SecureString class documentation.
Module and script block logging
Module Logging allows you to enable logging for selected PowerShell modules. This setting is effective in all sessions on the computer. PowerShell records pipeline execution events for the specified modules in the Windows PowerShell log in Event Viewer.
Script Block Logging enables logging for the processing of commands, script blocks, functions, and scripts - whether invoked interactively, or through automation. PowerShell logs this information to the Microsoft-Windows-PowerShell/Operational event log.
For more information, see the following articles:
AMSI Support
The Windows Antimalware Scan Interface (AMSI) is an API that allows applications to pass actions to an antimalware scanner, such as Windows Defender, to scan for malicious payloads. Beginning with PowerShell 5.1, PowerShell running on Windows 10 (and higher) passes all script blocks to AMSI.
PowerShell 7.3 extends the data that's sent to AMSI for inspection. It now includes all invocations of .NET method members.
For more information about AMSI, see How AMSI helps.
Constrained language mode
ConstrainedLanguage mode protects your system by limiting the cmdlets and .NET types allowed in a PowerShell session. For a full description, see about_Language_Modes.
Application Control
Windows 10 includes two technologies, App Control for Business and AppLocker that you can use to control applications. PowerShell detects if a system wide application control policy is being enforced. The policy applies certain behaviors when running script blocks, script files, or loading module files to prevent arbitrary code execution on the system.
App Control for Business is designed as a security feature under the servicing criteria defined by the Microsoft Security Response Center (MSRC). App Control is the preferred application control system for Windows.
For more information about how PowerShell supports AppLocker and App Control, see Use App Control to secure PowerShell.
Software Bill of Materials (SBOM)
Beginning with PowerShell 7.2, all install packages contain a Software Bill of Materials (SBOM). The PowerShell team also produces SBOMs for modules that they own but ship independently from PowerShell.
You can find SBOM files in the following locations:
- In PowerShell, find the SBOM at
$PSHOME/_manifest/spdx_2.2/manifest.spdx.json. - For modules, find the SBOM in the module's folder under
_manifest/spdx_2.2/manifest.spdx.json.
The creation and publishing of the SBOM is the first step to modernize Federal Government cybersecurity and enhance software supply chain security. For more information about this initiative, see the blog post Generating SBOMs with SPDX at Microsoft.
Security Servicing Criteria
PowerShell follows the Microsoft Security Servicing Criteria for Windows. Only security features meet the criteria for servicing.
Security features
- System Lockdown with App Control for Business
- Constrained language mode with App Control for Business
Defense in depth features
- System Lockdown with AppLocker
- Constrained language mode with AppLocker
- Execution Policy
Collaborate with us on GitHub
The source for this content can be found on GitHub, where you can also create and review issues and pull requests. For more information, see our contributor guide.
