Managing Secrets in Source Code

VA policy and software development best practices do not provide for the storing of plain-text credentials and secrets in source code under any circumstance. This includes, but is not limited to, usernames, passwords, API keys, and other authentication tokens. This policy applies to all VA repositories, including public, internal, and private repositories.

All secrets should be secured using an enterprise vault application such as Azure Key Vault, AWS Secrets Manager, or HashiCorp Vault. Secrets should be injected into applications at runtime using a secrets management tool.

Developers should refer to the Veteran Affairs OIT Secrets Management Enterprise Design Pattern for guidance on how to implement secrets management in their applications.

What is considered a secret

Secrets are any credentials or authentication tokens that can be used to access a system or service. This includes, but is not limited to, usernames, passwords, API keys, and other authentication tokens. Secrets should never be stored in plain-text in source code.

Secrets used in tests

Secrets used for testing purposes should be secured just as production secrets are secured in a vault application. If a secret grants access to a system or service, it should be secured, regardless of whether it is used in production or testing, or whether it contains real or test data.

A compromised secret to a non-production system still has the potential to be used to gain access to VA-owned resources.

Secret Scanning

The VA uses GitHub’s secret scanning feature to scan all repositories for secrets. If a secret is detected, the repository owner will be notified via the Security tab in the repository settings. Once a secret has been identified by secret scanning, it is no longer considered secret. The only acceptable course of action is to rotate the secret to ensure that the secret is no longer valid. Any secret exposed in plain-text in a repository should be considered compromised and should be rotated immediately.

Secret Scanning supported types

GitHub partners closely with third-party companies to provide secret scanning for a variety of secret types. The types of secrets that are scanned are determined by these third parties and not GitHub. As such, any secret identified by secret scanning should be considered compromised and should be rotated immediately.

If a secret has been flagged, this is because the vendor has deemed it should be treated as a secret and the only acceptable course of action is to rotate the secret.

You can find a list of all supported secret types in the GitHub Secret Scanning documentation.

Exceptions

There are no exceptions to this policy. All secrets must be secured using an enterprise vault application. This includes types such as “AWS Access Key ID” and other username-like credential types, as compromising username-like credentials limits the effort an attacker must take to compromise an account.