Teaching people to fly means listening for a living. Students arrive with sentences they have absorbed from films, from forums, from a cousin who once sat in a Cessna, and half of instruction is hearing a confident sentence and gently taking it apart. Lately I have been reading about how software teams ship their work, because a surprising number of my students build things for a living too, and I recognised the pattern immediately. DevSecOps — the habit of putting security checks inside the delivery flow and having the delivery team own them, instead of saving the worry for a phase at the end — attracts the same kind of confident sentences. Here are the six I keep hearing, why each one sounds reasonable, and what the evidence says instead.
“The DevSecOps scanner will catch it”
A student once told me he didn’t need to learn stall recovery because the aircraft had a stall warning horn. The horn tells you the wing is already stalled. It does not recover for you. Automated security scanning works the same way, and the numbers prove it. Research into Google’s Tricorder deployment — some of the most honest data the industry has — shows that blocking on a static analysis rule only makes sense once a rule’s effective false-positive rate has fallen to roughly nothing, once findings are judged on changed lines rather than the whole codebase, and once a thirty-finding sample has been read through before the rule is trusted. The scanner is a wonderful instrument. Instruments need a rated pilot who knows their failure modes, which is exactly what the thirty-finding sample builds.
“Shift it left and the problem moves with it”
Shifting security earlier in development is genuinely half the battle; nobody serious disputes it. The myth is the word finishes. A check that fires during development has still not proved anything about the artifact that actually reaches production, and evidence that fails to survive the journey is evidence you cannot act on. That is why mature setups attach an SBOM, a signature, and build provenance to every artifact, and then verify those receipts when the artifact is deployed — because a signature is a claim, and the check at deploy time is what makes the claim worth something. There is a harder lesson hiding here too: stored attestations can be forged if the machine producing them is compromised. The paperwork matters only as much as the process behind it. My students learn a version of this when they discover that a weather brief from six hours ago is not a weather brief; weather study tips only work if you keep studying the sky after the briefing ends.
“Let the security team handle that side of the house”
This one is usually said kindly, as if it were a compliment: the specialists have it covered. What the research actually shows is stranger. DORA’s 2022 report put the odds of reporting high burnout at 1.4 times for teams with weak security practice, and — more surprising — found that culture predicted whether security habits spread better than tooling did. Security as somebody else’s department produces exactly the fatigue those numbers describe, because the delivery team then experiences security as weather: something that happens to them. The arrangement that recurs in mature organisations is quieter. Champions embedded with delivery teams, given ten to twenty percent protected time, spread the judgement through the team instead of policing it from outside.
“Green means go”
Every checkmark on a dashboard is a statement about the past. The pipeline ran clean on Tuesday; the artifact that ships on Friday carries Tuesday’s verdict with no memory of what happened between. Teams that overtrust stored attestations learn this expensively, because a compromised build tool can falsify its own paperwork — an SBOM produced by an attacker’s Syft looks identical to an honest one. The correction is procedural rather than heroic: prove the receipts at the moment of deployment, keep the trust anchor small, and treat a green badge as one input among several. A preflight checklist signed yesterday does not clear today’s flight, and no instructor would pretend otherwise.
“Tighten every gate until nothing gets through”
Strictness feels like safety, which is why this myth survives every generation of tooling. The failure is documented with almost clinical precision: gates that block on everything above medium severity train the entire organisation to seek bypasses, and the bypass culture outlives the gate. What works is narrower and takes more courage to write down. A merge earns its refusal only when four ingredients are present together: severity, fixability, novelty against the change under review, and high confidence. Everything else — the pre-existing debt, the uncertain findings, the noisy rules — becomes scheduled work carrying an owner and a deadline, which the reference templates cap at ninety days. The gate keeps its authority precisely because it is used sparingly, the way a student’s trust in a checkride examiner survives on consistency rather than severity.
Four DevSecOps questions worth stealing
Between the gate myth and the certificate myth sits the practice that quietly fixes both: threat modeling done small. The stereotype is a room of architects and a three-day workshop; the version that actually spreads is a forty-five-minute playbook built on the Threat Modeling Manifesto’s four questions. A delivery team walks its change through them before the code review even starts, and the whole exercise fits inside a long lunch.
- What are we actually building here, drawn plainly enough that a newcomer could sketch it?
- What could go wrong with it, worked through the STRIDE lenses — could someone impersonate a user, tamper with data, deny having acted, peek at secrets, exhaust the service, or climb above their permissions?
- What will we do about the things that matter?
- Did we do a good enough job, checked honestly after the fact?
Notice what this buys. The scanner myth dies because a team that can name its own threats knows which findings are real. The gate myth dies because most threats are answered by design decisions, not by blocking merges. And the certificate myth dies last of all, because the four questions are judgement, and judgement is the one thing nobody can issue you a card for. Student pilots meet the same sequence dressed as a weather decision: what is the picture, what could go wrong, what is the plan, was the plan right? The format travels; only the nouns change.
“Somebody certified DevSecOps, somewhere”
Students ask me for the certificate that proves a pilot is safe, and I have to disappoint them: there isn’t one, only demonstrated skill, logged hours, and a history of judgement. DevSecOps is in the same position, more so than most people assume. There is no official standard that defines the term, no certification that confers it, and no agreed difference between the word orders — DevSecOps, SecDevOps, DevOpsSec get used interchangeably, and the rearrangements carry no agreed meaning. The name shows up in NIST’s SP 800-204C — which describes it as a facilitating paradigm around CI/CD — and in the SSDF, and in US Department of Defense guidance, but none of those documents certifies anything. What transfers is judgement, built the way flight hours get built: one reviewed finding, one tuned rule, one rehearsed incident at a time. A useful starting map, for anyone who wants the discipline described without vendor varnish, is the DevSecOps reference at xOps School.
What the two classrooms share
Aviation made its safety culture the hard way, by writing down what killed people and refusing to let the sentence stay comfortable. Software delivery is younger at this, but the mechanism is identical, and the six sentences above fall apart under the same pressure: measured false-positive rates, verified receipts, protected champion time, restrained gates. When my students stop saying “the horn will save me” and start saying “I own the recovery,” they pass. When a delivery team stops saying “the scanner has it” and starts owning the checks in its own pipeline, the same thing happens. The vocabulary is different; the maturity is recognisable anywhere. If you want the engineering-side version of this path — roles, infrastructure, the craft underneath the checks — the infrastructure engineering guide on this site picks up where the myths end.
