Posture & Supply Chain

Security work has a measurement problem: "are we secure?" has no yes. Microsoft Defender for Cloud answers a tractable question instead — how does this estate compare against a checklist of known-good configuration? — and renders the answer as the secure score: a percentage, built from recommendations it continuously evaluates against everything in the subscription. Storage accounts allowing public access, VMs missing patches, vaults without purge protection, subscriptions with too many owners: each finding docks points, each fix earns them back, grouped so that the identity findings (usually the heaviest) sit at the top.

The score's real value is political as much as technical. Security investment is famously hard to argue for — its successes are invisible — but a number that was 43 and is now 71 is a progress bar leadership can read, and the recommendation list under it is a pre-prioritised backlog with the reasoning attached. Treat it as a score you can argue with: some recommendations will not apply to you (a dev subscription need not meet production bars), and Defender lets you exempt them with a documented reason — which is not cheating; it is the argument, recorded. The free tier of this posture management costs nothing and is on by default; the paid Defender plans add active threat detection per workload type — including the Class Twenty-Six image scanning on ACR — and are a per-workload cost decision, not an all-or-nothing one.¹

The same engine renders a second view that matters more to auditors than to engineers: the regulatory compliance dashboard. It maps the estate against named frameworks — the Microsoft Cloud Security Benchmark by default, and ISO 27001, PCI-DSS, SOC 2 and their kin once assigned — and shows pass or fail per individual control, with the failing resources listed beneath each. When an auditor asks to see that encryption is on everywhere, this is the screen that answers in an afternoon instead of a fortnight of spreadsheet archaeology. Read a green control as evidence you are ready to be audited, not as proof you passed one² — the dashboard demonstrates control coverage; a real audit still wants scope, interviews, and paperwork it cannot see. The paid Defender plans behind the secure score are the active-detection layer, chosen per workload — Defender for Servers, for Containers (the Class Twenty-Six image scanning), for Storage, for Key Vault, for Databases — each a monthly per-resource charge that buys threat alerts on top of the free posture assessment, turned on where a workload is worth the watch rather than thrown estate-wide.

Campux's storefront is Campux's code plus a few hundred packages written by strangers, built on base images assembled by other strangers. That inheritance is the supply chain, and it is where modern compromises actually arrive — not through your firewall but through a dependency's. Four scanners, all sitting in the GitHub estate you built in Phase Three, watch it — and the code you write on top of it — continuously:

Dependabot

Reads your dependency manifests, cross-references every package version against known CVEs, raises an alert per finding — and can open the fix PR itself, version bump ready for review. Your Class Twenty-Two CI then proves the bump breaks nothing, which is the quiet payoff of having CI at all.

Code scanning

Static analysis — GitHub's engine is CodeQL — reads your own code for vulnerable patterns: injection paths, unsanitised input reaching a query, secrets handled carelessly. It runs as a Class Twenty-Two workflow on every pull request, so the finding arrives as a review comment before the flaw merges — the cheapest moment any security bug will ever be fixed.

Secret scanning

Scans the repository — history included — for strings shaped like credentials, and push protection blocks the commit at push time, before the secret enters history at all. The Class Seventeen lesson made mechanical: the only good place to catch a committed secret is before it commits.

Image scanning

Defender inspects every image pushed to ACR against known vulnerabilities — Class Twenty-Six's rot problem, watched. The finding is almost never your code; it is a base-image layer, and the fix is the container discipline: rebuild on an updated base and redeploy.

Notice what all four have in common: they are free or nearly free to enable, and enabled once. The work is not running them — machines run them — but triaging what they find, which is why the Class Thirty lesson applies verbatim: an unowned scanner alert channel becomes wallpaper in a month. Route findings somewhere owned, and treat "Dependabot PR merged within a week" as a team habit with the same standing as code review.

These four belong to a taxonomy interviewers name, worth holding as a set. Dependabot is SCA — software composition analysis, reading the dependencies you inherited. CodeQL is SAST — static application security testing, reading your source code at rest. Secret scanning and image scanning round out what can be checked without running anything. The category none of them covers is DAST — dynamic application security testing, which probes the running application for flaws that surface only at runtime, and which is not a GitHub switch but a stage you add: a tool such as OWASP ZAP fired at a deployed test environment. That split — scan the code at rest, then probe it running — is the shape you rebuild in Class Thirty-Nine on Azure DevOps Pipelines, where the security checks are stages that fail the build exactly as a failing test does. The idea under all of it is shift-left: run every check as early as it can run, because a finding on a pull request costs a review comment and the same finding in production costs an incident.

Everything so far has hardened one layer at a time: a vault for secrets, a score for posture, scanners for the supply chain. Step back and the pattern has a name — defence in depth — and a premise: every layer you own will, eventually, fail, so you arrange several so that the failure of any one is caught by the next. The first thing to fix in place is which layers are even yours. Moving to Azure does not hand your problems to Microsoft; it relocates the line between their responsibility and yours. Microsoft owns the datacentre, the physical host, the hypervisor, the physical network — you will never patch a hypervisor, and that is the trade. Everything above the line — identity, data, network configuration, the application — stays yours to hold.

The line's position is not fixed; it slides with the service model from Class Four. On a virtual machine you patch the guest OS; on App Service the platform patches the OS and you own only the app and its configuration; on a SaaS mailbox you own almost nothing but the data and who may read it. The most expensive misreading in this work is assuming the provider covers a layer they explicitly do not — because when a storage account leaks, Azure did its job. The disk was encrypted, the datacentre locked; the public-access toggle you left on sat above the line. The provider secures the building; you lock the room.

Identity and data stay yours at every tier — which is why this class spends most of its budget there — but the middle layers move, and the network is the one worth walking in full, because it is where the earlier classes stack into a wall. Read it from the internet inward. DDoS Protection absorbs volumetric floods at the edge before they reach anything you pay for. A Web Application Firewall (WAF), riding on Front Door or Application Gateway, inspects HTTP for the injection and scripting patterns CodeQL catches in your code — but at runtime, for traffic you did not write. Azure Firewall governs what your subnets may reach outbound, the exfiltration path most designs forget to close. Network security groups are the per-subnet, per-NIC allow-lists. And private endpoints (Class Fourteen) take the PaaS services off the public internet entirely, so the storefront reaches its database over a private address that never leaves the VNet. No one of these is security; stacked, they are.

The provider secures the building. You lock the rooms.

The secure score in §1 answered a checklist question one finding at a time. The frontier past that list has a name the industry has settled on and interviewers now expect — Zero Trust — and it is three sentences, not a product. Verify explicitly: every request authenticates and is authorised on its own merits — identity, device health, location checked at the door each time — rather than trusted because the caller is already inside the network. Use least privilege: Part I's pipeline audit and privileged-identity work, in space and in time, is this principle already built. Assume breach: design as though an attacker is already inside, which is precisely the premise under the defence in depth of §3 — segment the network, bound the blast radius, log everything, so the breach you assume is one you can see. The old model trusted a perimeter and let anything inside roam; Zero Trust deletes the idea of "inside."

The tools that operationalise this split into two jobs worth naming precisely, because the acronyms are interview currency — and Azure's answer folds them into one product you have already been driving.

CSPM

Cloud security posture management — the misconfiguration half. Is this storage account public, is MFA on, is encryption set? Defender's free posture tier and its secure score are CSPM; you met it in §1 and owe it nothing more here.

CWPP

Cloud workload protection platform — the runtime half. Is this VM running something that looks like a miner, is this container calling a known-bad address? Defender's paid per-workload plans (also §1) are CWPP: detection on the living workload, not the config at rest.

CNAPP

Cloud-native application protection platform — the two folded into one pane, so a posture finding and a runtime alert can be reasoned about together. Defender for Cloud is Azure's CNAPP; a job posting that lists the word is describing what this whole class taught, under one label.

The reason folding them together earns its keep is the feature that changes how you triage: attack-path analysis, built on Defender's cloud security graph. A flat list treats "VM has a public IP", "VM's identity can read the storage account", and "storage account holds customer data" as three separate medium findings you may never reach. The graph connects them into one sentence — an internet-exposed VM can reach the crown-jewels storage through its own identity — and ranks that path above a hundred isolated items, because it is the one an attacker actually walks. Posture stops being a backlog to burn down and becomes a set of chains to break at their cheapest link: drop the public IP and the whole path is severed.

An attacker walks paths, not lists.

Two operational choices sit under all this. Workload scanning comes agent-based — a Defender agent runs on the machine, giving deep, live runtime signal at the cost of something to deploy, patch, and account for on every VM — or agentless, where Defender snapshots the disk out of band and scans the copy, seeing installed packages and secrets with zero footprint on the workload but without the live process view. Mature estates run both: agentless for universal coverage, agents where the running picture earns its keep. And none of it is Azure-only — Defender connects AWS accounts and GCP projects and renders one secure score across all three, which is the actual job, since almost no real estate is single-cloud. The frontier, in one line: not "we scan our resources" but "we can see the paths an attacker would walk across every cloud we run, and we break them in priority order."

The §2 scanners find problems; policy-as-code stops the problem from ever deploying, by writing the rule as a machine-checked gate instead of a wiki page nobody reads. Two gates, at two layers, worth telling apart. Azure Policy (Class 8) sits at the ARM control plane: a policy that denies any storage account with public access, or audits any resource missing a required tag, is evaluated when the resource is created or changed, and the non-compliant deploy is refused by Azure itself before the resource exists. Gatekeeper — the Kubernetes admission controller built on OPA (Open Policy Agent) — sits one layer in, at the AKS API server: when a pod is applied, Gatekeeper checks it against policy and rejects it at kubectl apply if it runs privileged, pulls from an untrusted registry, or omits resource limits. Azure Policy governs the Azure resource; Gatekeeper governs what runs inside the cluster — and Azure Policy for AKS is Microsoft's managed Gatekeeper, so the two meet. The shared idea: the rule is code, versioned and reviewed like any other grant of power, and enforcement is automatic rather than a reviewer's memory.

The rule is code, or the rule is a rumour.

The same shift-left instinct reaches back into the Bicep and Terraform of Classes 20 and 21. IaC security scanning — Checkov, tfsec, or Microsoft's PSRule — reads the template before apply and fails the pipeline on the public storage account, the unencrypted disk, the NSG open to the world, catching in a pull request what Defender would otherwise surface in production a week later. It is a stage you add to the Class 39 pipeline exactly like a test: the plan is scanned, the build goes red on a high finding, the misconfiguration never reaches an environment. Policy-as-code and IaC scanning are the same lesson at two moments — one refuses the bad deploy at the platform, the other at the pipeline — and defence in depth wants both.

The four scanners watched what you depend on; the supply chain's other half is proving what you ship. Three nouns carry it, and they belong together as a set.

SBOM

Software bill of materials — a manifest of every component inside an artifact, so that when the next Log4j lands you answer "are we affected?" with a query against the SBOM instead of a week of archaeology.

Signed artifacts & provenance

The build signs its output (cosign, Notary) and records how it was built, so a consumer can verify the image came from your pipeline and not a substitute slipped in transit. SLSA is the industry ladder of maturity for exactly this provenance — a level you can be measured against.

Dependency pinning

Lockfiles, and pinning by digest rather than a mutable tag, close the gap where latest silently becomes something else overnight. What you tested is what you ship, because the version cannot move underneath you.

Together they answer the question the §2 scanners cannot: not "is what I depend on known-bad" but "is what is running actually what I built." Two closing moves finish the discipline. First, rotation as machinery, not memory: Key Vault carries rotation policies and fires Event Grid events on expiry, so a certificate or key rotates on a schedule and its dependents are notified rather than surprised — and at the top end, secret scanning can auto-revoke a leaked credential with the provider the instant it is detected, so detection response stops being a human paging a human. Second, the part no tool ships: DevSecOps is a culture before it is a pipeline. Shift-left is a team practice, not a product — security folded into design review, threat modelling done while the feature is still a diagram and cheap to change, a security champion embedded in the team rather than a gate bolted on at the end, and the blameless-postmortem discipline that makes people report the near-miss instead of hiding it. The tools in this class raise the floor; the culture decides whether anyone treats the red build as a real failure or a switch to override. Security as everyone's job is not a poster — it is who gets asked, and when.

"Tell me about security in your last environment" is a question most candidates answer with a product list, which is exactly as convincing as answering "are you healthy?" with the contents of a medicine cabinet. The strong answer is a posture story with a shape: where the secrets live (a vault, RBAC'd, referenced by managed identity — nothing stored in code, settings, or pipelines); how you know your standing (a score, its trend, and the exemptions you argued); what watches the code and its supply chain (four scanners, each with an owner); and what bounds the blast radius (a least-privilege audit, run on a calendar). Four sentences, each backed by something you can screen-share — and the senior version adds two more that separate a candidate from the pack: that you triage attack paths rather than finding lists (§4), and enforce the rules as code at the platform rather than by review after the fact (§5).

End the story the way honest security people do: with the residual risk, named. "The workflow files are still the most powerful text in the company, which is why they get the strictest review" — or whatever your estate's true soft spot is. Naming your own weakness, unprompted, is the highest-credibility move available in a security conversation, because it proves the posture is something you maintain rather than something you recite.³ Auditors, interviewers, and incident retrospectives all reward the same voice — Class Twenty-Three's auditor conversation taught it, and it transfers everywhere.