Study guide
14.4 Software Supply Chain, Container Scanning & Cloud Defender
Microsoft Certified: Azure DevOps Engineer Expert AZ-400
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Flow of Work, Traceability & Work Tracking
1.1 Flow of Work, GitHub Flow & Feedback Cycles 1.2 Work Tracking with Azure Boards & GitHub Projects 1.3 End-to-End DevOps Traceability & Quality Tracking
2 Chapter 2: DevOps Metrics, Dashboards & Team Collaboration
2.1 DORA Metrics, Flow Metrics & Dashboard Design 2.2 Lifecycle Metrics Across the Six DevOps Phases 2.3 Work Item Queries, WIQL Charts & Analytics 2.4 Project Documentation: Wikis, Mermaid Diagrams & Release Notes 2.5 Webhooks, Service Hooks & Microsoft Teams ChatOps
3 Chapter 3: Git Branching Strategies & Pull Request Workflows
3.1 Git Branching Models & Strategy Design 3.2 Pull Request Workflows & Merge Strategies 3.3 Branch Policies, Quality Gates & Compliance Restrictions
4 Chapter 4: Repository Management, Optimization & Git Data Operations
4.1 Git LFS Architecture & .gitattributes Tracking 4.2 LFS History Migration, git-fat & File Locking 4.3 Git Repository Scaling, Scalar & Monorepo Governance 4.4 Repository Permissions & Git Tag Governance 4.5 Git Data Recovery & Sensitive-Data Scrubbing
5 Chapter 5: Package Management & Dependency Versioning
5.1 Selecting Package Tools: Azure Artifacts vs. GitHub Packages 5.2 Feed Scoping, Upstream Sources & Pipeline Authentication 5.3 Package Views, Immutability & Quality Promotion 5.4 Dependency Versioning: SemVer, CalVer & Automated Versioning 5.5 Pipeline Artifact Versioning & Artifact Storage Strategy
6 Chapter 6: Pipeline Infrastructure, Agents & Integration
6.1 Selecting a CI/CD Solution: Azure Pipelines vs. GitHub Actions 6.2 GitHub-Azure Pipelines Integration & Hybrid Migration 6.3 Hosted vs. Self-Hosted Agents & Runners 6.4 VMSS Elastic Pools, Container Jobs & Agent Governance 6.5 Pipeline Triggers, Filters & Concurrency Management
7 Chapter 7: YAML Pipeline Architecture & Reusable Elements
7.1 YAML Pipeline Anatomy: Stages, Jobs, Steps & Workspaces 7.2 Job Execution Order: DAG Dependencies, Parallelism & Conditions 7.3 Reusable Elements: Templates, Parameters & Variables 7.4 Variable Groups, Secret Variables & Key Vault Linking 7.5 YAML Environments, Checks & Deployment Approvals
8 Chapter 8: Testing Strategy, Quality Gates & Code Coverage
8.1 Test Strategy Design: Local, Unit & Integration Testing 8.2 Load, Stress & Performance Testing in Pipelines 8.3 Test Execution Tasks, Agents & Results Integration 8.4 Code Coverage Analysis & SonarQube Integration 8.5 Quality Gates, Release Gates & Governance Checks
9 Chapter 9: Modern Deployment Strategies & Zero-Downtime Delivery
9.1 Progressive Delivery: Blue-Green, Canary & Ring Deployments 9.2 Minimizing Downtime: Deployment Slots & Rolling Updates 9.3 Feature Flags with Azure App Configuration & Feature Manager 9.4 Designing the High-Priority Hotfix Path 9.5 Ordered Dependency Deployments, Resiliency & Rollback
10 Chapter 10: Artifact Deployment & Database DevOps
10.1 Containerized Application Delivery: ACR, AKS & Container Apps 10.2 Binary, Web App, Function & Scripted Deployments 10.3 Database DevOps: State-Based & Migration-Based Strategies
11 Chapter 11: Infrastructure as Code (IaC) & Azure Deployment Environments
11.1 Infrastructure as Code Strategy: Bicep, ARM & Terraform 11.2 Desired State Configuration & Azure Machine Configuration 11.3 Azure Deployment Environments (ADE) & Developer Self-Service
12 Chapter 12: Pipeline Maintenance, Health & Modernization
12.1 Pipeline Health, Flaky Tests & Reliability Engineering 12.2 Pipeline Optimization: Caching, Slicing & Concurrency 12.3 Artifact & Build Retention Governance 12.4 Modernizing CI/CD: Classic to YAML Migration
13 Chapter 13: Authentication, Authorization & Identity Governance
13.1 Microsoft Entra Service Principals & Managed Identities 13.2 Service Connections, Workload Identity & Personal Access Tokens 13.3 Azure DevOps Projects, Teams & Permission Evaluation 13.4 Access Levels, GitHub Roles & Outside Collaborators
14 Chapter 14: Secrets Management, Sensitive Data & DevSecOps Scanning
14.1 Azure Key Vault, Secret Variables & Secretless CI/CD 14.2 Security Scanning Strategy, GHAS & Secret Scanning 14.3 CodeQL SAST in Pipelines and Containers 14.4 Software Supply Chain, Container Scanning & Cloud Defender
15 Chapter 15: Telemetry Collection, Azure Monitor & Alerting
15.1 Azure Monitor Architecture, AMA & Data Collection Rules 15.2 Application Insights & Specialized Azure Monitor Insights 15.3 Alerting Rules, Action Groups & GitHub Repository Insights
16 Chapter 16: Telemetry Analysis, Distributed Tracing & SRE Practices
16.1 Distributed Tracing, Application Map & Exception Triage 16.2 KQL Log Analytics, SRE Observability & Error Budgets
14.4 Software Supply Chain, Container Scanning & Cloud Defender
Key Takeaways Explain This Topic AI
Software supply chain security mandates maintaining an auditable Software Bill of Materials (SBOM) using standards like SPDX generated via SbomTool@1.
Dependabot provides continuous Software Composition Analysis (SCA), automatically dispatching alerts and opening automated pull requests with patched library versions.
Microsoft Defender for Containers performs automated vulnerability assessments of container images in Azure Container Registry (ACR) upon push and continuous rescanning.
Azure Policy for Kubernetes enforces container security gates at runtime by blocking the deployment of images with Critical or High severity CVEs to AKS clusters.
Microsoft Defender for Cloud DevOps Security bridges code-to-cloud security posture, mapping discovered code and pipeline vulnerabilities to runtime cloud resources.
Last updated: September 2026
14.4 Software Supply Chain, Container Scanning & Cloud Defender
Modern cloud-native applications rarely consist entirely of proprietary code. Industry studies show that 80% to 90% of code in modern enterprise applications comes from third-party open-source libraries, frameworks, and base container images. While open-source ecosystems dramatically accelerate development velocity, they introduce severe software supply chain vulnerabilities—such as the widespread Log4Shell exploit, typosquatting attacks, and compromised package repositories.
On the AZ-400 exam, candidates must demonstrate the ability to govern the entire software supply chain. This encompasses generating standard Software Bill of Materials (SBOM) manifests, automating dependency vulnerability remediation with Dependabot , securing containerized workloads in Azure Container Registry (ACR) , and unifying pipeline-to-runtime posture with Microsoft Defender for Cloud DevOps Security .
1. Software Supply Chain Security & SBOM Generation
A Software Supply Chain encompasses everything that touches an application before it reaches production: third-party dependencies, build infrastructure, package managers, base container images, and deployment scripts. Compromising any single link in this chain allows adversaries to inject malicious code into trusted downstream production systems. Traditional Vulnerability Vector: Direct Code Injection
Attacker ──> [Attacks Enterprise App] ──> Blocked by Firewalls / WAF
- Software Supply Chain Attack Vector: Indirect Transitive Dependency
- Attacker ──> [Compromises Open-Source Package on npm/NuGet]
- │
- ▼
- [Legitimate Update Pushed to Registry]
- │
- ▼
- [CI Pipeline Restores Package via npm install]
- │
- ▼
- [Enterprise Builds & Signs Contaminated Binary]
- │
- ▼
- [Production Deploy: Full Enterprise Compromise]
- The Software Bill of Materials (SBOM)
A Software Bill of Materials (SBOM) is a formalized, machine-readable inventory of all components, libraries, transitive dependencies, metadata, and licensing details that comprise a software build artifact. Governed by global cybersecurity standards (such as US Executive Order 14028), enterprise DevOps pipelines must generate an SBOM for every release build.
Industry SBOM Standards
SPDX (Software Package Data Exchange - ISO/IEC 5962:2021) : The international standard format for communicating software package components, licenses, copyrights, and cryptographic hashes. Microsoft's tooling natively outputs SPDX 2.2 JSON manifests.
CycloneDX : A lightweight, application-security-focused SBOM standard developed by the OWASP foundation, popular for container and software bill of materials analysis.
Generating an SBOM in Azure Pipelines via SbomTool@1
Microsoft provides the open-source Salus SBOM generation tool integrated as the SbomTool@1 task in Azure Pipelines. It automatically inspects build output directories, detects package dependencies (NuGet, npm, Maven, PyPI), generates an SPDX 2.2 compliant manifest.spdx.json , and signs the manifest: # Generating and Publishing an SPDX SBOM in Azure Pipelines
- task: DotNetCoreCLI@2
- displayName: 'Build and Publish Web API'
inputs:
- command: 'publish'
- publishWebProjects: true
- arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory)/app'
- task: SbomTool@1
- displayName: 'Generate Software Bill of Materials (SPDX)'
inputs:
- # Root directory of compiled artifacts to catalog
- buildDropPath: '$(Build.ArtifactStagingDirectory)/app'
- # Root source code repository path
- buildComponentPath: '$(Build.SourcesDirectory)'
- packageVersion: '$(Build.BuildNumber)'
- packageName: 'ContosoPaymentService'
- packageSupplier: 'Contoso Enterprise DevOps'
- # Manifest output folder
- manifestDirPath: '$(Build.ArtifactStagingDirectory)/app/_manifest'
- task: PublishPipelineArtifact@1
- displayName: 'Publish Build Drop with SBOM Manifest'
inputs:
- targetPath: '$(Build.ArtifactStagingDirectory)/app'
- artifact: 'ProductionDrop'
- publishLocation: 'pipeline'
- 2. Dependabot: Dependency Vulnerability & Version Management
Open-source components frequently contain known security vulnerabilities cataloged in the GitHub Advisory Database (with mapped CVE and GHSA identifiers). Dependabot provides automated Software Composition Analysis (SCA) directly within GitHub and Azure DevOps. ┌────────────────────────────────────────────────────────────────────────┐
- │ Dependabot Core Operational Modes │
- ├───────────────────────────────────┬────────────────────────────────────┤
- │ Dependabot Alerts │ Dependabot Security Updates │
- ├───────────────────────────────────┼────────────────────────────────────┤
- │ • Scans package manifests │ • Automatically generates a PR │
- │ • Notifies developers of CVEs │ • Updates to minimum secure patch │
- │ • Non-intrusive security triage │ • Runs CI tests against patch PR │
- ├───────────────────────────────────┼────────────────────────────────────┤
- │ Dependabot Version Updates │ Dependabot Grouped Updates │
- ├───────────────────────────────────┼────────────────────────────────────┤
- │ • Scheduled maintenance PRs │ • Consolidates multiple package │
- │ • Keeps libraries on latest release│ updates into a single PR │
- │ • Governed via dependabot.yml │ • Reduces developer PR fatigue │
- └───────────────────────────────────┴────────────────────────────────────┘
- Dependabot Alerts vs. Dependabot Security Updates
Dependabot Alerts : Continuously monitors dependency manifests ( package.json , pom.xml , requirements.txt , Directory.Packages.props ). When a library matches a new CVE, Dependabot creates a security alert with CVSS severity scoring and remediation advice. Alerts do not modify code.
Dependabot Security Updates : When an alert is detected, Dependabot automatically opens a Pull Request that modifies the project's dependency manifest to bump the vulnerable library to the minimum version required to patch the flaw. It does not perform breaking major version upgrades, minimizing regression risk.
Configuring Dependabot Version Updates ( dependabot.yml )
While security updates trigger reactively on CVE discovery, Dependabot version updates run on a proactive schedule to prevent technical debt. Configured via .github/dependabot.yml : # .github/dependabot.yml: Multi-Ecosystem Version Maintenance
version: 2
updates:
- # Maintain npm frontend dependencies
- package-ecosystem: "npm"
- directory: "/src/frontend"
schedule:
- interval: "weekly"
- day: "monday"
- time: "04:00"
- timezone: "America/New_York"
- open-pull-requests-limit: 10
reviewers:
- "frontend-leads"
labels:
- "dependencies"
- "javascript"
- # Group patch updates to reduce PR noise
groups:
minor-and-patch:
patterns:
- "*"
update-types:
- "patch"
- "minor"
- # Maintain NuGet backend dependencies
- package-ecosystem: "nuget"
- directory: "/src/backend"
schedule:
- interval: "daily"
- open-pull-requests-limit: 5
commit-message:
- prefix: "build(deps)"
- include: "scope"
- 3. Container Vulnerability Scanning in Azure Container Registry (ACR)
Deploying microservices to container runtimes like Azure Kubernetes Service (AKS) or Azure Container Apps introduces another supply chain layer: the container image itself. If a base operating system image contains vulnerable system packages (e.g., outdated glibc or openssl ), the containerized microservice can be compromised regardless of how secure the application code is. Pipeline: docker build ──> docker push ──> [Azure Container Registry (ACR)]
- │
- 1. Push Trigger Scan
- │
- ▼
- [Defender for Containers]
- (Vulnerability Assessment)
- │
- ▼
- [Security Findings & CVEs]
- (Critical, High, Med, Low)
- │
- ▼
- [Azure Policy Kubernetes Gate]
- │
- ┌────────────────────────┴────────────────────────┐
- ▼ ▼
- [Compliant Image (No High CVE)] [Vulnerable Image (High CVE)]
- │ │
- ▼ ▼
- [Allowed: Deployed to AKS] [Blocked: Rejected by Admission Webhook]
- Microsoft Defender for Containers & ACR Scanning Architecture
Continuous Registry Scanning : When enabled on an Azure subscription, Microsoft Defender for Containers automatically scans Linux container images pushed to Azure Container Registry (ACR).
Scan Triggers :
On-Push : The image is scanned immediately upon being pushed to ACR ( docker push or CI pipeline task).
Continuous Re-Scanning : Any image that has been pulled from the registry within the last 30 days is rescanned continuously whenever new vulnerabilities are published to global CVE databases.
Scanning Engine : Powered by industry-standard vulnerability assessment engines (Qualys and Trivy combined with Microsoft Threat Intelligence), evaluating OS packages (Debian, Ubuntu, Alpine, Red Hat) and language application packages.
Automated Deployment Quality Gates via Azure Policy
To prevent developers or deployment pipelines from launching non-compliant images into production AKS clusters, teams implement Azure Policy for Kubernetes (backed by OPA Gatekeeper):
Built-in Policy Initiative : Ensure vulnerable container images are not deployed to AKS clusters .
Mechanism : The Kubernetes Admission Controller queries Defender for Cloud vulnerability assessments for the container image digest before admitting the pod. If the image contains unpatched Critical or High CVEs exceeding organization thresholds, the admission controller rejects the deployment request .
4. Microsoft Defender for Cloud DevOps Security
In complex enterprise environments, security teams frequently struggle with fragmented visibility: development teams manage code in GitHub and Azure DevOps, while cloud operations teams monitor virtual machines, databases, and AKS clusters in the Azure portal.
Microsoft Defender for Cloud DevOps Security establishes a unified Code-to-Cloud security posture management (CSPM) solution. ┌────────────────────────────────────────────────────────────────────────┐
- │ Microsoft Defender for Cloud: DevOps Security Architecture │
- ├────────────────────────────────────────────────────────────────────────┤
- │ Connectors: │
- │ • Azure DevOps Organizations │
- │ • GitHub Enterprise Cloud / GitHub Organizations │
- ├────────────────────────────────────────────────────────────────────────┤
- │ Unified Capabilities: │
- │ │
- │ 1. Code-to-Cloud Contextual Traceability: │
- │ Runtime Alert (AKS Pod Exploit) ──► Maps to Container Image Digest │
- │ ──► Maps to ACR Repository ──► Maps to GitHub/ADO Commit & PR │
- │ ──► Identifies exact developer who introduced vulnerable dependency │
- │ │
- │ 2. Infrastructure as Code (IaC) Security: │
- │ Scans Bicep, ARM, and Terraform files in PRs against CIS Benchmarks │
- │ │
- │ 3. Centralized DevOps Security Posture: │
- │ Aggregates Secret Scanning, CodeQL SAST, and Dependabot findings │
- │ into the global Azure Secure Score │
- └────────────────────────────────────────────────────────────────────────┘
- Code-to-Cloud Contextual Traceability
A major topic on the AZ-400 exam is contextual correlation:
When Defender for Cloud detects a live intrusion attempt or compromised pod on an Azure Kubernetes Service cluster, DevOps Security correlates the runtime resource back to the specific build pipeline run, the exact Git commit SHA, and the developer pull request that introduced the vulnerability.
This drastically compresses Mean Time to Remediate (MTTR) from weeks to minutes by delivering remediation guidance directly to the responsible engineering team.
Infrastructure as Code (IaC) Posture Scanning
Defender DevOps Security inspects declarative Infrastructure as Code templates (Azure Resource Manager templates, Bicep, Terraform) during CI builds and PR reviews to detect misconfigurations before deployment:
Storage accounts configured with public access enabled.
Kubernetes clusters with role-based access control (RBAC) disabled.
Network security groups with overly permissive ingress rules ( 0.0.0.0/0 on port 22 or 3389).
5. Comprehensive YAML Pipeline: SBOM Generation, Container Build & Security Scan
The following complete Azure Pipelines YAML demonstrates an enterprise software supply chain workflow: compiling a .NET microservice, generating an SPDX 2.2 SBOM, building a Docker container image, pushing to ACR, and awaiting vulnerability assessment: # azure-pipelines.yml: Secure Supply Chain Build, SBOM, and Container Deployment
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
variables:
- acrServiceConnection: 'ACR-Production-ServiceConnection'
- acrRegistryName: 'acrcontosoprod.azurecr.io'
- imageRepository: 'payment-service'
- tag: '$(Build.BuildId)'
jobs:
- job: SupplyChainBuildAndScan
- displayName: 'Build, Catalog SBOM, and Publish Container'
steps:
- checkout: self
- # 1. Restore and Compile Microservice
- task: DotNetCoreCLI@2
- displayName: 'Compile Payment Application'
inputs:
- command: 'publish'
- publishWebProjects: true
- arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory)/publish'
- # 2. Generate SPDX 2.2 Software Bill of Materials (SBOM)
- task: SbomTool@1
- displayName: 'Generate Software Bill of Materials (SPDX)'
inputs:
- buildDropPath: '$(Build.ArtifactStagingDirectory)/publish'
- buildComponentPath: '$(Build.SourcesDirectory)'
- packageVersion: '$(Build.BuildId)'
- packageName: 'PaymentService'
- packageSupplier: 'Contoso Enterprise DevOps'
- manifestDirPath: '$(Build.ArtifactStagingDirectory)/publish/_manifest'
- # 3. Publish SBOM Drop as Pipeline Artifact
- task: PublishPipelineArtifact@1
- displayName: 'Publish Build Artifacts and SBOM'
inputs:
- targetPath: '$(Build.ArtifactStagingDirectory)/publish'
- artifact: 'DropWithSBOM'
- publishLocation: 'pipeline'
- # 4. Build Docker Container Image
- task: Docker@2
- displayName: 'Build Docker Image'
inputs:
- command: 'build'
- repository: '$(imageRepository)'
- dockerfile: '**/Dockerfile'
- buildContext: '$(Build.ArtifactStagingDirectory)/publish'
- tags: |
- $(tag)
- latest
- # 5. Push Image to Azure Container Registry (Triggers Defender Scan)
- task: Docker@2
- displayName: 'Push Container Image to ACR'
inputs:
- containerRegistry: '$(acrServiceConnection)'
- repository: '$(imageRepository)'
- command: 'push'
- tags: |
- $(tag)
- latest
- # 6. Verify Registry Vulnerability Compliance
- script: |
- echo "Image pushed to $(acrRegistryName)/$(imageRepository):$(tag)"
- echo "Microsoft Defender for Containers scan initiated automatically on ACR push."
- displayName: 'Audit Image Supply Chain Attestation'
- 6. Supply Chain & Cloud Security Defense Matrix
Tool / Feature Scope & Target Execution Location Primary Vulnerabilities Addressed Enforcement Action
SbomTool@1 (Salus) Direct & transitive build components CI Build Agent step Supply chain compliance (SPDX 2.2), component inventory Produces audited manifest.spdx.json drop artifact
Dependabot Alerts Open-source package manifests GitHub / Azure DevOps backend Known CVEs in third-party libraries (npm, NuGet, PyPI) Surfaces security alerts with CVSS severity ranking
Dependabot Security Updates Open-source package manifests GitHub / Azure DevOps backend Unpatched dependency CVEs Automatically opens PR to bump library to patched version
Defender for Containers Container images in ACR Azure Container Registry service OS and language package CVEs inside container images Vulnerability assessment reports; rescans images pulled in last 30d
Azure Policy for Kubernetes Running AKS clusters Kubernetes Admission Controller (Gatekeeper) Non-compliant or high-CVE container images Rejects Pod deployment requests at the API server boundary
Defender DevOps Security Repositories, pipelines, and cloud Multi-cloud & DevOps portals IaC misconfigurations, CodeQL findings, Code-to-Cloud posture Centralizes posture into Azure Secure Score; traces runtime CVEs to code
- 7. Realistic Exam Scenario & Common Traps
- Scenario: Regulated Banking Supply Chain Compliance Pipeline
Organization : First National Bank maintains a hybrid banking platform. Under new federal regulatory guidelines, the bank must provide a verifiable Software Bill of Materials (SBOM) for every production release, automate third-party dependency patch management without developer overhead, and guarantee that no container image with unpatched Critical CVEs is admitted to production AKS clusters.
DevOps Strategy Implemented :
SBOM Generation : The bank inserts the SbomTool@1 task into all Azure Pipelines build workflows. Every build outputs an SPDX 2.2 manifest.spdx.json uploaded to pipeline artifacts.
Automated Remediation : Dependabot security updates are enabled across all Git repositories. When a vulnerability in a logging library is published to the GitHub Advisory Database, Dependabot creates a pull request bumping the version, triggering automated unit and integration tests.
Registry Assessment : All container images are pushed to a Premium tier Azure Container Registry protected by Microsoft Defender for Containers, which immediately performs vulnerability scanning.
Runtime Gate Enforcement : An Azure Policy definition ( Ensure vulnerable container images are not deployed to AKS clusters ) is assigned to the production AKS cluster with the deny effect. When Helm attempts to roll out a release referencing an image with an unpatched Critical OpenSSL vulnerability, the Kubernetes admission controller rejects the rollout, preventing contaminated containers from executing.
Common Exam Traps to Avoid
Trap: Conflating Dependabot Version Updates with Dependabot Security Updates. Version updates update dependencies on a calendar schedule ( dependabot.yml ) to keep libraries current, even if no vulnerability exists. Security updates trigger reactively upon the publication of a known CVE to patch security flaws.
Trap: Believing SBOM Generation Tools Fix Vulnerabilities. The SbomTool@1 task generates a catalog and manifest of software components (SPDX). It does not evaluate CVE severity, rewrite package manifests, or upgrade libraries. Remediation is handled by Dependabot or manual developer intervention.
Trap: Assuming Container Scanning Occurs During docker build on the Agent. Microsoft Defender for Containers does not execute inside the build agent VM during docker build . The image must be pushed to Azure Container Registry (ACR) , where Defender's registry scanner inspects the image layers.
Trap: Overlooking Continuous Re-scanning Window. Defender for Containers does not scan an image once and abandon it. It continuously rescans any container image that has been pulled from ACR within the past 30 days , alerting teams if a zero-day CVE is discovered in an image deployed weeks prior.