Security & DevSecOps

This bootcamp has spent four classes teaching you where secrets must not live: not in Git (Class Twenty), not in Terraform state left unguarded (Twenty-One), not echoed in pipelines (Twenty-Two), not baked into image layers (Twenty-Six). The affirmative answer is Azure Key Vault — a hardened store for three kinds of dangerous material: secrets (connection strings, API keys, passwords — arbitrary strings, versioned), keys (cryptographic keys that never leave the vault; you send it work, it signs and decrypts inside), and certificates (with lifecycle management — renewal and, paired with Class Thirty's proactive checks, the end of expiry surprises).

Key Vault

A per-application store for secrets, keys, and certificates — access-controlled by Entra ID and RBAC, every read and write audit-logged, so "who can see the database password" becomes a role assignment you can list instead of a rumour you can't.

Two design points carry the class. First, RBAC on the vault itself: the vault is only as good as its door, and the door is Class Eight — data-plane roles like Key Vault Secrets User (read secrets) and Key Vault Secrets Officer (manage them), assigned per identity, per vault.¹ The clean pattern stacks three earlier classes: the app's managed identity (Class Nine) gets Secrets User on its own vault — no credential needed to fetch credentials, and the storefront's identity cannot read the payment vault's contents. Second, apps never handle vault plumbing: App Service and Container Apps support Key Vault references — the app setting contains a pointer, the platform fetches the value at start using the managed identity, and the code just reads its configuration. Rotation becomes a vault operation; the app never redeploys, never knows.

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.²

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.

Phase Three built machinery with real power: identities that deploy to production, tokens that write to your repositories, runners that execute whatever workflows say. This section is the audit you now know enough to run — four questions, asked of every pipeline, each one a callback:

# the pipeline least-privilege audit — run it quarterly
1. What can each service principal reach?      (Class 8)
   → Contributor on its own resource group, never the subscription.
2. Which runs can become each principal?       (Class 23)
   → subject claims: environment:production, never pull_request.
3. What can the GITHUB_TOKEN do?               (Class 24)
   → permissions: contents: read at the top; more only where earned.
4. Who reviews the files that grant all this?  (Class 22)
   → .github/ behind CODEOWNERS and required review.

Power accumulates; audits subtract.

The reason this is a recurring audit and not a setup task: privilege only ever drifts upward. Every incident adds a temporary permission somebody forgets to remove; every new feature widens a role "for now"; every convenience argues for Contributor at the subscription. Nothing in the system pushes back except a human with a checklist and a calendar entry — and the checklist above takes an hour a quarter. The interviewer's version of this section is one question — "what could an attacker do with your CI?" — and the strong answer walks these four lines and ends with: less than they could last quarter.

"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 (the §4 audit, run on a calendar). Four sentences, each backed by something you can screen-share.

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.