DevSecOps Fundamentals · Module 10 of 12

Secure pipeline design and artifact promotion

Compose security controls into a source→build→artifact→promote flow that scans once, promotes immutable artifacts and separates build from deploy authority.

Learning objectives

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

Order controls to give fast feedback without weakening final evidence.
Promote the same immutable artifact across environments.
Separate build identity, artifact registry permissions and deployment authority.

Scan early, prove late

Fast developer checks reduce feedback time; release gates should operate on the exact built artifact and retained reports.

Build once, promote by digest

Rebuilding per environment changes the artifact and invalidates earlier evidence. Promote immutable digests instead.

Separate duties in automation

The identity that builds does not need unrestricted production deployment authority. Environment approvals and scoped roles reduce blast radius.

Worked example

Pipeline flow

source → secret/SAST → build → image scan → SBOM → sign/attest → policy gate → promote digest → deploy verify

Connect each finding to a concrete risk and control.
Preserve evidence so a reviewer can reproduce the decision.

Core lab · account-free

Lab 10 — Validate promotion invariants

Goal: Ensure scan/sign/deploy evidence refers to the same artifact digest.

Before you start

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

STEP 1

Create evidence

cat > /tmp/promotion.json <<'EOF'
{"build":"sha256:abc","scan":"sha256:abc","sbom":"sha256:abc","signature":"sha256:abc","deploy":"sha256:abc"}
EOF

STEP 2

Check invariant

python3 - <<'PY'
import json
x=json.load(open('/tmp/promotion.json'))
assert len(set(x.values()))==1
print('same immutable artifact promoted')
PY

STEP 3

Break it deliberately

python3 - <<'PY'
import json
p='/tmp/promotion.json';x=json.load(open(p));x['deploy']='sha256:different'
assert len(set(x.values()))>1
print('policy correctly detects artifact drift')
PY

Verify

All normal evidence shares one digest.
The deliberate drift is detected.

Expected outcome

Promotion integrity is demonstrated.

Diagnose / troubleshoot

If an environment rebuilds the image, stop and compare digests before trusting prior scans.
If deployment needs broad registry write access, split publish and deploy roles.

Real-world connection

Immutable promotion lets production verification reuse the evidence generated for the artifact that was actually approved.

Optional real-tool lab

Optional tool lab — GitHub Actions design review

Review an existing training pipeline for scan/build/SBOM/sign/promote ordering.

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

find .github/workflows -type f -maxdepth 2 -print 2>/dev/null || true

Avoid these traps

Common mistakes

Rescanning a different rebuild and calling it equivalent.
Letting the same broad token build, sign and deploy everything.
Signing before the final artifact exists.

Knowledge check

Can you connect the finding to the control?

Three concept checks plus one scenario check.

1Why build once and promote?

It preserves artifact identity so scan/SBOM/signature evidence still refers to what is deployed.

2Where should image scanning occur?

On the final built artifact before promotion, in addition to earlier source/dependency checks.

3Why separate build and deploy authority?

It limits blast radius and supports independent environment policy.

4Scenario: staging rebuilds the image from the same commit and gets a new digest. Can production reuse the old signature?

No. Evidence must refer to the exact digest being promoted/deployed.

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

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

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