feat(secret): add built-in rules for Azure credential detection

[nikpivkin]

Summary

Add built-in secret detection rules for the most common and highest-impact Azure credential types.

Note on patterns: Exact regex patterns must be derived from real token samples before implementation. Microsoft's documentation (Purview SIT definitions) often describes outdated formats. Patterns in this issue are intentionally omitted — each rule should be validated against tokens generated from the Azure Portal.

Severity criteria

• CRITICAL — the secret grants unrestricted access with no scope limitations: full control over a resource or identity (e.g. read/write/delete everything, impersonate a service principal).
• HIGH — the secret grants access that is scoped by design (to a specific service, resource, or set of permissions), but the potential impact is still significant.

Proposed rules

CRITICAL

1. Azure Storage Account Key

Detects a bare Storage Account Key outside of a full connection string (e.g. in environment variables or config files).

• Keywords: accountkey
• Why: Grants full read/write/delete access to all blobs, queues, tables, and file shares with no scope restrictions. Also allows generating arbitrary SAS tokens, meaning a single leaked key effectively compromises all access controls on the storage account.
• Note: Microsoft Purview defines two patterns for this secret. The non-generic variant requires DefaultEndpointsProtocol as a mandatory anchor — it only matches full connection strings and misses bare keys. The generic variant has no anchor at all and relies on DLP proximity scoring to suppress false positives — a mechanism Trivy does not have. Our pattern uses AccountKey= as the anchor: broader than the non-generic (covers bare keys in env vars and config files), but precise enough without proximity scoring. Cosmos DB keys, which share the same base64 format, are handled by a separate rule anchored to .documents.azure.com / .cosmos.azure.com.
• Docs: https://learn.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage

2. Azure Cosmos DB Account Key

Detects a Cosmos DB connection string containing both the endpoint and the master key.

• Keywords: accountendpoint, accountkey
• Why: Grants full data-plane access (read, write, delete, execute stored procedures) across all databases and containers. The endpoint anchor differentiates it from generic Storage keys that share the same base64 format.
• Docs: https://learn.microsoft.com/en-us/azure/cosmos-db/secure-access-to-data

3. Azure Entra ID Client Secret

Detects an Entra ID (AAD) application client secret.

• Keywords: 8Q~
• Why: Grants access to all Azure resources the application has been granted permissions to. A leaked secret is equivalent to a stolen service identity. The 8Q~ marker at position 4–6 is unique to this token format — very high precision, low false-positive risk.
• Docs: https://learn.microsoft.com/en-us/entra/identity-platform/howto-create-service-principal-portal
• Pattern reference: https://gitlab.com/gitlab-org/security-products/secret-detection/secret-detection-rules/-/merge_requests/174

4. Azure Container Registry Credential

Detects an ACR admin or repository-scoped credential.

• Keywords: ACYeBjFEqg7NAAA, azurecr.io
• Why: Allows pulling and pushing container images to the registry. A leaked credential can be used to inject malicious images into the supply chain, with impact that extends far beyond the registry itself.
• Note: Two formats exist. The new structured format (84 characters) contains embedded service markers that make the pattern self-sufficient without surrounding context. The classic admin password format (32 characters, base64) requires azurecr.io context to avoid false positives.
• Docs: https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication

5. Azure App Configuration Connection String

Detects a connection string for an Azure App Configuration store.

• Keywords: azconfig.io
• Why: App Configuration stores often contain secrets and feature flags for production services. Access exposes the full configuration of an application. The *.azconfig.io endpoint anchor provides high precision.

HIGH

6. Azure SAS Token

Detects an Azure Shared Access Signature token URL.

• Keywords: sig=
• Why: Allows access to Azure Storage resources. Tokens can carry broad permissions and a long expiry. The sv=YYYY-MM-DD anchor is specific to Azure and eliminates most generic URL-signature false positives.
• Docs: https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview

7. Azure AI Services Key

Detects an API key for Azure AI Services (including Azure OpenAI, Computer Vision, and other Cognitive Services).

• Keywords: XJ3w3
• Why: Allows unrestricted use of deployed AI models and cognitive APIs. Leaked keys are actively exploited for financial abuse. The new structured token format (84 characters) contains embedded service markers (XJ3w3, ACOG) that uniquely identify this credential type across all Azure AI Services resources, making the pattern self-sufficient without URL context.
• Docs: https://learn.microsoft.com/en-us/azure/ai-services/openai/reference

8. Azure DevOps Personal Access Token

Detects an Azure DevOps PAT next to an ADO-specific variable name.

• Keywords: azure_devops, ado_pat, ado_token, azuredevops
• Why: Allows access to Azure DevOps organisation resources within the token's scope. A full-access PAT is equivalent to the owner's credentials within the organisation. Context anchor is mandatory — without it the base32 pattern is too broad.
• Docs: https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate

Testing

Each rule must be validated before merging:

1. True positive — generate a real credential from the Azure Portal and confirm it is detected.
2. True negative — confirm that strings with an incorrect format (wrong length, missing markers, invalid characters) are not detected.
3. No regression — run the full secret scanning test suite to confirm no existing rules are broken.

Test cases should be added to pkg/fanal/secret/scanner_test.go for each rule. Following the existing pattern (see invalid-aws-secrets.txt), a testdata file with fake/placeholder values should also be added to confirm no false positives.

Out of scope

The following Azure secret types were considered and excluded:

Rule	Reason
Azure Service Bus / Event Hub Connection String	Narrower audience — can be added in a follow-up
Azure IoT Hub Connection String	Narrower audience — can be added in a follow-up
Azure Function Key	Pattern too broad (azure context + 20–56 alphanumeric chars) — high false-positive risk without live validation
Azure Search Query Key	Read-only access; low blast radius
Azure Batch Key	Requires live API validation to avoid false positives
SQL Password	High false-positive risk
Storage Connection String	Fully covered by the bare Storage Account Key rule