PowerShell 7.5

Use these rules for PowerShell 7.5 scripts, modules, automation hosts, and remote administration. Treat every external string, object, file, environment value, module, remote result, and command target as untrusted until its authority and structure are established.

Establish the code-execution boundary

• Treat FullLanguage PowerShell as arbitrary native-code execution: loaded code can call .NET, COM, providers, native programs, and the operating system with the process identity's full authority.
• On Windows, enforce trusted code with App Control for Business so PowerShell enters System Lockdown mode. Do not treat a manually assigned ConstrainedLanguage mode, AppLocker alone, AMSI, or execution policy as a security boundary.
• On Windows, keep execution policy enabled as defense in depth, but never use pwsh -ExecutionPolicy Bypass, Set-ExecutionPolicy Bypass, or automatic Unblock-File calls to make unreviewed code run.
• Authenticode-sign released scripts and modules on Windows and verify Get-AuthenticodeSignature status and the expected publisher before execution. A valid signature proves identity and integrity, not that the code is safe or authorized.
• Start unattended jobs with pwsh -NoProfile -NonInteractive -File <fixed-path> and a controlled working directory. Do not let user profiles, current-directory files, or interactive prompts alter privileged automation.

Bind and validate data before use

• Use advanced functions with [CmdletBinding()], named parameters, narrow types such as [int], [guid], [uri], and [datetimeoffset], and