> ## Content Index > Fetch the complete content index at: https://debugly.dev/llms.txt > Use this file to discover other available public pages before exploring further. # The Secret Scanner That Ran After the Push - URL: https://debugly.dev/secret-scanner-after-push/ - Published: 2026-10-09T13:55:00.000Z - Updated: 2026-10-17T05:56:24.000Z - Description: The check that detects the leaked credential ran in CI, which runs after the push, which is after the credential is cloned by every mirror, fork and CI runner. - Author: Rohit Bhadani - Tags: DevOps, Security, Tooling The scanner did its job: it flagged the credential, opened the ticket, and the ticket was worked, and the credential was rotated, and the postmortem called it a success, and all of that was true, and none of it undid the fact that the credential, from the moment of the push to the moment of the rotation, was in the repository, and the repository had been cloned by the CI runners, mirrored by the backup, forked by a contractor, and the rotation makes the credential dead going forward, and says nothing about the copies, which is the half the scanner's success report omits, because the scanner measures detection, and the incident is defined by exposure, and the detection was after the exposure, by the design of the pipeline. This is the argument that a scanner placed after the push is a detector, not a prevention, and that the ordering of the check is the whole of its value, and the ordering was backwards. This was a pipeline whose secret scan ran in CI on the pushed commit, and the credential's exposure window was the push to the rotation, which was hours, which is the number the postmortem should have led with. ## Why after the push is after the fact The push is the moment the credential leaves the developer's machine and enters every system that clones the repository, and the clone is the exposure, because the clone is a copy, and the copy is permanent, per [deleting the commit did not delete the secret](https://debugly.dev/secrets-in-git-history-are-still-there/), and the common root is the property, not the platform. The ordering is therefore the value: a scanner that runs before the push, on the developer's machine, catches the credential at the one moment it exists in exactly one place, and the prevention at that moment has no copies to undo, which is the difference between a detector and a gate, and the gate is the scanner moved left, and the move is the entire fix. ## The layers, left to right The defence in depth for the secret is a sequence of gates, each later than the last, each catching what the earlier missed, and the pipeline's defect was that its only gate was the last one. **The editor and the pre commit.** The scanner as a pre commit hook, or built into the tooling, catches the credential before it enters the commit, which is before the push, which is before the copies, and the pre commit is the gate with the smallest blast radius, because the credential has not left the machine. Its limitation is that hooks are skippable, and a determined or hurried developer skips, so the hook is the first gate, not the only one. **The push gate.** The server side pre receive hook, or the platform's push protection, scans the pushed objects before they are accepted, and rejects the push containing the credential, which is the gate that is not skippable by the developer, because it runs on the server, and the rejection means the credential never enters the repository's history, which is the copies never made, and the push gate is the layer the pipeline lacked, which is the layer between the skippable hook and the too late CI scan. **The CI scan.** The existing scanner, kept, as the detector of last resort, for the credential that passes the earlier gates, a new pattern, a novel encoding, and its finding now triggers the rotation and the audit of the copies, which is its real job, the incident response, not the prevention, and the pipeline's error was treating the incident response as the prevention. **The provider side scanning.** The secret issuer, the cloud provider, scanning for its own credential formats across the public surface, catches the leak the repository gates missed, and the issuer's revocation is the backstop, which is the defence outside the organisation entirely, and the backstop is the last layer, not the first. ## The metric that names the defect The pipeline's health is not the scanner's detection rate, it is the exposure window, the time from push to rotation for a detected credential, and the count of credentials detected after push versus prevented before push, and the ratio is the gate's score, and a pipeline that detects many and prevents none is a pipeline whose gates are all at the end, which is the ordering made visible, and the ratio is the metric the postmortem should have led with, instead of the scanner's success. This is the observability half: the exposure window is the number, and the number is the incident's size, and the number is invisible unless the pipeline records the push time and the detection time and the rotation time, which is the instrumentation of the gate, which is the discipline from [the agent's retry loop rate limited the service](https://debugly.dev/agent-retry-loop-rate-limited/), and the shared property is the one worth fixing. ## What I would do differently I would have drawn the pipeline as a sequence of copies, the machine, the push, the mirror, the fork, the runner, and placed each gate at the boundary between copies, because the boundary is the only place a gate prevents a copy, and the gate after all the copies prevents nothing, only speeds the cleanup, and the drawing makes the ordering defect visible in one diagram, which is the diagram the pipeline's design review never drew. I would also have made the rotation automatic on detection, so the exposure window collapses to the detection latency, because the window is the product of the detection time and the rotation time, and the automatic rotation halves the product without touching the gates, which is the cheap win while the gates are built. ## The rule I keep A secret scanner that runs after the push detects the credential after every clone has copied it, so its finding speeds the rotation but undoes no exposure, and the prevention lives at the gates before the copies, the pre commit hook, the server side push protection, with the CI scan as the detector of last resort and the issuer's revocation as the backstop. The scanner was not broken. It was last, and last is a position, not a quality, and the position is what priced the incident, because the credential's copies were made at the push, and the scanner arrived after the copies. The lesson I keep is the property, not the incident. --- Published on [debugly.dev](https://debugly.dev/) by [Rohit Bhadani](https://debugly.dev/about/) | Founder of [Krova Cloud](https://krova.cloud/?ref=debugly.dev)