Compliance & Secret Management
AZ-400 path: Implement security and validate code bases for compliance — compliance enforcement, signing, and credential hygiene.
Overview
Pulls together the validated-compliance side of the path: secret scanning to keep credentials out of repositories, compliance gates that block shipping on violations, and code signing to guarantee artifact authenticity/integrity. It also connects to moving secrets to a secure store (Key Vault).
Learning objectives
- Detect and remediate hardcoded secrets in code and git history (revoke + rotate).
- Configure compliance gates that fail the build/release on security policy violations.
- Explain code signing (Authenticode / Azure Trusted Signing) for artifact authenticity & integrity.
- Route secrets to a secret store instead of the repo.
Units
- Secret scanning (working tree + history) & remediation (revoke/rotate)
- Compliance / quality gates on security & policy findings
- Code signing: public/private key, CA trust, Azure Trusted Signing
- Storing secrets in Azure Key Vault & variables (secure-CID overlap)
Concepts introduced
Key terms & commands
secret scanning · revoke & rotate · compliance gate · Authenticode · Azure Trusted Signing · private/public key · Key Vault
Hands-on
⚠ verify — add an exercise enabling secret scanning (history + PR), triaging a leaked token (rotate + remove from history), and adding a signing certificate.
Exam focus
- On a secret finding: revoke/rotate — never assume deletion is enough (git history persists) → also scan history, not just HEAD.
- Compliance gate = automated, policy-driven, blocks the build/release on violations (vulns, licenses, secrets, coverage).
- Code signing = authenticity (who) + integrity (tamper-proof): private signs, public verifies, trust via CA; Windows Authenticode; managed Azure Trusted Signing.
Related
Path MOC · shift-left-security · static-and-dynamic-analysis · dependency-scanning · Secure-CD path