Skip to content

Deployment parameter contains a secret that is not secured#

Security · Deployment · Rule · 2025_06 · Critical

Sensitive parameters that have been not been marked as secure may leak the secret into deployment history or logs.

Description#

This rule detects cases when a sensitive value is passed to a parameter that is not marked as secure. For example, you used listKeys to get a storage account key and then passed the value to a parameter of a child module. The parameter on the child module is not marked as secure, so the value has been leaked by the child deployment.

Azure Bicep and Azure Resource Manager (ARM) templates can be used to deploy resources to Azure. When deploying Azure resources, sensitive values such as passwords, certificates, and keys should be passed as secure parameters. Secure parameters use the @secure decorator in Bicep or the secureString / secureObject type.

Parameters that do not use secure types are recorded in deployment history and logs. These values can be retrieved by anyone with read access to the deployment history and logs.

Secret rotation — SE:09 Application secrets

If a secret has already been exposed by a previous insecure deployment, rotate it immediately to prevent unauthorized access to your resources.

Rotating a secret involves changing or regenerating the secret value and updating all dependent resources with the new value. This process should be done in a secure manner to prevent the new secret from being exposed.

Don't treat non-secrets like secrets — SE:09 Application secrets

Secrets require operational rigor that's unnecessary for non-secrets. This might result in additional resource management overhead and operational costs, such as:

  • Increased Key Vault transaction costs.
  • Security Information and Event Management (SIEM) integration and regular auditing and monitoring of secret usage.
  • Management overhead additional complexity to regularly rotate secrets.

Recommendation#

Consider using secure parameters for any parameter that contain sensitive information.

Examples#

Configure with Azure template#

To configure deployments that pass this rule:

  • Set the type of sensitive parameters to secureString or secureObject.

For example:

Azure Template snippet
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "secret": {
      "type": "secureString"
    }
  },
  "resources": [
    {
      "type": "Microsoft.KeyVault/vaults/secrets",
      "apiVersion": "2022-07-01",
      "name": "keyvault/good",
      "properties": {
        "value": "[parameters('secret')]"
      }
    }
  ]
}

Configure with Bicep#

To configure deployments that pass this rule:

  • Add the @secure() decorators on sensitive parameters.

For example:

Azure Bicep snippet
@secure()
param secret string

resource goodSecret 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
  parent: vault
  name: 'good'
  properties: {
    value: secret
  }
}

Notes#

Sensitive values detected include:

  • Key Vault secret references.
  • The output of a list* function such as listKeys.

Comments