PSAvoidUsingConvertToSecureStringWithPlainText makes unreasonable claims at high severity

[et1975]

Internal MS situation:

PSAvoidUsingConvertToSecureStringWithPlainText is now generating SFI/s360 work based on unsupported claims with neither Guardian nor TSA teams able to offer repo-wide suppression options.

This will expose secure information. Encrypted standard strings should be used instead.

Will it? Why is it an error?
I challenge you to create Credential instance from a token or another credential following this guidance.

There are workarounds of course and line-by-line suppressions, but they don't scale or make security story any stronger and we can't provide our own rules/settings for the linter.

[iRon7]

My personal opinion:
Anywhere where a SecureString is used, there is apparently enough reason to hide the contents. Automatically converting from - or to plaintext will effectively devaluate the security to security through obscurity. As PowerShell scripts are mainstream, you can't lay the authentication purely in there, but need to authenticate an identity as a computer or user (account). Hence, your challenge will end up in a catch22 if you try to resolve this from your script alone. That said, Read-Host -AsSecureString (involving the user) is safe, but can't be automated. Basically, the only safe thing you can do with a SecureString is passing it on 🤔 where a simpler implementation would be to rely on the (user or computer) account that runs the script as recommended in DE0001: SecureString shouldn't be used:

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.

Anyways, I also understand the dilemma, in practice this not always easy to implement as the solution doesn't just involve scripting but the application (setup and processes) where the company might depend on for years. Therefore I recommend you to change your complain to an actual question:

• I don't think that lowering the severity is an option (as that might mean a break change for others), but
• Making the rule optional (so that you might completely disable it) would probably the request you actually as for.
  (btw, I am not the one to decide on this, but based on my recent experiences with C# rules, I think it could be quiet easily done)

Another way for you to workaround this might be to create a general Hide-String function or class (see e.g. the HiddenString idea) where you only need to suppress the concerned rule once.

[et1975]

SecureString is used, there is apparently enough reason to hide the contents.

The issue is hiding the contents is orthogonal to the question of type. The actual reason there's SecureString is because the API requires it, that's it. The content itself is no more or less secure either way and the linter (of all things) is in no position to make the claim it makes.

Again, there are workarounds, but I've opened the issue because while we all interested in bettering the security I'm also confident nobody wants a security theater. The security starts with the API vendor, not with the user of that API.