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

Runtime verification, feedback and response

Connect pre-deployment security evidence to runtime detection, admission/verification, incident response and backlog improvement.

Learning objectives

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

  • Explain why shift-left does not replace runtime security.
  • Verify deployed artifact identity against release evidence.
  • Feed incidents and runtime findings back into source, policy and tests.

Runtime is a new evidence boundary

Configuration drift, compromised credentials, exposed services and new vulnerabilities can appear after build. Runtime verification complements pre-release controls.

Verify what actually ran

Record image digest, deployment identity, policy/admission result and relevant runtime configuration so responders can compare intended and actual state.

Feedback closes the loop

An incident should improve threat models, detector rules, tests, runbooks or policy—not end with a one-time patch.

Worked example

Release-to-runtime evidence

approved digest → admission/verification → deployed digest → runtime telemetry/finding → response → control improvement
  • Connect each finding to a concrete risk and control.
  • Preserve evidence so a reviewer can reproduce the decision.
Core lab · account-free

Lab 11 — Detect deployment drift

Goal: Compare approved and observed runtime evidence.

Before you start

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

Create records

cat > /tmp/runtime.json <<'EOF'
{"approved_digest":"sha256:good","running_digest":"sha256:good","signature_verified":true,"critical_alerts":0}
EOF
STEP 2

Verify normal state

python3 - <<'PY'
import json
x=json.load(open('/tmp/runtime.json'))
assert x['approved_digest']==x['running_digest'] and x['signature_verified']
print('runtime matches approved release')
PY
STEP 3

Reason about drift

If the running digest differs, define containment, evidence capture and rollback steps before changing state.

Verify

  • Approved and running digest are compared.
  • Response includes evidence capture before destructive remediation.

Expected outcome

  • The learner connects release evidence to incident response.

Diagnose / troubleshoot

  • If runtime identity is unknown, collect deployment/audit evidence before assuming compromise.
  • If a new CVE appears, rescan retained SBOMs and prioritize exposed running instances.
Real-world connection

DevSecOps is complete only when runtime learning changes future delivery controls.

Optional real-tool lab

Optional tool lab — Kubernetes verification concept

Inspect an approved image digest in a disposable manifest without requiring a cluster.

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
printf '%s\n' 'image: registry.example/demo@sha256:abc123' > /tmp/deploy.yaml
TOOL 2
grep '@sha256:' /tmp/deploy.yaml
Avoid these traps

Common mistakes

  • Assuming pre-deploy scans make runtime detection unnecessary.
  • Changing production before preserving evidence.
  • Closing an incident without improving a control or test.
Knowledge check

Can you connect the finding to the control?

Three concept checks plus one scenario check.

1Why is runtime verification still needed?

Runtime state and threat intelligence can change after build and deployment.

2What should you compare during artifact verification?

The approved immutable digest/signature policy with the artifact actually deployed.

3What should incidents feed back into?

Threat models, detector rules, tests, policy, runbooks and ownership.

4Scenario: production runs an unsigned digest different from the approved release. What is the priority?

Treat it as integrity drift: preserve evidence, contain according to incident policy, and restore a known approved artifact.

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.