Exercises: DevSecOps and the Secure Pipeline

These exercises move from vocabulary to pipeline design. Difficulty is marked ⭐ (recall/application), ⭐⭐ (analysis), and ⭐⭐⭐ (synthesis/open-ended). A dagger (†) marks problems with a full worked solution in Appendix: Answers to Selected Exercises — try every problem before you read one.

Work in your own notebook, a private repository, or a sandbox CI you control. Where an exercise asks you to write a pipeline config or a policy, exact syntax matters less than placing the right control at the right stage for the right reason. Authorization rule: any hands-on pipeline or scanner work is on your own projects and infrastructure only.

Part A — Core vocabulary ⭐

1.† In one sentence each, define DevSecOps, shift left, CI/CD pipeline, and security gate, then write one sentence that uses all four correctly to describe catching a flaw before it ships.

2. Match each scan to the question it answers: SAST, DAST, SCA, secrets scanning, IaC scanning, container image scanning. (a) "Is the running login form injectable?" (b) "Did someone commit an AWS access key?" (c) "Does this Terraform open a port to the whole internet?" (d) "Is our code written insecurely?" (e) "Are we running a known-vulnerable version of a library?" (f) "Does this built image ship unpatched OS packages?"

3. Explain the difference between artifact signing and provenance in one sentence each, and state why SolarWinds proves you need both, not just signing.

4.† Define pipeline integrity and list three controls that protect it. Why does the SolarWinds attack make this property "a first-class security boundary"?

5. Give the canonical distinction between a guardrail and a gate, and classify each of the following as one or the other: (a) AWS Block Public Access; (b) a SAST scan that fails the build on a critical finding; (c) a service control policy denying 0.0.0.0/0 SSH ingress; (d) a manual security review before release; (e) a deploy-time policy-as-code check.

6. Explain shift-left economics in two sentences: what happens to the cost of fixing a defect as detection moves later, and why does that justify moving checks toward the developer?

Part B — Reasoning about gates and scanning ⭐⭐

7.† A team puts all six security scans at the CD/deploy gate "because that's closest to production." Explain two concrete problems this causes, and rewrite the placement: which scans belong at pre-commit, which at CI, and which legitimately at deploy — and why.

8. A SAST gate is configured to fail the build on every finding it produces, including informational and low-severity ones. Predict what the development team will do within two weeks, and propose a gating policy that keeps the gate alive and useful. Reference at least three of the five "embed without blocking delivery" rules.

9.† Your organization adds IaC scanning to a five-year-old Terraform codebase and the first run reports 312 findings. If you fail the build on all of them, no one can deploy anything. Describe the baseline strategy that lets the gate protect against new mistakes from day one without halting all work, and explain what should happen to the 312 pre-existing findings.

10. Explain why the build/CI stage carries the densest cluster of security gates. Give the three properties of the CI stage that make it the right home for most automated scanning.

11.† A developer complains: "The secrets scanner is useless — I already have a pre-commit hook that checks for secrets, so the CI gate is redundant and just slows me down." Write a three-sentence response explaining why the CI gate is not redundant.

Part C — Add the gate ⭐⭐

12.† Add the gate. Here is a stripped-down CI pipeline (illustrative, GitHub-Actions-style) that builds Meridian's loan app but performs no security checks:

name: build
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r requirements.txt
      - run: pytest
      - run: docker build -t loanapp:latest .
      - run: docker push registry.meridianbank.example/loanapp:latest

Add security gates in the right places: a secrets scan, SCA on the dependencies, SAST on the code, IaC scanning on the project's terraform/ directory, and container image scanning on the built image. Annotate (in comments) what each gate checks and what severity should fail the build. You do not need real action names — placeholders like run: secrets-scan . are fine; placement and policy are the point.

13. Add the gate. The pipeline in Exercise 12 pushes an unsigned image straight to the registry with no integrity verification. Add the §31.4 controls: sign the artifact, generate provenance, and add a deploy step that refuses to deploy anything unsigned or not built by your pipeline. In one sentence, state which famous attack this defends against.

14.† Add the gate. A pipeline runs SAST, SCA, secrets, IaC, and container scanning serially, and each takes ~3 minutes, so the gate takes 15 minutes and developers are furious. Without removing any scan, cut the wall-clock time roughly in third. Explain the single change and why it is safe.

Part D — Find the pipeline weakness ⭐⭐–⭐⭐⭐

15.† Find the weakness. Review this build configuration and identify the pipeline-integrity weaknesses (there are at least four). For each, name the control from §31.4 that fixes it.

PIPELINE CONFIG — "deploy-prod"
  trigger:        any push to any branch, by any repo collaborator
  build runner:   a long-lived, shared VM reused across all builds; never rebuilt
  cloud creds:    a single AWS access key, hard-coded in the pipeline settings,
                  with AdministratorAccess, never rotated
  dependencies:   'pip install -r requirements.txt'  (no version pins, no hashes)
  artifact:       pushed to production registry; not signed; no provenance
  who can edit:   all developers have admin on the CI system

16. Find the weakness. An attacker who has compromised one developer's laptop wants to ship malicious code to all of Meridian's customers. Given the hardened pipeline of §31.6, walk through what they would have to defeat at each stage (commit, CI, deploy) and identify which single control is the hardest for them to bypass and why.

17.† Find the weakness. A vendor delivers a signed software update. Your team verifies the signature is valid and deploys it. Two weeks later it turns out the update was backdoored. The signature was genuinely the vendor's. Explain exactly how this is possible, what it has in common with SolarWinds, and what the vendor should have provided (and you should have verified) to catch it.

18. ⭐⭐⭐ Find the weakness. A team proudly reports "100% of our deploys pass the security gate." On investigation, you find the gate is configured to fail on CRITICAL only, the scanners are a year out of date, and there is a documented process for engineers to add a # nosec suppression comment to silence any finding with no approval required. Is "100% pass rate" good news? Identify every way this metric is being gamed and propose three fixes.

Part E — Write policy as code ⭐⭐–⭐⭐⭐

19.† Write the policy. In pseudocode or Rego-style syntax, write a policy-as-code rule that allows a deployment only if: the artifact is signed, its provenance builder equals "meridian-ci", and it has zero fixable critical vulnerabilities. Default to deny. Add at least one human-readable deny_reason. (Model it on §31.5; you do not need runnable Rego.)

20. Write the policy. Extend your Exercise 19 policy to also require that the image was built from a branch named main (not an arbitrary branch) and that the secrets scan found nothing verified. Explain in one sentence why "built from main only" is a meaningful integrity control.

21.† Write the policy. Convert this English security policy into a policy-as-code rule (pseudocode is fine): "No Terraform may be applied that creates a security group allowing ingress from 0.0.0.0/0 on ports 22 or 3389." Then explain whether this is better implemented as a gate (the policy check) or a guardrail (a structural control), and why you might want both.

22. Write the policy. A team wants a critical vulnerability with no available fix to not block deploys forever (otherwise they could never ship), but they do not want such vulnerabilities ignored. Design the policy logic and the surrounding process: how does the unfixable critical get tracked, time-boxed, and re-evaluated, rather than silently accepted? (This is risk acceptance for the pipeline.)

Part F — Design the secure pipeline ⭐⭐⭐

23.† Design it. A fintech startup deploys a customer-facing web app to AWS via CI/CD, ten times a day, with a six-person engineering team and no dedicated security staff. Design a secure pipeline for them: name the gates at each stage (commit / CI / deploy), state your gating policy (what fails the build), identify at least two guardrails you would put in place instead of gates, and explain how your design keeps the team's velocity. Half a page to a page.

24. Design it. Apply the guardrails-first principle to a specific class of mistake: developers keep accidentally committing AWS keys. Design a layered defense using both a guardrail and a gate (and the secrets-management ideas from Chapter 20), so that (a) committing a key is hard, (b) a committed key is caught before it ships, and (c) even a leaked key does limited damage. Name a control for each.

25. ⭐⭐⭐ Design it. Your CISO asks: "If an attacker gets into our build server like they did at SolarWinds, what would stop them from shipping malicious code under our name?" Write a one-page answer structured as the §31.4 pipeline-integrity controls, explaining for each control what attacker action it blocks or reveals. Be honest about residual risk: what could a sufficiently capable attacker still do?

Part G — CTF-style challenge ⭐⭐⭐

26.† The build that lies. You are handed evidence from a (constructed) incident. The source code in the repository is clean and passed all SAST/SCA/secrets gates. The deployed binary, however, contains a backdoor. The build logs show the build "succeeded" and the artifact was signed with the company's real key. Provenance was never generated or verified. (a) Where in the pipeline was the malicious code most likely introduced, and how do you know it was not in the source? (b) Which §31.4 control, if it had been present, would have prevented this, and which would have detected it? (c) Now that it has happened, what is the immediate response (hint: the signing key and the SOC)?

Part H — Interleaved & forward-looking ⭐⭐

27. (Interleave Ch.12.) The OWASP Top 10 includes "Vulnerable and Outdated Components." Which two of this chapter's six scans address it, at which two pipeline stages, and how do they differ from each other?

28. (Interleave Ch.15.) In Chapter 15 you learned to detect a public S3 bucket with CSPM after it exists. In this chapter you prevent it with IaC scanning before it exists. Argue why a mature program runs both, and give a specific scenario where CSPM catches something IaC scanning never could.

29. (Interleave Ch.20.) A secrets scan finds an API key committed three months ago and since "deleted" from the latest code. Why is deleting the line insufficient, what must actually happen to the key, and which Chapter 20 capability makes this less painful going forward?

30. (Interleave Ch.29.) SLSA defines build-integrity levels. Explain how a SLSA provenance requirement, which you learned to demand of a vendor in Chapter 29, becomes something your own pipeline produces and your deploy gate verifies in this chapter. What is the same, and what is new?

31. ⭐⭐⭐ (Forward to Ch.32.) The deploy gate in §31.5 defaults to deny and verifies identity, provenance, and posture on every request. Write two sentences predicting how this same "never trust, always verify, default-deny" instinct becomes a whole architecture in the next chapter, and what "trust nothing implicitly" would mean for the pipeline's own network access.

32. Open reflection. This chapter argues you should "prefer guardrails, use gates where you must." Name one area of your own life or work (outside software) where a guardrail — making the wrong action structurally impossible — would beat a gate that checks your behavior each time. What does that suggest about designing controls people cannot route around?

Solutions to daggered (†) problems are in the Answers appendix. The remaining problems are deliberately open — bring them to a study group, a sandbox pipeline, or your instructor.