azure-cicd-security

Standard IDs

ID	Severity	What it checks
CICD-001	P0	Long-lived service-principal secret used instead of OIDC federated credentials
CICD-002	P1	No environment protection rules/approval gate on a production deployment
CICD-003	P1	Deployment identity granted broader roles than the resources it actually touches
CICD-004	P1	Secret referenced directly in workflow YAML instead of via GitHub encrypted secrets

---

Check A — Long-lived secret instead of OIDC federation (CICD-001)

Detection

Grep .github/workflows/*.yml for azure/login@v* using creds:/client-secret: inputs sourced from a stored secret, instead of client-id/tenant-id/subscription-id with no secret at all (OIDC federated credential trust between GitHub and Entra ID). A long-lived service-principal secret sitting in GitHub Secrets is a standing credential that doesn't expire on its own and is a high-value target if the repo or an action dependency is compromised.

BAD — long-lived client secret

- uses: azure/login@v2
  with:
    creds: ${{ secrets.AZURE_CREDENTIALS }} # a JSON blob containing a client secret that never rotates automatically

GOOD — OIDC federated credential, no stored secret

permissions:
  id-token: write # required for OIDC
  contents: read

- uses: azure/login@v2
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    # No client-secret — GitHub's OIDC token is exchanged for a short-lived Azure token per run.

---

Check B — No environment protection/approval gate (CICD-002)

Detection

Check whether the production deployment job targets a GitHub environment: with protection rules (required reviewers, wait timer) configured, versus deploying to production on every push to main with no human gate.

BAD — production deploy fires automatically, no approval