Gnu Group Learning AcademyGnu Group ↗
DevSecOps Fundamentals · Module 01 of 12

DevSecOps mental model and threat-driven controls

Integrate security into delivery by connecting assets and threats to preventive, detective and recovery controls with reviewable evidence.

Learning objectives

By the end of this module, you should be able to:

  • Explain DevSecOps as an engineering feedback loop rather than a scanner collection.
  • Create a lightweight threat model for a source→build→artifact→deploy path.
  • Distinguish finding severity from deployment risk and evidence quality.

Security belongs to the delivery system

DevSecOps integrates security decisions into normal engineering work: source review, build, artifact handling, deployment and runtime feedback.

The goal is fast, repeatable evidence and proportionate controls—not a separate late-stage security queue.

  • Prevent
  • Detect
  • Respond
  • Prove

Threat model before tool selection

Start with assets, trust boundaries, threat events and abuse paths. A tool is useful only when it produces evidence for a relevant control.

  • Asset: source, credential, artifact, deployment identity
  • Threat: secret leak, vulnerable dependency, tampered artifact, over-privileged pipeline

Risk needs context

Severity is one input. Reachability, exposure, exploitability, compensating controls and business impact determine the action.

Worked example

Threat → control → evidence

Threat: tampered release
Control: immutable digest + signature verification
Evidence: digest, signer identity, verification result
Decision: promote only when policy passes
  • Connect each finding to a concrete risk and control.
  • Preserve evidence so a reviewer can reproduce the decision.
Core lab · account-free

Lab 01 — Build a threat/control/evidence map

Goal: Turn a delivery flow into a small security control matrix.

Before you start

  • No cloud account required.
  • Core lab uses bash/Python 3 and local files only.
STEP 1

Create the matrix

cat > /tmp/devsecops-controls.csv <<'EOF'
threat,control,evidence
secret_in_repo,secret_scan,scan_report
tampered_artifact,signature_check,verification_log
overprivileged_ci,least_privilege,workflow_permissions
EOF
cat /tmp/devsecops-controls.csv
STEP 2

Review gaps

For each threat, identify whether the control prevents, detects, or limits impact.

STEP 3

Record one recovery control

printf '%s\n' 'compromised_release,rollback,known_good_digest' >> /tmp/devsecops-controls.csv

Verify

  • Every threat maps to a control and evidence.
  • At least one recovery action is present.

Expected outcome

  • A small reviewable control matrix exists.

Diagnose / troubleshoot

  • If a control has no evidence, define what a reviewer can inspect.
  • If a threat has many controls but no owner, add ownership before adding more tools.
Real-world connection

Production security reviews are faster when evidence is generated by the pipeline that made the change.

Optional real-tool lab

Optional tool lab — inspect workflow security

Review a GitHub Actions workflow for explicit permissions and immutable action references.

Prerequisites

  • Install the referenced open-source CLI only for the optional lab.
  • Use an organization-approved pinned version in real CI; do not blindly use latest.

Cost / risk

  • Expected cloud cost: none. Use only approved repositories and disposable training artifacts.

Warnings

  • Never scan or publish real production secrets in a training lab.
  • Scanner output is evidence for triage, not an automatic statement of exploitable risk.
TOOL 1
grep -R "permissions:" -n .github/workflows 2>/dev/null || true
TOOL 2
grep -R "uses:.*@" -n .github/workflows 2>/dev/null || true
Avoid these traps

Common mistakes

  • Buying tools before defining threats.
  • Blocking every finding regardless of context.
  • Treating security evidence as a one-time audit artifact.
Knowledge check

Can you connect the finding to the control?

Three concept checks plus one scenario check.

1What is the core DevSecOps feedback loop?

Threat or requirement → control → evidence → decision → feedback.

2Why is a scanner result not automatically a release decision?

A finding still needs context such as exposure, exploitability, ownership and compensating controls.

3What does a trust boundary indicate?

Where identity, privilege, data ownership or control changes and threats may differ.

4Scenario: a signed image is promoted but the pipeline uses a long-lived admin key. What remains weak?

Pipeline identity: replace long-lived broad credentials with scoped short-lived identity and least privilege.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.