This chapter covers software supply chain security on Azure, a critical topic for the AZ-500 exam under Security Operations (Objective 4.1). Supply chain attacks have become a top threat, and Azure provides multiple services to secure the end-to-end pipeline from code to cloud. Expect 8-12% of exam questions to touch on this area, often testing your ability to configure services like Microsoft Defender for DevOps, Azure DevOps security features, and container image signing. Master this to protect against poisoning, dependency confusion, and unauthorized code injection.
Jump to a section
Software supply chain security on Azure is analogous to an airport's baggage screening system. An airport doesn't just screen bags at the gate; it screens at multiple checkpoints: when bags are first dropped off, when they are loaded onto carts, and again before they go onto the plane. Similarly, Azure's supply chain security validates code at each stage: when a developer commits code, when a build is triggered, when a container image is pushed to a registry, and when it is deployed. Just as airport security uses X-rays, CT scanners, and sniffer dogs to detect different threats, Azure uses static analysis, dependency scanning, and runtime monitoring to detect vulnerabilities. If a bag is flagged, it is held for inspection and not loaded. In Azure, if a vulnerability is found, the pipeline can be blocked, the image can be quarantined in the registry, or the deployment can be prevented. The airport also maintains a list of known threat items (like banned liquids) — Azure uses threat intelligence feeds and vulnerability databases. Finally, baggage handlers must be vetted and authorized — similarly, Azure requires signed commits, verified identities, and role-based access to ensure only trusted actors can modify the supply chain.
What is Software Supply Chain Security?
Software supply chain security refers to the practices and tools used to ensure that every component of a software application — from source code to dependencies to build artifacts — is authentic, untampered, and free from vulnerabilities. In Azure, this spans across Azure DevOps (or GitHub), Azure Container Registry (ACR), Azure Kubernetes Service (AKS), and Microsoft Defender for Cloud. The goal is to prevent attacks like dependency confusion, where a malicious package with a similar name is uploaded to a public feed, or code injection during build.
Why It Exists
Traditional security focused on perimeter defense, but modern attacks target the software supply chain because a single compromised dependency can affect thousands of customers. For example, the SolarWinds attack inserted malicious code into a build pipeline, affecting 18,000 organizations. Azure's supply chain security features aim to provide end-to-end provenance and integrity.
How It Works Internally
Azure supply chain security operates through a combination of: - Signed commits using GPG or SSH keys to verify the identity of code contributors. - Branch protection policies in Azure Repos to require pull request reviews and status checks. - Build validation using pipeline agents that run in isolated environments. - Dependency scanning with tools like Dependabot (GitHub) or Azure DevOps dependency scanning. - Container image signing and notary integration in ACR. - Runtime threat detection via Microsoft Defender for Containers.
Key Components, Values, and Defaults
Azure DevOps: Default branch protection policy requires at least one reviewer; you can enforce up to 10 reviewers. Status checks can include build validation, which runs a pipeline before merge.
GitHub Advanced Security: Includes secret scanning, code scanning (CodeQL), and dependency review. Default secret scanning patterns for over 200 credential types.
Azure Container Registry: Supports content trust (Notary v1) to sign and verify images. Default: content trust is disabled; must be enabled per registry. Signing uses a delegation key with a default TTL of 30 days.
Microsoft Defender for Cloud: Integrates with Azure DevOps and GitHub to provide a unified view of supply chain risks. Default assessment frequency is every 12 hours for repositories.
Azure Policy: Can enforce that only signed images are deployed to AKS. Use the built-in policy "Container images should be deployed from trusted registries only".
Configuration and Verification Commands
Enable content trust in ACR (Azure CLI):
az acr config content-trust update --registry myregistry --status enabledSign a container image:
az acr signing sign --registry myregistry --image myimage:tagVerify a signed image:
az acr repository show --name myregistry --image myimage:tag --query 'signature'Create a branch policy in Azure DevOps (REST API):
# Using Azure DevOps CLI
ez repos policy create build-validation --branch main --build-definition-id 1 --manual-queue-only false --display-name "Require build"Enable Dependabot on GitHub:
# Via GitHub UI or API. No CLI command; enable in repository settings > Security & analysisInteraction with Related Technologies
Azure DevOps + Defender for Cloud: Defender for Cloud can ingest alerts from Azure DevOps pipelines, such as exposed secrets or vulnerable dependencies, and correlate them with other cloud security signals.
ACR + AKS: AKS can be configured to only pull images from ACR with content trust enabled. Use the --enable-image-cleaner flag to automatically delete untagged images older than a threshold (default 30 days).
GitHub Actions + Azure: GitHub Actions can publish to ACR and sign images using the azure/container-actions actions. The docker/login-action authenticates to ACR.
Azure Policy + AKS: Use Azure Policy to enforce that only images signed by a specific key are allowed to run. The policy evaluates the notary metadata.
Detailed Step-by-Step: Securing a Build Pipeline
Commit Signing: Developers sign commits with GPG. Azure Repos verifies the signature against a public key stored in the user profile. Unsigned commits can be rejected via branch policy.
Pull Request Validation: When a PR is created, a pipeline runs to build the code, run unit tests, and scan dependencies. The pipeline agent runs in a container with minimal permissions.
Dependency Scanning: The pipeline invokes a task (e.g., DependencyCheck or WhiteSource) to scan package.json, pom.xml, etc. Vulnerabilities are reported as pipeline annotations.
Container Image Build and Sign: After successful validation, the pipeline builds a container image and pushes it to ACR. A separate step signs the image using the az acr signing sign command. The signing key is stored in Azure Key Vault.
Deployment Gate: AKS deployment uses a webhook or Azure Policy to verify the image signature. If the signature is missing or invalid, the pod is not scheduled.
Runtime Monitoring: Microsoft Defender for Containers monitors running containers for anomalous behavior, such as unexpected network connections or privilege escalation.
Common Pitfalls and Edge Cases
Dependency confusion: Attackers upload a package with the same name as a private package to a public feed. Mitigation: use upstream sources and scope feeds to your organization.
Timing attacks: An attacker could exploit a delay between scanning and deployment. Use immutable tags and enforce signature verification at runtime.
Key compromise: If a signing key is stolen, an attacker can sign malicious images. Use hardware security modules (HSM) in Key Vault and rotate keys regularly.
Pipeline secrets exposure: Secrets like PAT tokens can be leaked in build logs. Use Azure DevOps secret variables and GitHub encrypted secrets.
Exam-Relevant Numbers and Defaults
Content trust in ACR: disabled by default; must be enabled per registry.
Default image retention policy in ACR: untagged images deleted after 30 days (configurable).
GitHub secret scanning: scans for over 200 credential patterns.
Defender for Cloud's supply chain assessment: runs every 12 hours for connected repositories.
Azure DevOps branch policy: minimum number of reviewers defaults to 1, but can be set up to 10.
ACR signing key TTL: 30 days for delegation keys.
Verification Commands (Exam Must-Know)
# Check content trust status
az acr config content-trust show --registry myregistry
# List signed images
az acr repository list --registry myregistry --query "[?signature != null].name"
# Show policy assignments
az policy assignment list --query "[?displayName=='Container images should be deployed from trusted registries only']"Enable Content Trust in ACR
Content trust in Azure Container Registry (ACR) uses Docker's Notary to sign and verify images. When enabled, the registry requires images to be signed before they can be pushed. The signing process creates a trust collection with root and delegation keys. By default, content trust is disabled. To enable it, use `az acr config content-trust update --registry myregistry --status enabled`. Once enabled, any image push without a valid signature will be rejected. The signing key is stored in the registry and can be backed up to Azure Key Vault. This prevents unauthorized images from being stored.
Sign a Container Image
After building an image, sign it using `az acr signing sign --registry myregistry --image myimage:tag`. This command uses the registry's signing key (stored in Key Vault) to create a signature manifest. The signature is stored as a separate layer in the registry. The image digest is used to ensure integrity. If the image is modified after signing, the signature becomes invalid. The signing process also timestamps the signature, providing a record of when it was signed. The default signature TTL is 30 days, after which the signature must be renewed.
Verify Image Signature Before Deployment
Before deploying a signed image to AKS, verify its signature using `az acr repository show --name myregistry --image myimage:tag --query 'signature'`. This returns the signature metadata, including the issuer and expiry. In AKS, you can enforce signature verification using Azure Policy or Open Policy Agent (OPA). For example, a Gatekeeper constraint can check that every pod uses an image with a valid signature from a trusted signer. If the signature is missing or expired, the pod creation is denied. This ensures only authorized images run in the cluster.
Configure Branch Protection Policies
In Azure Repos, branch protection policies enforce workflows like requiring a minimum number of reviewers (default 1, max 10), checking for linked work items, and running build validation. To set up, navigate to Project Settings > Repositories > Policies. For the main branch, enable 'Require a minimum number of reviewers' and set it to 2. Also enable 'Check for linked work items' and 'Build validation' to run a pipeline on every PR. These policies prevent direct commits and ensure code is reviewed and tested before merging, reducing the risk of malicious code injection.
Enable Dependency Scanning with Dependabot
Dependabot is a GitHub-native tool that automatically scans repositories for vulnerable dependencies. It checks for known CVEs in package manifests (e.g., package.json, requirements.txt) and creates pull requests to update them. To enable, go to repository Settings > Security & analysis and enable 'Dependabot alerts' and 'Dependabot security updates'. Dependabot runs daily by default and supports over 12 ecosystems. Alerts are aggregated in the Security tab. For Azure DevOps, use the 'Dependency Scanning' task from the marketplace, which integrates with WhiteSource or Snyk.
Enterprise Scenario 1: Financial Services Company Securing Container Deployments
A large bank uses AKS to run microservices. They need to ensure that only approved images from their internal ACR are deployed. They enable content trust on ACR and require all images to be signed by a key stored in Azure Key Vault with HSM-backed keys. Their CI/CD pipeline in Azure DevOps signs each image after a successful build and vulnerability scan. They use Azure Policy with a custom policy to enforce that any pod in AKS must have an image with a valid signature. Misconfiguration: initially, they forgot to enable content trust on the registry, so unsigned images were allowed. This was caught during a security audit. They also set the signing key TTL to 90 days, but a key rotation policy was missing, causing expired signatures to block deployments. They now rotate keys every 30 days and use automated alerts for expiring signatures.
Enterprise Scenario 2: SaaS Provider Preventing Dependency Confusion
A SaaS company uses both private and public NuGet packages. An attacker uploaded a package with the same name as their private package to nuget.org. To prevent this, they use Azure Artifacts with upstream sources configured to only allow approved public feeds. They also enable Dependabot on their GitHub repositories to scan for vulnerable dependencies. They set branch protection policies requiring at least two reviewers and a successful build. The build pipeline includes a task that runs dotnet list package --vulnerable to fail the build if any vulnerable package is found. A common issue was that developers bypassed the pipeline by pushing directly to the main branch; they fixed this by disabling direct pushes via branch policy.
Scenario 3: E-commerce Platform Using GitHub Advanced Security
An e-commerce platform uses GitHub for source control and GitHub Actions for CI/CD. They enable secret scanning to prevent credentials from being committed. They also use code scanning with CodeQL to find vulnerabilities in their Python code. Their supply chain security includes a dependency review action that blocks PRs if a new dependency has a known vulnerability. They also use Azure Container Registry with content trust for their Docker images. Performance consideration: scanning large monorepos can take over an hour; they optimized by using matrix builds and caching. A misconfiguration: they forgot to enable secret scanning on all repositories, and a developer accidentally committed an Azure Storage account key, which was then exposed in a public fork. They now enforce secret scanning via organization-level policy.
What AZ-500 Tests on This Topic
The AZ-500 exam focuses on Objective 4.1: "Configure and manage security for software supply chain." Specifically, you must know:
How to enable content trust in ACR and sign images.
How to configure branch protection policies in Azure DevOps.
How to integrate Microsoft Defender for Cloud with Azure DevOps and GitHub for supply chain visibility.
How to use Azure Policy to enforce trusted image deployment.
How to set up dependency scanning with Dependabot or Azure DevOps tasks.
Most Common Wrong Answers and Why
"Content trust is enabled by default in ACR." – Wrong. It is disabled by default. Candidates assume it's on because of security posture. Reality: you must explicitly enable it.
"Branch protection policies can be bypassed by pipeline service accounts." – Wrong. Service accounts can be exempted, but by default they are subject to policies. Candidates think pipelines must bypass policies to work.
"Dependabot only scans for known vulnerabilities in GitHub." – Wrong. Dependabot also creates PRs to update dependencies. Candidates confuse scanning with updating.
"Azure Policy can enforce image signing but not signature verification." – Wrong. Azure Policy can enforce both, but signature verification is typically done via Gatekeeper/OPA. Candidates think policy only checks registry.
Specific Numbers and Terms Appearing on the Exam
Content trust: enabled/disabled per registry.
Signing key TTL: 30 days (default).
Minimum reviewers: 1 (default), max 10.
Defender for Cloud assessment frequency: every 12 hours.
GitHub secret scanning: over 200 patterns.
ACR image retention: untagged images deleted after 30 days (configurable).
Edge Cases and Exceptions
Multi-registry scenario: If you use multiple ACRs, content trust must be enabled on each.
Cross-tenant access: When pulling images from another tenant's ACR, content trust verification may fail if the signing key is not shared.
Base images: If a signed image uses an unsigned base image, the signature is still valid for the top-level image, but the base image is not verified. Exam may test that content trust does not recursively verify base images.
Pipeline variables: Secrets in pipeline variables are masked in logs, but can be exposed if echoed. Use Azure Key Vault for secrets.
How to Eliminate Wrong Answers
If an answer says "automatically" or "by default" for a security feature, check if it's actually opt-in. Most Azure security features are opt-in.
For policy questions, remember that Azure Policy evaluates at deployment time, not at build time. If the question mentions preventing a build, it's likely a branch policy or pipeline gate, not Azure Policy.
For signing questions, know that signing requires a key, and key management is separate (Key Vault). Don't confuse signing with encryption.
Content trust in ACR is disabled by default; enable it with `az acr config content-trust update --registry <name> --status enabled`.
Sign images using `az acr signing sign --registry <name> --image <image:tag>`; requires Key Vault for key storage.
Branch protection policies in Azure DevOps require a minimum of 1 reviewer by default (max 10).
Dependabot scans for vulnerabilities daily and creates PRs for updates; supports over 12 ecosystems.
Microsoft Defender for Cloud assesses repository security every 12 hours when connected to Azure DevOps or GitHub.
Azure Policy can enforce that only images from trusted registries or with valid signatures are deployed to AKS.
Signing key TTL defaults to 30 days; rotate keys regularly to avoid expired signatures blocking deployments.
Dependency confusion attacks can be mitigated by using upstream sources and scoping feeds in Azure Artifacts.
These come up on the exam all the time. Here's how to tell them apart.
Azure DevOps Branch Policies
Requires minimum number of reviewers (1-10).
Can require a successful build (CI pipeline).
Can enforce linked work items.
Integrates with Azure Policy for additional checks.
Managed via Azure DevOps REST API or CLI.
GitHub Branch Protection Rules
Requires pull request reviews (1 or more).
Can require status checks (e.g., CI, CodeQL).
Can enforce conversation resolution.
Integrates with GitHub Apps for custom checks.
Managed via GitHub API or web interface.
ACR Content Trust (Notary v1)
Signs images at the registry level.
Requires a signing key stored in Key Vault.
Default TTL for delegation keys is 30 days.
Only verifies the image digest and signature.
Must be enabled per registry.
Azure Policy for Image Verification
Enforces policies at the AKS cluster level.
Can check image registry, tag, or signature.
Policies are evaluated at deployment time.
Can block pods with unsigned or untrusted images.
Applies to all subscriptions or resource groups.
Mistake
Content trust in ACR automatically signs all images.
Correct
Content trust only requires images to be signed; it does not automatically sign them. You must explicitly sign images using `az acr signing sign` or a pipeline step.
Mistake
Branch protection policies in Azure DevOps prevent all direct commits.
Correct
Branch policies only apply to specified branches (e.g., main). Other branches can still have direct commits. Also, users with 'Bypass policies when completing pull requests' permission can bypass.
Mistake
Dependabot can scan for vulnerabilities in private packages.
Correct
Dependabot scans only public packages from known ecosystems. It cannot access private package feeds unless explicitly configured with credentials.
Mistake
Azure Policy can block a build pipeline from running.
Correct
Azure Policy evaluates resources at deployment time, not during CI/CD. To block a build, use branch policies or pipeline conditions, not Azure Policy.
Mistake
Signing an image guarantees the image is free of vulnerabilities.
Correct
Signing only verifies the integrity and origin of the image. It does not perform vulnerability scanning. A signed image can still contain vulnerabilities.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use the Azure CLI command `az acr config content-trust update --registry myregistry --status enabled`. This enables Docker Content Trust (Notary v1) on the registry. After enabling, any image push without a valid signature will be rejected. You must also sign images using `az acr signing sign`. The signing key is stored in the registry and can be backed up to Azure Key Vault. Note: content trust is disabled by default.
Branch policies (in Azure DevOps or GitHub) control what happens before code is merged, such as requiring reviews and successful builds. Azure Policy controls what resources are allowed at deployment time, such as ensuring only signed images run in AKS. Branch policies prevent malicious code from entering the repository; Azure Policy prevents untrusted images from running. Both are needed for end-to-end security.
Dependabot scans GitHub repositories for vulnerable dependencies by checking package manifests (e.g., package.json, requirements.txt, pom.xml). It supports over 12 ecosystems including npm, pip, Maven, NuGet, and Docker. It runs daily and creates pull requests to update vulnerable packages to the latest secure version. To enable, go to repository Settings > Security & analysis.
Yes, you can use Azure Policy with the built-in policy 'Container images should be deployed from trusted registries only' or create a custom policy. However, Azure Policy cannot directly verify image signatures; it checks the registry and tag. For signature verification, you need to use Open Policy Agent (OPA) with Gatekeeper or a custom admission controller webhook. Azure Policy can enforce that only images from a specific ACR are used.
If the signing key (delegation key) expires, the image signature becomes invalid. The image will still exist in ACR, but any attempt to verify the signature will fail. In AKS, if you have a policy that requires valid signatures, the pod will not be scheduled. To avoid this, rotate keys before expiry (default TTL 30 days) and re-sign images with the new key. Use Azure Key Vault to manage key lifecycle.
Use Azure Artifacts with upstream sources configured to only allow approved public feeds. Scope feeds to your organization (e.g., @mycompany). In your package manager configuration, set the registry to your private feed first. Additionally, use Dependabot to monitor for malicious packages. For NuGet, use the `nuget.config` file to specify package sources. Always use fully qualified package names.
Microsoft Defender for Cloud integrates with Azure DevOps and GitHub to provide a unified view of supply chain risks. It can scan repositories for exposed secrets, vulnerable dependencies, and misconfigured pipeline permissions. It also correlates these findings with other cloud security alerts. The assessment runs every 12 hours. You can enable this in Defender for Cloud's Environment Settings.
You've just covered Software Supply Chain Security on Azure — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?