Sensitive information in automation is any value or detail that could help an unauthorized party gain access, target an attack, or misuse the permissions available to a script. Obvious examples include passwords, secrets, API keys, SSH keys, private certificates, certificate thumbprints, PGP keys, and RSA tokens. Less obvious details—such as connection strings, usernames, internal FTP addresses, and public keys—can also reveal useful pieces of an environment. section 4.0 section 4.1.1
Never place sensitive information directly in a script. A copied script, public repository, lost device, or unsecured email can expose plain-text values; hard-coded usernames also reduce portability and increase maintenance work. Treat convenience and time pressure as risks to address with a secure store rather than reasons to defer protection. section 4.1.1
Choose protection based on how the automation runs:
- For interactive automation, prompt for passwords, run under the user's context, or use privileged access management and delegated permissions. section 4.1.3
- For unattended automation, arrange secure access to required values while preventing others from accessing them. section 4.1.3
- Avoid passwords when an execution identity can authenticate instead, such as a scheduled job running under a Windows domain account or a local system context on the SQL server. section 4.1.3
SQL health check automation
A SQL health check can alert when a recovery model is incorrect. Rather than embed database credentials, it can use Windows domain authorization and run through a job scheduler under an authorized account; running locally on the SQL server under system context is another option when appropriate. section 4.0 section 4.1.3
Obscuring a value is not securing it. Encoded values in scripts can be reversed quickly and become unsecured variables when decoded in memory; compiled executables and DLLs can also be decompiled. Use protections for data at rest and during execution, alongside role-based access and least privilege. section 4.1.6 section 4.6
PowerShell can use SecureString and PSCredential objects to protect sensitive values during execution and at rest. For reusable secure retrieval, SecretManagement can connect scripts to multiple password vaults; automation and CI/CD platforms may also provide built-in vaults, including Jenkins. section 4.4 section 4.6
