Cascadia Flight Academy runs twelve training aircraft, three instructors’ rosters, and one small software team: Priya the lead, Marcus on backend, Tom — three weeks into the job — on everything nobody else wants. Their booking, scheduling, and student-record platform ships a few times a week from a single repository. This is the story of their first quarter with DevSecOps, reconstructed from their sprint notes because the honest version of adoption is never as tidy as a tutorial. It is a fictional composite, but every step in it follows the field’s documented playbook — the same material collected in the DevSecOps reference pages at xOps School — so the story works equally well as a sequence to copy.
Week one: forty-five minutes, four questions
Priya opened the quarter with a threat-modeling session instead of a tool demo. The playbook she followed budgets forty-five minutes for one significant change, uses STRIDE as the lens, and ends on the four questions that have anchored the practice since the manifesto: what the thing is, how it can fail, what gets done about the failures, and whether the work held up. The target was the new online-payment flow for course deposits. Forty-five minutes, one whiteboard, and nine what-ifs — two of which, a payment webhook that trusted unverified callbacks and a debugging endpoint left reachable in production, became that week’s work. Marcus timed it: the whole session cost less than one untimed build. Tom’s notebook entry: “security is just design review with sharper questions.”
Week two: the scanners find an old friend
Next came secret detection, and it struck paydirt on day one: a cloud access key committed fourteen months earlier by an engineer who has since moved on. The runbook Priya had taped above her desk gave the order of operations: rotate the credential first — the value stays live until the key dies, whatever happens to git history — and rewrite history second, since anyone who cloned the repo before the cleanup may still hold a copy. They rotated in twenty minutes. The rewrite took an afternoon and a stiff coffee, and both of them agreed the order mattered: had they started with the history, the key would have stayed live while they tidied evidence. Server-side push protection went on the same day, so the next leaked token gets stopped at the door instead of discovered in an audit fourteen months later. Priya filed the runbook in the team wiki under “read before you need it.”
The report-only month
With the acute problem handled, the team switched everything on — dependency scanning, image scanning, configuration checks — in report-only mode, and let it run for four weeks. The first week was humbling: two hundred and change findings, most of them noise from a scanner misconfigured for their runtime. The point of the quiet month was precisely to learn that before the checks had power to stop anything. Two habits stuck from this phase. First, every build began producing a software bill of materials — a packing list of everything inside each release — because, as Priya put it, “we can’t answer ‘are we affected?’ about components we can’t name.” Second, each rule’s false alarms were counted, and rules that cried wolf were retuned or switched off before they could earn anyone’s contempt. By the fourth week the signal-to-noise had flipped: the findings list read like real work instead of a nag file, which was Priya’s signal that the checks were ready to be trusted with authority.
DevSecOps gates, switched on carefully
In week seven, the team held the gate-policy conversation they had been putting off. The rule they settled on came almost verbatim from the playbook: a check may refuse a merge only when the problem is serious, repairable, confidently real, and arrived with this change. Pre-existing debt never blocks — it goes on a burn-down list instead. Anything short of those conditions becomes tracked work with a name attached. When the gate went live, it refused exactly three merges in the first fortnight, all legitimate, and none was overruled. Marcus, the team’s skeptic, conceded in retro that “it behaves like a preflight checklist, not a cop.” That is the intended character of the mechanism: quiet, predictable, and arguable when it is wrong — the team demoted one noisy configuration rule in week eight without ceremony.
The first exception
Week nine produced the quarter’s most instructive moment: a legitimate blocker. An internal reporting service couldn’t yet adopt the new image-base policy, and work had to ship anyway. The team wrote the first exception of its existence: what the problem was, why it couldn’t be fixed this sprint, who owned it — Tom, who had stopped being the everything-nobody-wants engineer somewhere around week six — and when it would expire. Ninety days, the playbook’s ceiling, with a calendar reminder set. The fix itself went onto the sprint board with an estimate, which meant the exception had a visible countdown rather than an open-ended shrug. Priya’s note in the retro: “the exception isn’t the failure. The exception without an owner and an expiry is how failure gets scheduled.”
What month three of DevSecOps looked like
By the end of the quarter the numbers had settled into a rhythm the team could read at a glance: zero gate overrides across the month, a findings list they actually trusted, an inventory attached to every release, and a monthly thirty-minute review where the only agenda was the data — override count, false-alarm rates, what escaped to production, which exceptions were aging. The review produced no theater. One rule got retired for being wrong more than it was right, one got tightened, and the burn-down list lost four items. Total security-specific meeting time for the month: thirty minutes. Priya also drafted the compromise runbook they hope never to use: if a dependency turns hostile, who rotates what, in which order, and who calls the flight schools. Tom, meanwhile, had taken over dependency hygiene as a defined role with protected hours — a homegrown version of the champion model, which the research says works best when it’s a tenth to a fifth of someone’s week, not a hero’s spare time. Nobody had to be persuaded anymore; the quiet month had already made the argument.
What a fictional quarter teaches
Strip the narrative and the transferable sequence is short:
- Threat-model one real change in forty-five minutes, with the four manifesto questions on the whiteboard.
- When a secret leaks, rotate first; rewrite history second.
- Run every scanner report-only for a month and count its false alarms.
- Emit the software inventory from the very first build, not the tenth.
- Turn gates on only for rules that proved themselves in the quiet month.
- Attach an owner and a deadline to every exception — ninety days is the ceiling before it must be re-justified.
- Read the numbers together once a month, and rehearse the compromise runbook twice a year.
None of it requires a security team, a reorg, or a big purchase — it requires a quarter and a Priya. The parallels to flight training itself are hard to miss: progress measured in small logged increments, checklists that precede the maneuver, and costs that are easiest to see by type and scale, the way our guide to how aircraft type affects training cost breaks down spend before the first hour is flown. Teams that want the adjacent discipline for keeping systems reliably up will find a kindred roadmap in the SRESchool path into site reliability engineering.
And if the quarter at Cascadia proves one thing, it’s that security work, like flight training, compounds quietly. The academy funds its aircraft partly through scholarships — see our scholarship guide for flight-training students — because nobody learns to fly without someone fronting the first hours. Pipelines are the same: the checks you install this quarter are the hours someone else doesn’t spend in an emergency later. Priya’s team ended the quarter with no headline incident, which is precisely the point. The best security story is the one where nothing happens, on schedule, for a very long time.
