Referencing a secure param in a regular (non-secure) param is not flagged

[anthony-c-martin]

The following scenarios should be blocked:

Scenario 1:

• main.bicep:

  @secure()
  param secureParam string
  
  param insecureParam string = secureParam

Scenario 2:

• main.bicepparam:

  using 'main.bicep'
  
  param secureParam = 'MYSECRET'
  param insecureParam = secureParam

• main.bicep:

  @secure()
  param secureParam string
  
  param insecureParam string

[jeskew]

Maybe a separate issue, but we should in general be flagging whenever a sensitive value is assigned to a non-sensitive slot or vice versa. For example, the following template raises no diagnostics but should raise two:

@secure()
param secret string

param nonSensitive string

resource e 'Microsoft.CostManagement/exports@2024-08-01' = {
  name: secret    // <-- Should flag assignment of sensitive data to non-sensitive slot
  properties: {
    definition: {
      timeframe: 'BillingMonthToDate'
      type: 'Usage'
    }
    deliveryInfo: {
      destination: {
        container: 'containerName'
        sasToken: nonSensitive   // <-- Should flag assignment of non-sensitive data to sensitive slot
      }
    }
  }
}

We should be able to do this based on existing type validation flags. I'm not sure if we accurately track "taint," though (i.e., is a variable whose value is based on a secure parameter itself be flagged as secure?).