DevSecOps Fundamentals · Module 09 of 12

Policy gates, exceptions and evidence

Turn scanner output into consistent promotion decisions with explicit policy, evidence retention, accountable exceptions and fail-safe behavior.

Learning objectives

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

  • Design a gate using clear inputs and outcomes.
  • Define a time-bound exception workflow.
  • Distinguish fail-open, fail-closed and degraded evidence behavior.

Policy should be explainable

A release rule should state what evidence is required, thresholds, ownership, exception path and what happens when evidence is unavailable.

Exception is part of policy

Exceptions are not bypasses when they are scoped, approved, expiring and auditable. They become dangerous when permanent or invisible.

Evidence failure is different from clean evidence

If a scanner fails to run, that is not the same as zero findings. Model unavailable evidence explicitly.

Worked example

Gate states

PASS: required evidence present and policy satisfied
FAIL: policy violated
ERROR: evidence unavailable
EXCEPTION: authorized, scoped, expiring risk decision
  • Connect each finding to a concrete risk and control.
  • Preserve evidence so a reviewer can reproduce the decision.
Core lab · account-free

Lab 09 — Implement a four-state gate

Goal: Evaluate findings and evidence availability deterministically.

Before you start

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

Create gate input

cat > /tmp/gate.json <<'EOF'
{"secret_scan":"pass","sast":"pass","critical_reachable_fixable":0,"exception":null}
EOF
STEP 2

Evaluate

python3 - <<'PY'
import json
x=json.load(open('/tmp/gate.json'))
required=['secret_scan','sast']
assert all(x.get(k)=='pass' for k in required)
assert x['critical_reachable_fixable']==0
print('PASS')
PY
STEP 3

Model outage

Change one evidence source to unavailable and decide whether your production policy should fail closed or route to an authorized emergency process.

Verify

  • PASS is distinct from ERROR/unavailable.
  • Exception fields are explicit rather than hidden in scanner configuration.

Expected outcome

  • A deterministic decision model exists.

Diagnose / troubleshoot

  • If teams cannot explain why a build was blocked, simplify the rule and evidence output.
  • If exceptions never expire, treat that as policy debt.
Real-world connection

Good gates accelerate delivery because engineers know exactly what evidence and remediation are required.

Optional real-tool lab

Optional tool lab — combine scanner reports

Use shell/jq or Python to normalize local scanner outputs into one decision record.

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
python3 -m json.tool /tmp/gate.json
Avoid these traps

Common mistakes

  • Treating scanner outage as a clean scan.
  • Embedding permanent exceptions in CI code.
  • Blocking without a remediation owner.
Knowledge check

Can you connect the finding to the control?

Three concept checks plus one scenario check.

1What are useful gate states?

At minimum pass, policy fail, evidence/tool error, and authorized exception.

2Why must scanner outage be explicit?

Missing evidence is not evidence of absence.

3What makes an exception accountable?

Scope, approver, owner, reason, expiry and retained evidence.

4Scenario: the secret scanner times out but all other scans pass. Is that a clean release?

No. Treat secret evidence as unavailable and follow the defined fail-safe or emergency policy.

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.