AZ-400 Security & Validate for Compliance

Implement security and validate code bases for compliance (DevSecOps)

6-security-compliance-moc

Implement Security & Validate Code for Compliance — MOC

MS Learn path: Implement security and validate code bases for compliance · Shift-left security: find issues before they ship.

Map / Canvas

The core idea

Security is embedded throughout the pipeline (DevSecOps / shift-left), not bolted on at release. Code is validated for compliance with automated analysis layered by what it inspects:

All findings are enforced by a compliance gate that blocks shipping on violations — making compliance continuous and demonstrated, not audited at the end.

Modules in this path

Concepts (linked from here)

DevSecOps · SAST · DAST · Dependency vuln scanning · SCA · Code signing · Compliance gate · Secret scanning

Skills measured (exam blueprint)

  • Implement security and validate code bases for compliance (DevSecOps, SAST/DAST, dependency & secret scanning, code signing, quality gates).
  • Integrate defense against code-vulnerability classes and supply-chain risks into pipelines.

Practice

⚠ verify — add practice questions on SAST vs DAST vs SCA, gate behavior, and secret-remediation (revoke/rotate).

Practice questions

shift-left-security

Shift-Left Security (DevSecOps)

AZ-400 path: Implement security and validate code bases for compliance — start here.

Overview

Introduces the DevSecOps mindset: embedding security into the earliest stages of the DevOps lifecycle instead of treating it as a release-time gate. Sets up the “validate code for compliance” theme of this path: automation, shift-left, and continuous compliance.

Learning objectives

  • Explain how DevSecOps embeds security throughout the pipeline (shift-left).
  • Identify the security checks that belong in commit/build vs release.
  • Understand how continuous, automated security replaces manual, end-of-delivery review.

Units

  • What is DevSecOps / why shift-left
  • Security tooling in the CI/CD pipeline (automated scans)
  • Culture & process: shared responsibility, security as code
  • Mapping checks to pipeline stages (SAST at PR/build, DAST at deploy, SCA & secrets everywhere)

Concepts introduced

Key terms & commands

Shift-left · security as code · SAST vs DAST vs SCA · gate · DevSecOps · “fail fast”

Hands-on

⚠ verify — add an exercise placing a simple scan (coverage or lint) at the build and observing it block a bad commit.

Exam focus

  • DevSecOps mantra: shift-left, security embedded & automated, not a final review.
  • Distinguish SAST (source, no execution) vs DAST (running app) vs SCA (components/licenses) vs secret scanning (credentials).
  • Compliance is enforced by automated gates in the pipeline, not manual audit.

Path MOC · static-and-dynamic-analysis · dependency-scanning · compliance-and-secret-management

static-and-dynamic-analysis

Static and Dynamic Analysis (SAST & DAST)

AZ-400 path: Implement security and validate code bases for compliance — “Validate code” module.

Overview

Covers the two classical code-level security testing techniques used to validate code in CI/CD: static analysis (SAST) that inspects source without executing, and dynamic analysis (DAST) that tests the running application. Both output findings that drive a compliance gate.

Learning objectives

  • Distinguish SAST (source inspection, no runtime) from DAST (runtime, black-box).
  • Choose the right tool/technique for a given vulnerability class.
  • Wire analysis results into a build/release gate so critical findings block shipping.

Units

  • What is static analysis (SAST) & what it catches
  • What is dynamic analysis (DAST) & runtime-only flaws
  • CI vs runtime placement (SAST at PR/build; DAST against deployed app)
  • Turning findings into a quality/compliance gate

Concepts introduced

Key terms & commands

SAST · DAST · white-box vs black-box · CodeQL · SonarQube · OWASP ZAP · gate · code coverage

Hands-on

⚠ verify — add an exercise running a SAST tool (e.g. Pylint/Sonar) as a PR check and a gate that fails on critical findings.

Exam focus

  • Memorize pairing: SAST = static/source/no-execution · DAST = dynamic/black-box/running app.
  • Both feed an automated compliance gate; culprits: SAST→code-level, DAST→runtime/config/endpoint, SCA→dependencies/licenses (next module).
  • Understand placement: SAST early (commit/PR), DAST where there’s a runnable env (test/staging).

Path MOC · shift-left-security · dependency-scanning · compliance-and-secret-management

dependency-scanning

Dependency Scanning (SCA & Supply Chain)

AZ-400 path: Implement security and validate code bases for compliance — “Manage dependencies / open-source governance” module.

Overview

Covers software composition analysis (SCA) and dependencies vulnerability management: inventorying the open-source components an app consumes, checking them for known CVEs/advisories, enforcing license policy, and automating remediation (e.g. Dependabot PRs) — all feeding the release.

Learning objectives

  • Explain why third-party/transitive dependencies are a security surface.
  • Identify how SCA, vulnerability scanning, and license governance differ.
  • Use dependency-scanning output as a release gate (critical vuln / banned license → block).
  • Automate fix pull-requests (Dependabot) and pair with Azure Artifacts dropping/upstream.

Units

  • The software-supply-chain risk & transitive dependencies
  • Vulnerability scanning (CVE/advisories) vs SCA (inventory + licenses)
  • Tools: Dependabot (GitHub), Open Source / artifact scanning, OWASP Dependency-Check
  • Gating releases on dependency & license findings

Concepts introduced

Key terms & commands

SCA · CVE · advisory · transitive dependency · SBOM / bill of materials · Dependabot · lockfile · gate

Hands-on

⚠ verify — add an exercise enabling Dependabot/vulnerability scanning, reviewing a flagged package, and setting the release gate.

Exam focus

  • SCA = components + licenses + inventory vs vulnerability scanning = patch state vs SAST = your code — three-way distinction.
  • Transitive deps must be scanned (full graph, not just direct references).
  • Policy violation (critical CVE, banned/GPL license) → gate fails the release.
  • Automated remediation: Dependabot opens PR to bump versions; prefer update + redeploy on a finding.

Path MOC · shift-left-security · static-and-dynamic-analysis · Dependency-Management path

compliance-and-secret-management

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.

Path MOC · shift-left-security · static-and-dynamic-analysis · dependency-scanning · Secure-CD path

Core / Culture

dev-sec-ops

DevSecOps

What it is

DevSecOps is a culture and set of practices that embeds security into every stage of the DevOps lifecycle instead of treating it as a separate, last-minute phase. It is DevOps applied to security: development, operations, and security teams share responsibility for shipping software that is fast and secure.

Why it exists

Traditional security was a “gate” at the end of delivery (security reviews just before release), which slowed DevOps down and surfaced problems too late to fix cheaply. DevSecOps makes security a first-class, continuous activity — automated, code-based, and run by the same pipeline that ships features — so vulnerabilities are found early (the shift-left principle) when they cost the least.

Key ideas

  • Shift-left — move testing and security checks earlier in the delivery pipeline (set up, code, build) rather than deferring to a release review.
  • Security as code — policies, scan configs, and gates are defined in the repo and run in CI/CD, not maintained by a manual checklist.
  • Automated scanning pipeline — run multiple scans on every build:
  • Shared responsibility — developers own security of the code they write; security engineers enable tools, policies, and guidance; operations ensures secure platforms.
  • Continuous compliance — security gates run continuously, so compliance is demonstrated by the pipeline, not by an audit at the end.

How it fits

DevSecOps is the rationale that connects all the code-security tools in this learning path: the automated scanners, compliance gates, and signing/validation steps are the implementation of a DevSecOps culture. It pairs with platform-side checks in other paths (secure CD, identity/rbac) to protect the whole value stream.

Exam notes

  • DevSecOps = security embedded throughout, not added at the end; shift-left is the memorized motto.
  • Security must be automated in pipelines and continuous, not a single manual review.
  • Distinguish DevSecOps (culture/process for the code) from the individual tool categories that execute it (SAST vs DAST vs SCA).
  • Expect exam scenarios where the “fastest / correct” answer is to add an automated security scan + gate to the build rather than a manual release checkpoint.

Diagram

static-analysis · dynamic-analysis · software-composition-analysis · dependency-vulnerabilities · secret-scanning · compliance-gate · code-signing

📘 Source: Microsoft Learn — Dev Sec Ops

compliance-gate

Compliance gate

What it is

A compliance gate (a.k.a. quality/security gate) is an automated checkpoint inside the continuous integration/delivery pipeline that blocks the build or release until defined policies are satisfied — e.g. no critical vulnerabilities, SAST passes, code coverage ≥ threshold, no secret/banned-license violations. It makes compliance an enforced, continuous condition of shipping, not a manual audit.

Why it exists

Without gates, “we did security checks” doesn’t translate to “no known-unsafe code shipped.” A gate converts scan results into an objective go/no-go decision: if a critical finding exists, the artifact cannot proceed, forcing the team to fix it before it reaches the next (more expensive) stage. This is how shift-left security becomes enforced rather than advisory.

Key ideas

  • Policy-authored — the rules (“fail on critical vuln”, “no GPL code”, “no secret in a commit”) are codified and, ideally, version-controlled (policy as code).
  • Integrates scan outputs — consumes results of SAST, DAST, SCA/vulnerability scanning, secret scanning, unit/coverage tests.
  • Fails fast — gate evaluated in the pipeline; on failure the run is blocked/failed with who-and-why, driving the fix close to the change.
  • Evasion responsibility — findings must be triaged (e.g. approved baseline/exceptions) or the gate stays red; prevents silent offset.
  • Distinct from deployment gates — deployment gates pause a release stage (approval/metrics around promotion); a compliance gate runs on build/quality criteria about the artifact. In AZ-400 they often layer: quality gates build-time, deployment gates release-time.

How it fits

The enforcement point that makes the whole DevSecOps approach real: every scanner feeds a gate, and the gate decides “ships / doesn’t ship.” It sits in the build phase of the pipeline, upstream of release, and pairs with compliance monitoring for runtime.

Exam notes

  • Gate = automated, pipeline-blocking, policy-driven go/no-go on scan/test results — memorize “fails the build/release”.
  • Types of criteria: vulnerabilities (critical=block), SAST/DAST findings, code coverage, secret scanning, license policy.
  • Don’t confuse with deployment gates (release-stage approvals/monitoring) — quality vs deployment.
  • Exam scenario: an org wants “no vulnerable or licensed problem code to ship” → configure a quality/compliance gate in the build.

dev-sec-ops · static-analysis · dynamic-analysis · dependency-vulnerabilities · software-composition-analysis · secret-scanning · deployment-gate

📘 Source: Microsoft Learn — Compliance Gate

Code Analysis (SAST/DAST/SCA)

static-analysis

Static Analysis (SAST)

What it is

Static Application Security Testing (SAST), or simply static analysis, analyzes source code (or binaries) without executing it. It inspects the code itself — logic, syntax, and known insecure patterns — to find bugs and vulnerabilities in what you wrote.

Why it exists

Many defects are cheaper to catch by reading the code than by running it: typos, logic errors, unreachable code, unsafe function usage, SQL-injection-prone string concatenation, and hardcoded secrets. Running analysis on every commit gives instant feedback to developers and catches issues in the part of the pipeline where they cost the least to fix.

Key ideas

  • White-box — it has access to the source and reasons over the actual code, so it can find issues DAST cannot.
  • Runs without executing — no environment, no runtime state, no side effects; fast enough to run per commit/PR.
  • Finds “written-code” issues — bug patterns, code smells, style, and security anti-patterns (at the code level).
  • Integrates into the pipeline — runs as a build/PR check; results feed a compliance gate that can fail the build.
  • Limits — it cannot see runtime behavior, configuration, or interactions between live components (that’s DAST’s job).

Example tools

Authored directly in CI/CD for Azure: CodeQL (GitHub), SonarQube/SonarCloud, Pylint (Python), ESLint (JavaScript), Roslyn/.NET analyzers, Credential Scanner for secrets.

How it fits

Part of the shift-left DevSecOps toolkit. SAST = “examine the code”; DAST = “attack the running app”. Both are automated scans that feed a quality/security gate in the DevSecOps pipeline.

Exam notes

  • SAST = static / source / white-box / non-executing — memorized pairing.
  • Best for catching issues during development / code review, on every commit.
  • Complemented by DAST for runtime issues, SCA for dependency issues.
  • Common exam trap: choosing “static” when the question emphasizes running the app (that’s DAST).

dev-sec-ops · dynamic-analysis · software-composition-analysis · compliance-gate · code-signing

📘 Source: Microsoft Learn — Static Analysis

dynamic-analysis

Dynamic Analysis (DAST)

What it is

Dynamic Application Security Testing (DAST), or dynamic analysis, tests a running application by interacting with it as a real user — sending requests and observing responses — to find vulnerabilities that only exist at runtime. It is a black-box technique: it doesn’t need the source code.

Why it exists

Some vulnerabilities only appear when the app actually executes: auth/session handling, access-control flaws, injection and input-validation issues reachable through the public interface, and misconfigurations in how the running service behaves. DAST exercises the app in a live environment to catch what SAST (which never executes code) cannot.

Key ideas

  • Black-box / executed — observes the app from the outside (HTTP/API), like an attacker.
  • Finds runtime issues — session management, CSP/TLS config, SQL-injection and XSS against live endpoints, open endpoints, unsafe redirects.
  • Runs in a deployed/test environment — needs the app up (test env, staging, or pre-prod), then replays requests.
  • Feeds the gate — results can block a deployment/release gate if critical issues are found.
  • Limits — can’t inspect internal logic, unreachable code, or issues that need a specific code path that the exercised requests don’t hit (that’s SAST’s strength).

Example tools

OWASP ZAP (open-source, scriptable), Burp Suite, and commercial DAST integrated into CI/CD/release pipelines.

How it fits

Integer of the shift-left DevSecOps toolkit and the “runtime” counterpart to SAST. Typical pipeline: SAST at build/PR on source → DAST against the deployed app in a test/staging stage → results in a compliance gate.

Exam notes

  • DAST = dynamic / black-box / executing / running app — memorized pairing (contrast SAST = static/source).
  • Cannot use it in CI without a runnable environment — deeper scans run in release/test stages.
  • SAST = static vs DAST = dynamic: exam asks “which finds this?” — runtime behavior → DAST; code defect → SAST.
  • Both are inputs to automated security/compliance gates in the pipeline.

dev-sec-ops · static-analysis · software-composition-analysis · compliance-gate

📘 Source: Microsoft Learn — Dynamic Analysis

software-composition-analysis

Software Composition Analysis (SCA)

What it is

Software Composition Analysis (SCA) inventories the open-source and third-party components your application is built from and analyzes each one for security vulnerabilities, licenses, and outdatedness. It answers both “what exactly is in my software?” and “are any of those components risky or non-compliant?”

Why it exists

Modern apps are 80%+ pre-built components, not your code. That brings two risks SCA manages:

  • Security — components carry vulnerabilities that become your exposure.
  • Legal/compliance — every OSS component has a license (MIT, Apache-2.0, GPL, proprietary) with obligations you must honor; and corporate policy may ban certain licenses.

Key ideas

  • Bill of Materials (SBOM) — SCA builds and tracks an inventory of components + versions + licenses.
  • Vulnerability scanning — cross-reference each package against CVE/advisory feeds → flag risky versions (overlaps dependency-vulnerabilities).
  • License governance — detect licenses, flag copyleft (e.g. GPL) or banned ones, and block them per policy.
  • Outdated / deprecated components — report components past their supported/patched life.
  • Transitive dependencies — scans the full dependency graph, not just direct references.
  • Feed a compliance gate — policy violations (critical CVE, banned license) can fail the build/release.

Distinct from vulnerability scanning

Vulnerability scanning is the security health view (“is this package patched?”). SCA is the broader governance view — adds license and inventory (bill of materials) on top of vulnerability detection.

Example tools

Mend (WhiteSource) · Synopsys Black Duck · FOSSA · OWASP Dependency-Check (open source) · Azure-hosted Open Source compliance scanning with Azure Artifacts.

How it fits

The “software + supply chain” pillar of shift-left analysis: alongside SAST (your code) and DAST (runtime), SCA owns components/licenses. Its output gates the release via a compliance gate and pairs with dependency management for feeds/versioning strategy.

Exam notes

  • SCA = components + licenses + vulnerabilities (governance) vs vuln scanning = just patch state vs SAST = your code — memorize the three-way split.
  • License question (e.g. “a GPL component isn’t allowed”) is an SCA concern.
  • SCA output → compliance gate fails the build on critical vulnerability or banned license.
  • Related exam skill-measured phrase: “manage … open-source and third-party dependencies” — part of security/compliance.

dev-sec-ops · dependency-vulnerabilities · dependency-management · static-analysis · compliance-gate

📘 Source: Microsoft Learn — Software Composition Analysis

dependency-vulnerabilities

Dependency vulnerabilities

What it is

Dependency vulnerabilities are security weaknesses found in third-party libraries, packages, and tools that your application pulls in — either directly or transitively (dependencies-of-dependencies). Because modern apps are mostly composed of open-source components, an unpatched dependency can give an attacker the same access as a flaw in your code.

Why it exists

You rarely write the whole stack; you consume packages (NuGet, npm, PyPI, Maven, Go modules) and base images. Each has its own known vulnerabilities (CVEs). Without tracking them, an app can ship with a critical, patched-elsewhere flaw that attackers exploit — the software supply chain is a primary attack surface, which is why scanning dependencies is an AZ-400 security focus.

Key ideas

  • Direct vs transitive — you control the direct ones; transitive ones (nested deps) are also scanned by tooling.
  • CVE / advisory databases — tools cross-reference package versions against known-issue feeds (e.g. GitHub Advisory Database, OWASP Dependency-Check, NuGet/npm advisories).
  • Automated detection & remediation — tools flag the vulnerable package and suggest/auto-raise the fix (e.g. Dependabot opens a PR to bump the version).
  • Version pinning / lockfiles — lock files (package-lock.json, packages.lock.json) make the resolved set deterministic and thus scannable.
  • Feed a gate — fail the build or block the release when a critical dependency violation exists (a compliance gate).
  • Pair with SCA — dependency/vulnerability scanning is the security dimension of supply-chain component analysis; dependency management covers feeds and versioning.

How it fits

One pillar of shift-left security: automation patches risky components at the point of change instead of leaving a “known-unsafe dependency” liability in released builds. Works alongside SAST (your code), DAST (runtime) and SCA (components).

Exam notes

  • Distinguish SAST (your code) vs dependency/vuln scanning (third-party components) vs SCA/llicense (component inventory + legal).
  • Memorize the tool: Dependabot (GitHub) auto-opens PRs for vulnerable dependencies; Azure DevOps integrates Open Source / vulnerability scanning with Azure Artifacts.
  • Watch for transitive dependencies — tooling must scan the full graph, not just directly-referenced packages.
  • Vulnerable package found late → prefer update + redeploy via automated PR; the finding should gate the release.

dev-sec-ops · software-composition-analysis · compliance-gate · dependency-management · azure-artifacts

📘 Source: Microsoft Learn — Dependency Vulnerabilities

Supply Chain & Secrets

code-signing

Code signing

What it is

Code signing is the practice of digitally signing software artifacts (executables, packages, scripts, firmware) with a private key to guarantee who published it (authenticity) and that it wasn’t tampered with since signing (integrity). A valid signature means a trusted signer produced the artifact and it arrived unchanged.

Why it exists

Users and systems can’t trust software just because it “came from somewhere.” Attackers routinely inject malicious code into builds or repackage legitimate software. Signing lets clients verify the author and integrity of an artifact before running/installing it — reducing runtime prompts (fewer “unknown publisher” warnings), enabling build provenance, and blocking tampered droppers in the supply chain.

Key ideas

  • Public/private key pair — the publisher signs with its private key; anyone verifies with the corresponding public certificate.
  • Certificate authority (CA) — the certificate is issued by a trusted CA; trust chains back to it (e.g. code-signing certs with an EV/OV identity).
  • Hashing — the signer hashes the content and signs the hash; any change to the artifact breaks verification → signals tampering.
  • Known in Windows as Authenticode (PE/signing); package managers (NuGet, MSIX, APK) and OSes also validate signatures.
  • Azure Trusted Signing — Azure service that issues/renews signing certificates (with identity and Audit management) so pipelines don’t have to hold long-lived certs.

How it fits

Adds end-to-end integrity to the software supply chain: code is analyzed by SAST/SCA (correctness/security), then signed to lock in the verified artifact before it ships — a hard security control feeding a compliance gate on release. Complements build-artifact integrity/provenance in CI.

Exam notes

  • Signing solves authenticity (who) + integrity (tamper-proof) — memorized.
  • Private key signs; public key verifies; the certificate must trace to a trusted CA.
  • Windows Authenticode; EV certs = strong identity for code signing; Azure Trusted Signing is the managed modern option.
  • Contrast with encryption: signing is for integrity/authenticity (not secrecy of content).

Diagram

dev-sec-ops · compliance-gate · build-artifact · static-analysis

📘 Source: Microsoft Learn — Code Signing

secret-scanning

Secret scanning

What it is

Secret scanning automatically detects hardcoded secrets — API keys, passwords, connection strings, OAuth tokens, private keys, certificates — in source code, commits, and build scripts, and flags/remediates them before they leak. It finds credentials committed by accident so a repository history doesn’t become a treasure chest for attackers.

Why it exists

Developers routinely paste a token to get something working and it ends up in a commit — and git history keeps it forever, even if the latest commit removes it. Scanning code (current state and full commit history) is the reliable way to catch leaked credentials, then revoke & rotate them, because a committed secret must be considered compromised regardless of deletion.

Key ideas

  • Content/text scanning — runs as a PR/build check to catch secrets in the code being authored.
  • History scanning — scans the full git history, not just HEAD, since old commits still contain the secret and bots mine them.
  • Patterns + entropy — detects by known key formats (e.g. sk-...), header shapes (Authorization: Bearer), and high-entropy strings.
  • What to do on a hit — revoke/rotate the credential, remove it from history (or treat history as compromised), and add it to an allow/ignore list if it’s a test fixture.
  • Secret about remediation — don’t just delete; push the fix, invalidate the token, and optionally surface to the owner.
  • Pair with secret storage — scanning pushes you to move secrets to a secure store (Azure Key Vault) into variables/references rather than hardcoding.

Example tools / services

GitHub secret scanning (built-in); Azure DevOps CredScan / advanced security secret scanning; open-source Gitleaks, TruffleHog, detect-secrets — runnable in CI as a gate.

How it fits

The credential-leak pillar of shift-left security: a compliance gate runs secret scanning on PR/build (and history) so secrets can’t slip into a shipped or force-pushed artifact. It complements SAST (which finds code flaws, not necessarily credentials) and the secure-CID path’s secret management.

Exam notes

  • Secret scanning = hardcoded credentials in code/history; on hit → revoke + rotate (never assume delete is enough, history persists).
  • Scan history as well as working tree — memorized trap (“it’s in an old commit”).
  • Tools: GitHub secret scanning, Azure DevOps **CredScan/**Advanced Security, Gitleaks, TruffleHog.
  • Best practice pairing: scan and store secrets in Key Vault/variables (secrets-management) so nothing sensitive lives in the repo.

dev-sec-ops · secrets-management · key-vault · compliance-gate · static-analysis

📘 Source: Microsoft Learn — Secret Scanning

DevSecOpsSAST & DASTDependenciesCompliance & secretsCultureGateSASTDASTSCAVulnsSigningSecrets