Edit

Detect exposed secrets in code

  • Article
  • 3 minutes to read

When passwords and other secrets are stored in source code, it poses a significant risk and could compromise the security of your environments. Defender for Cloud offers a solution by using secret scanning to detect credentials, secrets, certificates, and other sensitive content in your source code and your build output. Secret scanning can be run as part of the Microsoft Security DevOps for Azure DevOps extension. To explore the options available for secret scanning in GitHub, learn more about secret scanning in GitHub.

Note

During the Defender for DevOps preview period, GitHub Advanced Security for Azure DevOps (GHAS for AzDO) is also providing a free trial of secret scanning.

Check the list of supported file types, exit codes and rules and descriptions.

Prerequisites

Setup secret scanning in Azure DevOps

You can run secret scanning as part of the Azure DevOps build process by using the Microsoft Security DevOps (MSDO) Azure DevOps extension.

To add secret scanning to Azure DevOps build process:

  1. Sign in to Azure DevOps

  2. Navigate to Pipeline.

  3. Locate the pipeline with MSDO Azure DevOps Extension is configured.

  4. Select Edit.

  5. Add the following lines to the YAML file

    inputs:
    categories: 'secrets'

  6. Select Save.

By adding the additions to your yaml file, you'll ensure that secret scanning only runs when you execute a build to your Azure DevOps pipeline.

Remediate secrets findings

When credentials are discovered in your code, you can remove them. Instead you can use an alternative method that won't expose the secrets directly in your source code. Some of the best practices that exist to handle this type of situation include:

  • Eliminating the use of credentials (if possible).

  • Using secret storage such as Azure Key Vault (AKV).

  • Updating your authentication methods to take advantage of managed identities (MSI) via Azure Active Directory (AAD).

Remediate secrets findings using Azure Key Vault

  1. Create a key vault using PowerShell.

  2. Add any necessary secrets for your application to your Key Vault.

  3. Update your application to connect to Key Vault using managed identity with one of the following:

Once you have remediated findings, you can review the Best practices for using Azure Key Vault.

Remediate secrets findings using managed identities

Before you can remediate secrets findings using managed identities, you need to ensure that the Azure resource you're authenticating to in your code supports managed identities. You can check the full list of Azure services that can use managed identities to access other services.

If your Azure service is listed, you can manage your identities for Azure resources.

Suppress false positives

When the scanner runs, it may detect credentials that are false positives. Inline-suppression tools can be used to suppress false positives.

Some reasons to suppress false positives include:

  • Fake or mocked credentials in the test files. These credentials can't access resources.

  • Placeholder strings. For example, placeholder strings may be used to initialize a variable, which is then populated using a secret store such as AKV.

  • External library or SDKs that 's directly consumed. For example, openssl.

  • Hard-coded credentials for an ephemeral test resource that only exists for the lifetime of the test being run.

  • Self-signed certificates that are used locally and not used as a root. For example, they may be used when running localhost to allow HTTPS.

  • Source-controlled documentation with non-functional credential for illustration purposes only

  • Invalid results. The output isn't a credential or a secret.

You may want to suppress fake secrets in unit tests or mock paths, or inaccurate results. We don't recommend using suppression to suppress test credentials. Test credentials can still pose a security risk and should be securely stored.

Note

Valid inline suppression syntax depends on the language, data format and CredScan version you are using.

Credentials that are used for test resources and environments shouldn't be suppressed. They're being used to demonstration purposes only and don't affect anything else.

Suppress a same line secret

To suppress a secret that is found on the same line, add the following code as a comment at the end of the line that has the secret:

#[SuppressMessage("Microsoft.Security", "CS001:SecretInLine", Justification="... .")]

Suppress a secret in the next line

To suppress the secret found in the next line, add the following code as a comment before the line that has the secret:

#[SuppressMessage("Microsoft.Security", "CS002:SecretInNextLine", Justification="... .")]

Next steps