You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add topic about best practices for writing secure code #10099
Existing Issue: Search the existing issues for this repository. If there is an issue that fits your needs do not file a new one. Subscribe, react, or comment on that issue instead.
Descriptive Title: Write the title for this issue as a short synopsis. If possible, provide context. For example, "Document new Get-Foo cmdlet" instead of "New cmdlet."
PowerShell Version
7.4
Summary
We have two scenarios:
Writing secure code in general
2. Don't rely on auto-loading
3. Import the modules you use or use module qualified invocation
I think the useful gap is practical secure PowerShell authoring guidance rather than duplicating the existing PowerShell security features, application control, and script-injection documentation.
I’ve drafted an outline covering:
trusted dependencies and predictable command resolution
input validation
avoiding dynamic code execution
credentials and secret handling
least privilege
execution policy, application control and Constrained Language Mode
external files and commands
explicit failure handling and safe logging
code signing
dependency review and static analysis
I’d propose placing it under PowerShell > Security, alongside the existing security guidance.
If that scope and location make sense, I’m happy to submit an initial article as a PR.
Activity
sdwheeler commentedon May 26, 2023
Travis Plunk (@TravisEz13) Do you have a draft you can share?
sdwheeler commentedon Jun 2, 2023
We have some existing documentation:
DOC: Add topic about best practices for writing secure PowerShell code (
rakeshranderia commentedon Sep 16, 2026
I’d be interested in taking this issue on.
I think the useful gap is practical secure PowerShell authoring guidance rather than duplicating the existing PowerShell security features, application control, and script-injection documentation.
I’ve drafted an outline covering:
I’d propose placing it under PowerShell > Security, alongside the existing security guidance.
If that scope and location make sense, I’m happy to submit an initial article as a PR.