The Security Gate Is in the Pipeline. The Releases Go Around It.

Every bypass was a reasonable call at the time

Every one of these paths was opened deliberately, by somebody solving a real problem in front of them. The gate goes in, it blocks on what it was configured to block on, and for a while every release passes through it. Then the ordinary pressures arrive.

An incident starts at 2am. The person on call has a customer outage behind them and a queue in front of them, and somebody adds a flag that skips the check for that build. That was the right call that night. The flag survives because switching it off is a decision, and that decision needs an owner and a date before anybody takes it.

A legacy service cannot run the check inside its build, which was assembled years before the standard the check was written against. Blocking its releases would stop work on a system the business runs on, so it gets an exemption in a configuration file that one team reads. Elsewhere a team has a deployment the first pipeline cannot handle, so they stand up a second one. It ships, and connecting it to the gate stayed on the list of projects waiting for a budget.

On a platform where the checks are required at the merge boundary there is a faster path still. Somebody with administrative permission waives the required checks on a single pull request and the merge proceeds. It takes one click, it can be entirely the right call, and its record lands in the platform audit log, a long way from the build system.

Each of those was a competent person responding to a real constraint, not an act of subversion. Together they decide which releases the gate sees, and that set drifts away from the set that carries the risk.

• An emergency flag added during an incident, still in place because switching it off is a decision waiting for an owner
• An administrative override at the merge boundary, where somebody holding the permission to waive the required checks does so on a single pull request
• An exemption for a service whose coverage decision is still owed, held in a configuration file that sits outside the review cycle
• A promotion out of an artifact registry, where the check ran on the original build and the artifact that shipped is several promotions downstream of it
• Manual deploys from a console, whose only record sits in the platform audit log

The paths show up on the deployment side

A build pipeline is authoritative about the builds that ran through it, and a release that took another route is recorded wherever it did run. So the reconciliation starts from the other end, in what was deployed.

Take every deployment into a production environment across a trailing window. For each one, find the artifact, the build that produced it, and whether the check ran. Where provenance is complete the row resolves itself. The rows that stall sort into three groups: a build that skipped the check under a flag, a build that ran in a system outside the gate's reach, and a deployment whose artifact traces back to no build record at all.

That third group splits again. Where a running workload has no recorded link back to a source build, the finding is a provenance gap, and the work is instrumenting the build to record what it produced. Where the build ran somewhere else, the finding is a second pipeline, and the work carries an engineering cost and an owner. The Secure Software Development Framework asks organizations to maintain provenance data for the components of each release, which is what makes this reconciliation possible.

Estate discovery is where CWS argues this reconciliation belongs, and the one discovery CWS has run at that scale covered roughly 6,300 repositories. Interviews cannot be relied on to surface bypass paths, because from inside a team the path is simply how their releases have always shipped, which is what makes it invisible to a question about exceptions. The inputs are mostly systems the organization already holds.

• Deployment records for every production environment over a stated window, including anything deployed by hand
• Artifact provenance linking each running workload back to the build that produced it
• Build records showing whether the check ran, was skipped or was waived, and who triggered the build
• The configuration holding exemptions, exclusions and allowlists, read as a list of decisions
• Every build system in the estate, including the one predating the current standard and the one that arrived with an acquisition

Whatever route a release took, it arrives in the deployment record. That shared endpoint is where a bypass becomes visible.

Zero exceptions is the wrong target

The instinct on reading the list is to close every item on it. CWS argues the other way, and the argument sits in the text below because it is ours: closing them all is the expensive move, and the safety it buys is smaller than it looks.

The pressure that produced each path is still in the building. The next incident will still need a fix in production, and the legacy service will still be a legacy service. Close the documented path and the next person under the same pressure finds another one. The first path had a flag with a name attached and a log entry behind it. The second is a token and a deploy script on somebody's laptop.

A bypass that sits in a register is part of the operating model. It has a scope, an owner, a date, and a count of how often it fired. A bypass nobody wrote down carries the same traffic and offers none of that. So the target is a small number of visible paths, each owned, each with a date it stops working. Zero is a number that gets reported, and the pressures underneath it go on finding quieter routes.

Keeping the paths visible pays twice. Each entry marks a place where the way the organization ships and the way it governs are pulling against each other, and that is a thing somebody can put an estimate against.

• A bypass that fires on most releases of one service says something about how well the control fits that team's delivery, and the fit is the finding
• An ecosystem exemption is a coverage decision waiting to be funded, now carrying a scope and a cost
• A second pipeline either gets the same gate or gets a retirement date, and the register is where that gets settled
• A path whose owner has to be established is the finding, ahead of anything about the check itself

Every bypass in the register is also a budget line, which is the second reason to keep one.

Sorting the paths into decisions

A reconciliation produces a list, and the list starts working once each row carries a decision. Three decisions cover the ground: the path closes, the path stays and something else covers it, or the path stays with a date on which it stops working.

Closing fits where the constraint that produced the path has expired. The legacy service was migrated, the second pipeline can run the check now, the artifact promotion can be instrumented to carry its provenance forward. Those rows are engineering tickets, and they leave the register when the ticket closes.

Covering fits where the constraint is durable. A service that cannot run the check inside its build can be checked after deployment, on a schedule, with the report going to a named reader. The path stays open and something is watching it.

A date fits the rest, because it puts the row back in front of somebody on a day that arrives whether or not anyone is paying attention. What an entry has to carry, and what renewing one should cost, are questions that belong to the exception register as a whole. The field a bypass entry adds to that register is a count: how many releases used this path since it was approved. That count does most of the sorting.

• A path used once, during the incident it was created for, which is a closure waiting to be scheduled
• A path used on most releases of one service, which moves the decision into pipeline design
• A path used by several teams, which has become infrastructure, and the entry is now a coverage decision with a budget attached
• A path whose firing count has to be reconstructed by hand, which makes instrumenting the record the first decision

The emergency path and the two numbers

One path resists all three decisions, and it is the one that opens at 2am. An incident will need a fix in production faster than the checks can run, and a program that assumes otherwise gets routed around at the moment it matters most.

Design it to be quiet at 2am and loud the next morning. The person on call uses it alone, and the record reaches a review queue by itself, carrying the build, the person and the reason. The review happens inside a window stated in advance, so the follow-up is already scheduled when the morning arrives.

Every register drifts in the same direction. Entries get added under pressure and renewed by default, because refusing a renewal means telling a team it cannot ship this week. Left to that, a register converges on permanence, and a permanent register describes the estate while the estate goes on as it was. What holds it in place is that renewal costs something, and that is a subject of its own.

Two numbers go upward: how many bypass paths exist, and how many releases used one this period. The second is the one that moves. A count climbing quarter over quarter says a control is fighting the way the organization ships, which is worth knowing while it is still a conversation about pipeline design. New paths appear the way the first ones did, one reasonable decision at a time, so the reconciliation runs again.

• An emergency path that is easy to use during an incident and automatically visible afterward, reviewed inside a stated window
• A firing count on every entry, since a path used weekly and a path used once a year are different decisions wearing the same label
• A re-run of the deployment reconciliation on a schedule, with the window and the method recorded alongside the result

The number that matters is how many releases went out around the gate, and only the deployment records can produce it.