DevSecOps Fundamentals · Module 12 of 12

Capstone — secure source-to-deploy pipeline

Design and validate a release evidence bundle that proves the expected source, scans, SBOM, vulnerability disposition, artifact identity, signature/provenance, policy decision and deployment verification.

Learning objectives

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

Assemble security evidence around one immutable artifact.
Reject a deliberately incomplete or inconsistent release bundle.
Defend a release decision and rollback path from evidence.

Evidence must agree

The capstone fails if build, scan, SBOM, signature or deployment refer to different digests.

A secure pipeline can still stop

Tool failure, missing evidence, policy violation and expired exception are distinct non-pass states.

Recovery is part of release engineering

A production security gate needs known-good rollback evidence and post-deployment verification.

Worked example

Capstone contract

source_commit → findings → artifact_digest → SBOM → vulnerability disposition → signature/provenance → policy decision → deploy digest → rollback digest

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

Core lab · account-free

Lab 12 — Prove a release evidence bundle

Goal: Validate a production-shaped security evidence manifest and reject broken variants.

Before you start

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

STEP 1

Copy example bundle

cp labs/devsecops-capstone/release.example.json /tmp/devsecops-release.json

STEP 2

Run validator

python3 labs/devsecops-capstone/validate_release.py /tmp/devsecops-release.json

STEP 3

Break the digest

python3 - <<'PY'
import json
p='/tmp/devsecops-release.json';x=json.load(open(p));x['deployment']['digest']='sha256:tampered';json.dump(x,open('/tmp/devsecops-release-bad.json','w'))
PY
if python3 labs/devsecops-capstone/validate_release.py /tmp/devsecops-release-bad.json; then echo 'ERROR: broken release accepted'; exit 1; else echo 'Expected rejection'; fi

Verify

Good bundle passes.
Digest drift fails.
Required evidence, exception expiry and rollback controls are enforced.

Expected outcome

The learner can explain why each evidence object exists and which decision it supports.

Diagnose / troubleshoot

Read the validator error literally: missing evidence, digest mismatch, unauthorized exception or rollback gap are different failure classes.
Do not “fix” a failing capstone by deleting the check; repair the evidence relationship.

Real-world connection

A release gate is credible when another engineer can reproduce the decision from retained evidence.

Optional real-tool lab

Optional tool lab — assemble real reports

Substitute approved local Gitleaks/Semgrep/Trivy/Syft/Grype/Cosign evidence for synthetic capstone fields.

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

gitleaks version 2>/dev/null || true

TOOL 2

semgrep --version 2>/dev/null || true

TOOL 3

trivy --version 2>/dev/null || true

TOOL 4

syft version 2>/dev/null || true

TOOL 5

grype version 2>/dev/null || true

TOOL 6

cosign version 2>/dev/null || true

Capstone rubric

Score evidence, not confidence.

Threat/control/evidence model · 15%

Threats map to preventive/detective/recovery controls with owners and evidence.

Secrets and source security · 15%

Secret handling, SAST evidence and remediation decisions are explicit.

Artifact vulnerability posture · 15%

Final artifact inventory, scan context and vulnerability disposition are tied to one digest.

SBOM and supply-chain evidence · 15%

SBOM, signature/attestation and provenance identity are linked to the release artifact.

CI/CD identity and permissions · 15%

Workflow permissions are least privilege and external access uses short-lived identity where appropriate.

Policy and exception governance · 15%

Pass/fail/error/exception states are deterministic, owned and auditable.

Runtime verification and recovery · 10%

Deployment verifies the approved digest and includes rollback plus feedback actions.

Avoid these traps

Common mistakes

Accepting evidence that refers to different artifacts.
Treating an expired exception as valid.
Having no known-good rollback identity.

Knowledge check

Can you connect the finding to the control?

Three concept checks plus one scenario check.

1What is the capstone’s central invariant?

All artifact-specific evidence must refer to the same immutable release digest.

2Why retain scanner/tool versions?

Detection behavior depends on rules, databases and tool versions; provenance helps reproduce decisions.

3What should happen when required evidence is unavailable?

Use the explicit error/fail-safe policy rather than treating it as a clean result.

4Scenario: all scans pass but deployment uses a different digest. Is the release approved?

No. Artifact identity drift invalidates the evidence chain and must block/review deployment.

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.