That’s when you realize your GitHub CI/CD controls failed. Worse, someone used break-glass access—and you have no clear trail to follow.
Break-glass access is the sharpest double-edged sword in engineering. It’s the override you allow when critical systems lock down, a failsafe to keep the lights on. When tied to GitHub CI/CD pipelines, it can bypass branch protections, revert security policies, and push code directly to production. If you’re not ready for it, break-glass will turn from a safeguard into a breach vector.
The first step is visibility. Know exactly when, why, and by whom break-glass access is initiated. Logging isn’t enough—you need active alerts that trigger the moment CI/CD controls are skipped. Passive monitoring means you’ll discover problems hours too late.
The second step is policy hardening. Define clear rules for break-glass events. Restrict who can trigger them in GitHub Actions or other orchestrators. Keep these permissions separate from normal role-based access, with time limits that auto-expire. Never let break-glass linger in an “on” state.