A Gate You Can Bypass Is Not a Gate

The interesting failure in DevSecOps is not the breach. It is the audit.

A team has done the work. There is static analysis on every pull request, software composition analysis on every build, a container scanner, a secrets scanner, a dynamic scanner against staging, an annual penetration test, and a dashboard that is mostly green. Twelve tools, honestly bought and honestly run.

Then the assessor asks four questions.

Show me the list of applications this applies to. Show me a release that was stopped by a security gate. Show me every open Critical finding across all sources in one place, with one clock running against it. Show me the evidence that gate three was passed on the last release, without anyone taking a screenshot for you.

The programme cannot answer. Not because the engineering is bad, but because the engineering was never wired into anything that produces proof. This is the gap between doing security and being able to demonstrate it, and in a regulated environment only the second one counts.

Below are the four structural failures I see most often, and what each one has to be replaced with.

Failure one: the gate that is not a gate

Most pipelines have something called a security gate. Very few have a gate.

A gate has exactly three parts. Remove any one and it degenerates into something that looks like governance and is not.

The third part is where most programmes quietly fail. The scanner runs, the finding is raised, the release goes out anyway, and nothing in the system records that a decision was taken to accept it. A year later nobody can say whether that release was an exception or the norm, because bypass left no trace.

So the test is not whether you have gates. It is whether you can produce a release that a gate stopped. If you cannot, the gates are advisory, whatever the pipeline configuration says.

And the corollary matters just as much: a gate that can never be bypassed will be routed around by the business instead. The answer is not an unbreakable gate, it is a recorded exception. A time-bound waiver, with a named approver at a level matched to the severity, an expiry date and a compensating control, is a healthy gate operating as designed. An undocumented bypass is a broken one.

Failure two: five registers pretending to be one

Ask where the security findings live and count the answers.

Static analysis findings sit in the scanner. Penetration test findings sit in a report and a tracking spreadsheet. Cloud posture findings sit in the cloud console. Bug bounty submissions sit in the platform. Findings from the last incident sit in the incident record. Each has its own severity words, its own idea of when the clock started, and its own owner.

This is the failure that makes the other three unfixable, because it destroys the ability to say anything true about the whole. “How many open Criticals do we have?” has five answers, none of which is wrong.

One register, one taxonomy, one clock. The clock is the part people underestimate. If the service level starts when the ticket is created rather than when the finding was detected, every backlog looks healthy, because the delay moves into the gap between detection and triage where nothing is measured.

Email deserves a specific mention. If a finding can be handed over by email, it will be, and a finding communicated only by email has not been communicated. It has been mentioned to one person who may be on leave. Retire the channel and the register becomes the only route, which is the point.

Failure three: coverage without a denominator

“We scan one hundred per cent of our repositories” is a sentence that sounds like assurance and contains none.

One hundred per cent of which repositories? The ones connected to the scanner. That is a numerator being reported as a ratio. The question the assessor is actually asking is what proportion of the applications the organisation runs are covered, and answering it requires a denominator that the security function does not control and usually does not have: an approved inventory of applications.

This is uncomfortable because the gap is the whole point. The applications that are not in the inventory are, by definition, the ones that have never been scanned, never been threat modelled and never been through a gate. A coverage figure computed against the connected repositories hides exactly the population you most need to see.

It also changes who owns the problem. Building an approved application inventory is not a security tooling task. It is an ownership task, and it usually surfaces a dozen systems that no named person will claim.

Failure four: evidence that a human had to assemble

The last failure shows up only under audit, which is why it survives so long.

Ask how a team proves that a given release passed its security gates, and the honest answer in most organisations is that somebody goes and collects it. They open the scanner, filter by date, screenshot the result, export the approval email, and paste it all into a folder named after the release.

That is not evidence. It is reconstruction, performed by an interested party, after the fact. It also does not scale: it is tolerable for the four releases an assessor samples and impossible for the four hundred that actually shipped.

Evidence has to be a by-product of the pipeline. The gate decision, the scan result it was based on, the identity of the approver and the timestamp are emitted when the gate runs, into a store the delivery team cannot edit. If producing your audit pack takes a person a week, you do not have an evidence model. You have an archaeology project.

What good looks like

Four replacements, in the order I would sequence them.

1. Build the inventory first. Everything else is measured against it. Until it exists, every coverage number you report is a number about your tooling. Expect this to be the slowest step and the one that requires the most political capital, because it is fundamentally about who owns what.

2. Consolidate to one register. One severity taxonomy, one clock that starts at detection, one accountable owner per finding, one exception route. Retire the side channels, email included.

3. Give every gate its third part. Define the break criteria by severity in advance, wire them into the pipeline, and build the waiver route at the same time so that the pressure has somewhere legitimate to go. A gate without a waiver process gets disabled within a quarter.

4. Make the pipeline emit the evidence. If the gate decision is not written to an immutable store at the moment it is taken, it will be reconstructed later by the person with the most to lose from it looking bad.

Notice that none of the four is a tool purchase. Every organisation I have worked with that failed an application security assessment already owned the tools. What they lacked was an inventory, a register, an enforceable decision point and a record.

The bottom line

DevSecOps is usually sold as a speed story, and it is one. But the reason it survives contact with a regulator is different. It is that a pipeline, unlike a person, produces a defensible account of what happened on every single release, not just the ones somebody thought to document.

A control that depends on somebody remembering to run it is not a control. A gate you can bypass without leaving a trace is not a gate. And a metric without a denominator is not a measurement, however green the dashboard looks.

Here is the question I would put to your own programme this week. Can you name the last release that a security gate stopped, and produce the record without asking anyone to go and look?

If the answer is no, the tools are not the problem.