Compliance at the point of change verifies that required compliance work was completed immediately before a software change enters an environment. It separates doing the work from verifying it, preserving developer self-service while giving governance stakeholders an automated control. section 1.3.3 section 4.1.1
A practical implementation separates responsibilities and places verification at every deployment boundary:
- Provide reusable, versioned pipeline components that perform compliance work, such as vulnerability scanning. section 4.1.1
- Intercept deployments at the first environment and continue verification through production. section 4.1.1
- Verify evidence from an authoritative source instead of repeating the compliance activity. section 4.1.1
- Compare the image commit SHA with a successful vulnerability-scan record before allowing deployment. section 4.1.1
In Kubernetes, an admission controller can implement the control boundary through validating webhooks. The webhook checks deployment requests before they are applied, allowing teams to retain pipeline ownership while enforcing shared guardrails. Gatekeeper can provide a policy implementation, such as checking required deployment labels. section 4.1.1
Figure 4.3 Kubernetes admission controller
Use the admission-controller diagram to trace how deployment interception separates compliance execution from compliance verification. section 4.1.1
