The team in this story is invented; the mechanics of what happened to them are not. Call them the Ledger team — eight engineers maintaining a payments-adjacent service, two-week sprints, a build pipeline nobody had opened the settings of in a year. Over one quarter they collected a leaked cloud key, a dependency scare, and a delivery audit they had been postponing since spring. What they changed afterwards is a working portrait of DevSecOps, told here as it unfolded rather than as a framework diagram.
Tuesday, 09:40: the key that travelled
It started with a routine alert from a public-repository monitor: a string resembling an access token had appeared in a customer’s gist, pasted during a screen share that was recorded and published. The token belonged to the Ledger team’s CI system. Anyone holding it could trigger builds and read cached artefacts. The engineer who spotted it did the correct first thing and the incorrect second thing in the same hour — she told the channel, then opened a ticket titled “key issue, low priority”.
Her lead reordered the priorities within minutes. The sequence for a leaked credential is rotate first and rewrite history second: issue a replacement, revoke the old value everywhere, and only then scrub the repository, because a history rewrite of a still-live key protects nothing. The team later learned their platform’s push protection could have caught the paste at commit time, had anyone switched it on — and that the bypass button for that protection is, by default, available to any writer on the repository. Both settings were fixed that afternoon. DevSecOps practice, at its most basic, is exactly this: scanning at the developer’s desk and at the server, so a secret gets two chances to be caught, plus a rotation runbook nobody has to improvise.
The review that refused to hunt for a villain
The post-incident review took an hour and assigned zero blame, which surprised the newer hires. Instead of asking who pasted the token, the group modelled the threat properly — the short, structured kind, not the fortnight-long workshop they had always assumed security work required. A forty-five-minute playbook exists for exactly this scale of session: sketch the change, walk the STRIDE categories (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege), and answer the four questions from the Threat Modeling Manifesto — what are we building, what can go wrong, what are we doing about it, and did we do a good enough job?
The session produced three findings the team could actually act on. The CI token was scoped too widely. The pipeline ran on a single long-lived credential rather than short-lived identity tokens. And nobody could say, with evidence, which of their dependencies had been in the last release. That third finding rankled. “We build this thing every day,” someone said. “Doesn’t the build know what it built?” It knew; nothing retained the answer.
The DevSecOps answer: evidence, not memory
The fix for that third finding is the supply-chain half of DevSecOps. Each release now carries three artefacts: an inventory of every bundled component — the software bill of materials — plus a cryptographic signature and a provenance statement naming the pipeline that produced the build. The SLSA framework grades how much weight those claims can bear. Build levels run from L0 (no guarantees) to L3 (hardened, isolated builds), source platforms sit on their own L1–L4 ladder, and GitHub’s artifact attestations correspond to Build L2, reaching L3 only where reusable workflows are pinned. One rule survived every debate in the room: the evidence gets verified at deploy time, not merely collected, because a signature minted last Monday says nothing about what Friday’s build actually contains — and a compromised build machine will happily sign fiction.
The dependency scare arrived, as these things do, without waiting for the roadmap. In March 2024 the XZ Utils backdoor — CVE-2024-3094 — landed in downstream distributions before anyone outside the attacker’s orbit understood what they were looking at, and CISA’s guidance to operators was to downgrade to 5.4.6 while the situation clarified. The Ledger team was not directly affected. What the episode changed was their reading of their own inventory: with an SBOM in hand, answering “are we exposed?” took eleven minutes; their pre-SBOM estimate for the same question had been “about a day, probably”. Speed of response, not prevention, is what that inventory buys you — the attacker chooses whether to strike, the SBOM chooses how fast you can see.
What changed in the pipeline itself
Hardening the machinery took two sprints and mostly meant deletion. The list from the retrospective:
- Third-party build actions pinned to full commit SHAs, so an upstream force-push can no longer rewrite the team’s build out from under them.
- Per-job permission scopes, each runner granted the least it needs and nothing more.
- Federated identity replacing the stored cloud key — credentials now exist for the length of one job.
- Secrets disabled entirely for builds arriving from forked repositories.
- The pull_request_target trigger, which runs contributor code with privileged access, removed after a five-minute reading of what it actually permits.
Those moves track the OWASP top-ten catalogue for CI/CD failures, and none of them required buying anything. The team’s reading of the subject afterwards began with the DevSecOps page in the Ops Atlas, which names the same hardening moves and the reasoning behind each.
The gate, and the argument it settled
One policy decision did more for the team’s mood than any scanner. When the first round of analysis tooling went live, it ran in report-only mode for a fortnight while the group measured how often each rule was actually right. Two rules earned the right to block outright; a dozen became advisory tickets; one — a style-adjacent check that fired on half the codebase — was switched off entirely, to quiet applause from the whole channel. Enforcement arrived only after that calibration.
The first week of real enforcement blocked three merges. All three authors fixed their code within the hour, because the findings were genuine and the repairs were obvious. Nobody routed around the gate, since routing around evidence is a hard argument to win at review. The contrast with the team’s previous arrangement was hard to miss: a quarterly report once landed with forty findings of unknown accuracy and no owners, was skimmed, forwarded, and forgotten. Findings now arrived in small numbers, each either blocking with a stated reason or ticketed with a deadline, and the ninety-day expiry meant no exception could quietly turn permanent. Same codebase, same eight people — the difference was where the checks sat and who answered for the output.
What DevSecOps looked like a quarter later
By the end of the next quarter, the Ledger team’s version of DevSecOps looked like this. Two engineers held a written charter as security champions, with a tenth to a fifth of their sprint ring-fenced for the work — enough to keep the scanning rules tuned and the exceptions tracked, not enough to become a bottleneck. The merge gate blocked only on fresh, serious, high-confidence findings; everything else became a ticket with a name and a ninety-day clock, and the backlog of old debt stayed out of the merge path entirely. Rules whose false alarms outran their catches were demoted to advisory status rather than argued about monthly.
Delivery speed, the thing everyone feared sacrificing, was unchanged by any measurement they had. The security work lived inside the pipeline they already ran — which is the whole idea. For readers building the underlying skills, the path runs through general delivery practice first: a calm DevOps learning guide for the foundations, structured SRE training for the reliability instincts that incident response reuses, and the complete DataOps guide for teams whose pipelines move data rather than binaries. The Ledger team’s story is fictional. The two choices that defined it — rotate before rewriting, verify at deploy rather than at signing — are the field’s standard advice, and both were learned the expensive way by real teams before they were written down.
