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 1Create gate input
cat > /tmp/gate.json <<'EOF'
{"secret_scan":"pass","sast":"pass","critical_reachable_fixable":0,"exception":null}
EOF
STEP 2Evaluate
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 3Model 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 connectionGood 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 1python3 -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.