This is not a big deal, as secure strings are not encrypted on Unix systems. The password will instead be obfuscated as hexadecimal representation of the string’s bytes.
According to a user on reddit, converting a string to a secure string it is basically doing this:
[BitConverter]::ToString([Text.Encoding]::Unicode.GetBytes('foo')).Replace('-','')
That this is not at all something that can be called secure, can be demonstrated in the following way:
$password = "foo"
$secureString = $password | ConvertTo-SecureString -AsPlainText -Force
$serializedSecureString = $secureString | ConvertFrom-SecureString
$byteArray = [byte[]] -split ($serializedSecureString -replace '..', '0x$& ')
$utf8 = [Text.Encoding]::UTF8
$decodedPassword = $utf8.GetString($byteArray)
Write-Host "Password: $password | Decoded Password: $decodedPassword"
On Windows this will not lead to a useful value for $decodedPassword, as Windows systems encrypt the secure string based on the profile of the current User and Host. On Linux the value for $password and $decodedPassword will be identical.
So better find another way to store your automation secrets on Linux or even better: avoid them alltogether by using certificates or managed identities if possible.