Rule request: `AvoidSecureStringDisclosure`

As for AvoidUsingConvertToSecureStringWithPlainText it should be avoided to retrieve a PlainText password from a SecureString as it might leave memory trials (or even logging trails).

$Password = $SecureString | ConvertFrom-SecureString -AsPlainText

Besides, the action that follows and requires the plaintext password is likely vulnerable from a security aspect.
This will also include the common used statements as:
(see: https://stackoverflow.com/a/28353003/1701026)

$SecurePassword = ConvertTo-SecureString $PlainPassword -AsPlainText -Force
$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($SecurePassword)
$Password = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
[Runtime.InteropServices.Marshal]::ZeroFreeBSTR($BSTR)

and (see: https://stackoverflow.com/a/40166959/1701026):

$Password = (New-Object PSCredential 0, $SecurePassword).GetNetworkCredential().Password

The general approach of dealing with credentials is to avoid them and instead rely on other means to authenticate, such as certificates or Windows authentication.

Proposed technical implementation details (optional)

Create rules to check for the above mentioned unsafe statements.

Commencez par localiser les implémentations et les tests existants des règles de PSScriptAnalyzer, puis comparez leur gestion de ConvertFrom-SecureString, SecureStringToBSTR et PSCredential.GetNetworkCredential(). Le travail est terminé lorsque les modèles non sûrs de SecureString-to-plaintext sont signalés de manière fiable et que les tests correspondants de l’analyseur couvrent les exemples de l’issue.