Week 16: Capstone — Secure a Full DevOps Pipeline End-to-End

1. Scoping the Pipeline

Before touching any configuration, define exactly what "the pipeline" means for this project — the same discipline Week 14's scoping/authorization step requires before any testing begins.

• What's being built and deployed? — Reuse an app from an earlier course (a React or Node app is fine) or build something small and simple; the pipeline's security is the point, not the application's feature set.
• What's the full path? — Source repo → CI (lint/test/build) → artifact (container image or build output) → deployment target (a cloud instance, a container platform, a static host).
• What's genuinely in scope for this capstone? — A small, complete pipeline done properly beats an ambitious one left half-hardened, echoing Week 14's own "small and well-built beats large and untested" framing.

Draw this as a diagram before writing any config — a Week 1-style data-flow diagram of the pipeline itself, with every trust boundary marked (developer → repo, repo → CI, CI → registry, registry → production).

2. Threat Model & Hardening Plan

Run Week 1's full process against the pipeline diagram from Section 1: STRIDE at every trust boundary, a risk estimate per threat, and a concrete mitigation mapped to a specific, later course week.

• Source control boundary — Can a malicious commit or PR trigger CI with elevated secrets access? (Week 10's CI/CD lockdown)
• CI boundary — Are third-party actions pinned? Is the CI pipeline itself least-privilege scoped? (Week 10)
• Build artifact boundary — Is the container image minimal and non-root? Is it scanned before it's ever deployed? (Week 9, Week 11)
• Deployment boundary — Is IAM/cloud access least-privilege? Are security groups default-deny? (Week 8)
• Runtime boundary — Is the running system monitored, with alerts that would actually fire on a real attack pattern? (Week 12)

The output of this section is a written threat model and hardening plan — a real document, not just a mental checklist — that Section 3 then implements in order.

3. Full Implementation, in a Sensible Order

Build in an order that lets each layer be verified before the next depends on it — the same incremental discipline the React course's own capstone uses for application code, applied here to security controls:

# 1. Harden the base: non-root, minimal container image (Week 9)
# 2. Secrets out of source control entirely -- a vault or CI-native
#    secrets store, never a checked-in credential (Week 10)
# 3. CI pipeline lockdown: pinned actions, scoped secrets per job (Week 10)
# 4. Dependency scanning wired INTO the pipeline, failing the build
#    on a critical finding, not just reported after the fact (Week 10, 11)
# 5. Least-privilege cloud IAM for whatever deploys the artifact (Week 8)
# 6. Network controls at the deployment target: security groups,
#    segmentation appropriate to what's actually running (Week 2, 8)
# 7. Monitoring: centralized logs, at least one real detection rule
#    tuned against this specific pipeline (Week 12)

Verify each step with the same "prove it, don't assume it" standard the rest of this course has used — confirm a pinned action actually resolves to the expected commit, confirm the scanning step actually fails a deliberately-vulnerable dependency, confirm the detection rule actually fires against a simulated attack (Week 12's own exercise pattern).

4. A Full Scanning & Monitoring Pass

Apply Weeks 9-13 in full against the finished pipeline, not as an afterthought:

• Image/dependency scanning (Weeks 9-10) — run it for real, and address (or document, with reasoning) every finding above your chosen severity threshold.
• Vulnerability scan (Week 11) — scan the deployed target itself, not just the container image, and triage findings with Week 11's fuller framework, not raw CVSS alone.
• A real detection rule (Week 12) — at minimum, one rule tuned against this pipeline's own logs, deliberately triggered and confirmed to fire.
• A mini incident-response dry run (Week 13) — simulate one plausible compromise (a leaked credential, an exploited dependency) and walk through containment and a blameless summary, even briefly.

5. Deployment & Portfolio Write-Up

A pipeline nobody else can see the security work behind is far less valuable as a portfolio piece than one with a clear, documented story. Deploy the actual application through the hardened pipeline, then write it up properly.

• The system and its threat model — the Section 1-2 diagram and findings, presented cleanly.
• What you hardened, and why — mapped explicitly back to specific weeks/controls, the same mapping discipline Week 15 practiced.
• What you scanned, tested, and found — real findings, honestly described, including anything you chose to accept as a documented risk rather than fix (with reasoning).
• Evidence — screenshots of a passing scan, a fired detection rule, an enforced least-privilege policy — the same evidence discipline Week 15's compliance mapping required.
• What you'd do with more time — an honest gap list is more credible than an unqualified "fully secure" claim, and shows the kind of ongoing thinking a real security role requires.

6. The Capstone Project

7. Final Checklist

Before calling the capstone — and the course — done, confirm each of these honestly: