A change reached production without passing the pipeline's required security-scan gate. How do you work out how it got there, and how would you design gates so that route is closed?

## Start at the target, not at the pipeline The instinct is to open the pipeline and read the YAML. Start one step later instead: at the deployment record on the environment itself, or failing that at the target's own audit log — the cloud provider's control-plane log, the cluster's audit trail, the registry's push history. That record answers the first question that actually partitions the investigation: **which identity performed this deployment?** If the identity is not the delivery pipeline's, the pipeline was never involved. Someone with standing credentials pushed the change directly. No gate written inside a pipeline can constrain a path that does not go through the pipeline, and adding another check is a non-fix. This case is more common than teams expect, because break-glass credentials issued during a past incident are rarely revoked. If the identity *is* the pipeline's, you have a run to inspect, and the question becomes why the gate did not stop it. ## The ways an in-pipeline gate fails to apply **It was not wired to this path.** The gate is attached to the pull-request workflow but the release runs on a tag; or it is conditioned on the default branch and the hotfix went out from a release branch; or it runs only for one directory in a monorepo and this change lived elsewhere. This is the single most common cause: the gate exists and works, on a route this change did not take. **It ran and failed open.** The step is set to continue on error so tool outages do not block releases; or the scanner's exit code is discarded by a shell pipeline whose status is its last command's; or the command exits 0 while writing findings to a report nothing reads. The step is green and the gate is decorative. **It was self-modifiable.** If the gate lives in the repository's own pipeline definition, a change can remove or weaken the gate in the same commit that needs to pass it — the change under review is also the change to the control reviewing it. This is why gate definitions belong in platform-level or organisation-level policy, evaluated outside the repository's control, or at minimum in a file requiring separate ownership approval to edit. **It was bypassed with sanctioned machinery.** A break-glass or emergency-deploy path exists, was used, and produced a record that looks like any other approval. If emergency use is not distinguishable from routine use at query time, nobody can tell you how often it happens — and in practice it becomes the fast lane. **The artifact was not the scanned artifact.** The gate scanned a build, and the deploy stage rebuilt from source or pulled a mutable tag that had since moved. The scan was truthful about something that is not what is running. ## Making the finding durable The design conclusions follow directly from the causes. *Only the delivery identity may write to production.* Humans hold no standing credentials to the target; the pipeline's identity does, and it is short-lived. This is the control that makes the deployment record complete, and therefore the one that makes every other gate meaningful. Without it your gates are advice offered to people who can ignore them. *Enforce gates where the change cannot reach them.* Organisation or platform policy, environment protection rules, or an admission control point in front of the target — anywhere that is not a file the change can edit. *Fail closed everywhere.* A gate whose tool failed must block. Assert exit codes explicitly rather than trusting a pipeline's default, and treat "the scanner did not run" as a failure result rather than an absence of a failure result. *Bind the gate to an immutable artifact identity.* The thing deployed must be the exact thing scanned, referenced by content digest or an equivalently immutable identifier, so a rebuild cannot silently substitute for it. *Make the emergency path loud.* Break-glass should be a distinct, obviously-labelled mechanism that notifies a channel, opens a record automatically, and is reviewed afterwards. It should stay available — removing it just pushes people back to direct credentials — but its usage rate is a metric someone reads. ## The organisational half One bypass is an incident; a *rate* of bypasses is a design signal. If the emergency path is used weekly, the gate is too slow, too flaky, or asks for something teams cannot supply, and the correct response is to fix the gate rather than to tighten the exception. Investigations that end with "we reminded the team of the policy" close the ticket without closing the path.