PowerShell & Scripting

PSScriptAnalyzer

Allgemeine Infos

PSScriptAnalyzer ist ein statischer Code-Checker für PowerShell-Module und -Skripte. Er wendet Regeln auf Basis von PowerShell-Best-Practices an und meldet potenzielle Fehler, unsichere Muster wie Klartext-Passwörter und Stilverstöße wie Aliase oder nicht genehmigte Verben, ohne den Code auszuführen. Aktuell ist Version 1.25.0 vom 20. März 2026, sie läuft ab Windows PowerShell 5.1 und unter PowerShell 7 auf Windows, Linux und macOS.

Die PowerShell Gallery analysiert jedes veröffentlichte Paket mit PSScriptAnalyzer und meldet Fehler an den Herausgeber, Microsoft verlangt die Behebung von Fehlern vor der Veröffentlichung. Die PowerShell-Erweiterung für Visual Studio Code nutzt PSScriptAnalyzer für die Codeanalyse direkt im Editor. Microsoft bietet für das Modul nur eingeschränkten Support, Fehler meldest Du im GitHub-Repository.

Abgrenzung: Pester testet das Verhalten von Code zur Laufzeit, PSScriptAnalyzer untersucht den Quelltext statisch, beide ergänzen sich in einer Build-Pipeline. PowerShell-Skriptsignierung und Execution Policy regeln, welcher Code ausgeführt werden darf, über seine Qualität sagen sie nichts aus.

Funktionsweise & Details

PSScriptAnalyzer lässt jede aktive Regel über den geparsten Code laufen und gibt pro Fund einen Diagnosedatensatz mit Regelname, Schweregrad, Datei und Zeile aus. Der Ablauf:

  1. Installation: Install-Module -Name PSScriptAnalyzer oder Install-PSResource aus der PowerShell Gallery.
  2. Analyse: Invoke-ScriptAnalyzer -Path .\Projekt -Recurse untersucht alle Dateien, -Severity filtert nach Error oder Warning. Get-ScriptAnalyzerRule listet die verfügbaren Regeln. Parserfehler erscheinen seit Version 1.18.0 als eigene Funde vom Typ ParseError.
  3. Konfiguration: Eine Datei PSScriptAnalyzerSettings.psd1 im Projektstamm wird automatisch erkannt, alternativ übergibst Du sie mit -Settings. Darin steuern IncludeRules, ExcludeRules und Severity die Auswahl. Mitgelieferte Presets sind PSGallery, DSC und CodeFormatting.
  4. Ausnahmen: Mit dem Attribut [Diagnostics.CodeAnalysis.SuppressMessageAttribute()] und einer Justification unterdrückst Du eine Regel gezielt für eine Funktion, einen Parameter oder eine Klasse.
  5. Korrektur: -Fix wendet vorgeschlagene Korrekturen automatisch an, Invoke-Formatter formatiert Code nach Regeln. Eigene Regeln bindest Du über CustomRulePath ein.

Kompatibilitätsregeln wie PSUseCompatibleCmdlets, PSUseCompatibleCommands und PSUseCompatibleSyntax melden Befehle und Syntax, die auf einer Ziel-PowerShell-Version fehlen.

Vorteile & Nutzen

  • Fehler vor dem Rollout: Klartext-Passwörter (PSAvoidUsingPlainTextForPassword, PSAvoidUsingConvertToSecureStringWithPlainText) fallen auf, bevor ein Skript mit Admin-Rechten produktiv läuft
  • Einheitlicher Stil: Regeln wie PSAvoidUsingCmdletAliases und PSUseApprovedVerbs halten Skripte im Team lesbar und wartbar
  • Automatisierbar: Als Schritt in einer Build-Pipeline stoppt die Analyse den Build bei Fehlern, Code-Reviews konzentrieren sich auf die Logik
  • Gallery-Tauglichkeit: Das Preset PSGallery zeigt vorab, was die Gallery beim Upload bemängeln würde
  • Versionssicherheit: Kompatibilitätsregeln melden Befehle, die unter Windows PowerShell 5.1 oder einer anderen Zielversion nicht existieren

Praxisbeispiel

Das vierköpfige IT-Team eines Klinikverbunds pflegt rund 150 PowerShell-Skripte in einem Git-Repository, darunter Skripte mit Admin-Rechten für Active Directory und Exchange. Vor jeder Zusammenführung läuft in der Pipeline Invoke-ScriptAnalyzer mit einer gemeinsamen Settings-Datei, Funde mit Schweregrad Error brechen den Build ab. Beim ersten Lauf findet das Team mehrere Skripte mit fest hinterlegten Passwörtern und stellt sie auf SecretManagement um. Seitdem gelangen solche Funde nicht mehr in den Hauptzweig.

Worauf sollte man achten?

  • Die Settings-Datei ins Repository legen und in VS Code über powershell.scriptAnalysis.settingsPath einbinden, damit Editor und Pipeline dieselben Regeln nutzen
  • Unterdrückungen immer mit Justification versehen, sonst weiß später niemand, warum eine Regel abgeschaltet wurde
  • -Fix nur auf Code unter Versionskontrolle anwenden: Manche Korrekturen erfordern Folgeänderungen, und die Dateikodierung bleibt nicht immer erhalten
  • PSScriptAnalyzer ersetzt keine Tests, Logikfehler findest Du erst mit Pester
  • Parserfehler lassen sich nicht per Attribut unterdrücken, sie zeigen echte Syntaxprobleme und gehören behoben

Lizenz & Verfügbarkeit

PSScriptAnalyzer ist kostenlos und wird über die PowerShell Gallery verteilt, Quellcode und Lizenzdatei liegen auf GitHub (PowerShell/PSScriptAnalyzer). Microsoft leistet für das Modul nur eingeschränkten Support über das GitHub-Repository. Stand: Oktober 2026.

Fazit

PSScriptAnalyzer gehört in jede PowerShell-Codebasis, die über einzelne Einzeiler hinausgeht. Binde es mit einer gemeinsamen Settings-Datei in Editor und Pipeline ein und ergänze es um Pester-Tests.

Weiterführende Links

Verwandte Artikel