DevSecOps & Secure SDLC Exam Prep

DevSecOps and secure-software exams rarely ask you to recite what a tool does. They hand you a team, a pipeline and a deadline, and ask which control belongs where, which finding matters first, and which option is the BEST next step. This lesson shows you how those exams think, gives you a map of the whole secure software development lifecycle, solves a complete "which control belongs in which pipeline stage?" case with you, and ends with a 4, 8 or 12-week study plan.

• 12lessons in the course
• 7SDLC stages on one map
• 40original questions in the final exam
• ~20 minreading time for this lesson

What DevSecOps and secure-SDLC exams actually test

This course covers topics that also appear in exams such as ISC2's CSSLP, GIAC's GCSA or EC-Council's CASE, but it is built around the shared, vendor-neutral body of knowledge rather than around any one of them. The formats differ – some exams are pure multiple choice, others add practical tasks – yet the thinking they reward is remarkably similar.

First, they test placement. You are expected to know not only what static analysis is, but that it reads source code and therefore belongs on every pull request, long before anything is deployed. You must know that dynamic testing needs a running application, so it cannot be the first line of defence on a developer's laptop.

Second, they test priority. A team has fourteen findings and one afternoon. Which one do you fix first? A leaked production credential beats a medium-severity library flaw in a test-only dependency every time, and exams love to hide the obvious answer behind a higher CVSS number.

Third, they test process over tools. Many wrong options name a fashionable product or "buy a scanner". The right option usually describes a practice: define security requirements, threat model the design, enforce a policy as a gate, give developers fast feedback, measure remediation time.

Fourth, they test proportionality. A control that blocks every build on every low finding is not "more secure"; it trains people to bypass the pipeline. Good answers balance risk, speed and the people who have to live with the control.

The four question shapes you will meet

• EARLIESTAt which stage can this flaw be detected first?
• BESTWhich control most effectively reduces this risk?
• FIRSTWhat must happen before anything else?
• MOST LIKELYWhat explains this symptom or finding?

Learn to spot the qualifier before you read the options. "Earliest" questions are about inputs and stages. "Best" questions are about root cause and coverage. "First" questions are almost always about containment or about getting authority and scope right. "Most likely" questions are about reading evidence calmly instead of jumping to the dramatic explanation.

The secure-SDLC map: eleven domains in one table

Every lesson after this one covers one domain of the map. The table shows what each domain is about, how exams tend to ask about it, and the trap that catches most candidates. Keep it open while you study; it doubles as a checklist for your weakest areas.

Read the right-hand column again. Almost every trap is either the right activity at the wrong stage, or a tool chosen instead of a root-cause fix. That observation is the core of the method you will learn next.

The "feed it, place it, gate it" method for placing controls

When a question asks where a control belongs, run three short checks. They work for tools you have never heard of, because they rely on what the control needs rather than on its brand name.

1. Feed it. What input does the control inspect? Requirements text, a data-flow diagram, source code, a dependency lockfile, infrastructure templates, a built image, a running application, or live production telemetry. Name the input precisely.
2. Place it. Find the earliest stage in which that input exists. That is where the control should run first. Running it again later is often useful, but the first placement decides where the cheapest feedback happens.
3. Gate it. Decide whether the result blocks progress (a gate), warns the owner (a signal), or opens a ticket (a backlog item). Block only on findings that are high-confidence and high-impact; everything else must still reach an owner with a deadline.

Figure 2 turns the first two checks into a picture. Read each row from left to right: the orange dot marks the earliest stage where an input exists, and the grey dots show where it is still available for re-checking.

Solved scenario: which control belongs in which pipeline stage?

Here is a complete case of the kind you will see, in a longer form than any exam item, so that you can watch the reasoning step by step. The company and system are invented for practice.

Scenario. A small team at Example Payments builds pay-api, a containerised REST service that accepts card-payment requests from a mobile app and forwards them to a payment processor. Code lives in a Git repository, a CI system builds a container image on every merge to main, a staging environment receives each new build automatically, and production runs on a managed Kubernetes cluster. Infrastructure (network, database, storage bucket for receipts) is defined in Terraform files in the same repository. The security lead gives you a list of twelve controls and asks you to place each one where it gives the most value, and to say which ones should block.

1. Name each input. Before you place anything, write next to each control what it reads. Threat modelling reads the design; secret scanning, SAST and peer review read source; SCA reads the lockfile; IaC scanning reads Terraform; image scanning, SBOM generation and signing read the built image; DAST reads the running staging service; signature verification and admission policy read the image reference at deploy time; runtime detection reads production behaviour.
2. Find the earliest stage for each input. Use the staircase in Figure 2. Anything that reads source can run on the pull request. Anything that reads the image must wait for the build. DAST must wait for a deployed copy.
3. Decide gate or signal. High-confidence, high-impact checks block: a verified secret, a critical vulnerability with a fix available, a public bucket, an unsigned image. Noisy or context-dependent checks warn and create tickets: medium SAST findings, low-severity library issues.
4. Check for duplicates and gaps. Re-running SCA nightly against the deployed SBOM is not a duplicate – it catches vulnerabilities disclosed after the build. Having no control between "image built" and "image running" is a gap.
5. Write down the owner. Every finding needs a person who can fix it. Placement without ownership produces dashboards nobody reads.

The solution table

Two placements trip up most people. The first is image scanning versus SCA: both look for known vulnerabilities, but SCA reads your application's declared dependencies, while the image scan also sees the operating-system packages inherited from the base image. You need both. The second is signing versus verification: signing at build time is worthless if nothing checks the signature at deploy time. The gate is the verification, not the signature.

What the pipeline looks like in practice

The commands below show one possible implementation with common open-source tools. Tool choice is not what the exam tests; the order and the gates are.

# ---- Stage: Code — every pull request, should finish in a few minutes ----
gitleaks detect --source . --redact                 # secrets in files and history
semgrep scan --config p/default --error             # SAST, non-zero exit on findings
trivy fs --scanners vuln --severity HIGH,CRITICAL --exit-code 1 .   # SCA on lockfiles
trivy config --exit-code 1 ./infra                  # IaC misconfiguration (Terraform)

# ---- Stage: Build — on merge to main, produces the one artifact we ship ----
docker build -t registry.example.com/pay-api:1.4.2 .
trivy image --severity CRITICAL --ignore-unfixed --exit-code 1 registry.example.com/pay-api:1.4.2
docker push registry.example.com/pay-api:1.4.2
syft registry.example.com/pay-api:1.4.2 -o cyclonedx-json > sbom.cdx.json
cosign sign --key cosign.key registry.example.com/pay-api@sha256:<digest>

# ---- Stage: Test — against the deployed staging copy ----
docker run --rm -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://staging.example.com

# ---- Stage: Release — production admits only verified images ----
cosign verify --key cosign.pub registry.example.com/pay-api@sha256:<digest>

Notice three details. Signing and verification use the digest, not the tag, because a tag such as 1.4.2 can be moved to a different image while a digest cannot. The image scan uses --ignore-unfixed so the gate only blocks on problems you can actually fix today; unfixed findings still go to the backlog. And the DAST step runs against staging, never against a system you do not own.

What you should see when a gate works

Suppose a developer accidentally commits a test cloud key in config/settings.py. The secret-scanning job fails, and the report (example output, shortened) looks roughly like this:

Finding:     AWS_ACCESS_KEY_ID = REDACTED
Secret:      REDACTED
RuleID:      aws-access-token
File:        config/settings.py
Line:        12
Commit:      4be2c1d...

WRN leaks found: 1

The job exits with a non-zero status, the required check turns red, and branch protection keeps the merge button disabled. That is the whole point of a gate: the bad change physically cannot reach main without someone consciously overriding the rule, and that override is logged.

If instead the job passes but the key is visible in the file, check three things: whether the scanner ran on the right directory, whether a broad allow-list rule silenced it, and whether the key format is one the scanner recognises. Custom internal tokens often need a custom rule.

Worked exam item: the leaked key and the tempting wrong answer

Now compress the same knowledge into exam form. Read the item, decide, then read the reasoning.

A developer discovers that a production database password was committed to a public repository three days ago. The commit is still in the history. What should the team do FIRST?

1. Rewrite the repository history to remove the commit and force-push.
2. Rotate the password and review the database logs for access since the commit.
3. Add a secret-scanning tool to the pipeline.
4. Make the repository private.

Answer: B. The secret has been public for three days, so you must assume someone has it. Removing it from history (A) or hiding the repository (D) does nothing about copies that already exist in forks, clones or caches. Adding a scanner (C) is the right long-term fix, but it prevents the next leak, not this one. Rotating the credential is the only option that makes the leaked value useless, and reviewing logs tells you whether it was already used. History clean-up and the scanner come afterwards.

The pattern generalises: in a "FIRST" question about an exposed credential, invalidate it before you tidy up. Exams frequently place the tidying step first in the list, because it feels responsible.

Exam angle: how these topics are asked and the classic traps

Once you have the map and the method, the remaining skill is reading questions the way the examiner wrote them. A few patterns cover most DevSecOps items.

Five traps worth memorising

Common reasoning errors of experienced candidates

People who already work in software delivery often lose points not through lack of knowledge but through habits from their own company. Watch for these.

• Answering for your tool stack. The exam does not care that your CI system calls it a "workflow" or "pipeline". Translate every option into the generic stage it describes.
• Picking the most technical option. When two answers both work, the one that addresses policy, ownership or root cause usually wins over the clever configuration tweak.
• Over-reading the scenario. If the question does not mention a budget problem, do not invent one. Use only the facts given.
• Ignoring the word "MOST". Several options may help. Only one helps most, typically the one that removes the risk rather than reducing its likelihood a little.
• Forgetting people. Training developers, appointing security champions and writing secure coding standards are legitimate controls, and they appear as correct answers more often than engineers expect.

Your study plan: 4, 8 or 12 weeks

Choose the plan that matches your starting point. If you already ship code through a CI/CD pipeline every week, four focused weeks can be enough. If you know security well but have never maintained a pipeline, or you are a developer new to security, take eight. If both worlds are new, twelve weeks with steady practice will serve you far better than cramming. All plans share one rhythm: learn a domain, answer its Check-yourself questions, and revisit earlier domains before they fade.

The split above is a starting point, not a rule. After your first round of Check-yourself questions, move time toward whichever domain cost you the most points. Spaced repetition beats rereading: a question you answered wrong three days ago is worth more study time than a chapter you already understand.

Check yourself: six exam-style questions

• Read the qualifier – tell EARLIEST, BEST, FIRST and MOST LIKELY questions apart before reading the options
• Use the map – name the seven SDLC stages and at least two controls for each
• Feed it, place it, gate it – place any control by its input and decide whether it blocks
• Separate look-alikes – SCA versus image scanning, signing versus verification, SBOM versus scan
• Handle a leaked secret – revoke and rotate first, then investigate, then clean up and prevent
• Spot the traps – tools instead of root cause, blocking everything, CVSS as priority
• Pick a plan – choose the 4, 8 or 12-week schedule and put the first week in your calendar

Glossary