Aviation people understand investing on numbers. Nobody buys hours on an aircraft because the brochure used the word “safe”; they read the hourly rates, the pass rates, the insurance math, and the maintenance records before the money moves. DevSecOps — security woven through the build-and-ship process and owned by the people who run it, so nothing reaches release without examination and a trail — deserves the same treatment, because its practitioners have quietly assembled benchmark figures that separate working programs from expensive theater. If you’re about to fund a security initiative, acquire a software business, or hire someone with “DevSecOps” in their title, the ten numbers below tell you whether the practice is real. Each is checkable in public sources rather than vendor collateral; the collection point is the DevSecOps entry of the Ops Atlas, and after each number comes the question to ask in the room — because the room, sooner or later, always asks.
The ten DevSecOps numbers, and the question behind each
1. Forty-five minutes — the price of a threat model
The working playbook for threat modeling one significant change budgets forty-five minutes, frames the session with STRIDE, and closes on the manifesto’s four standing questions. That’s less time than a preflight coffee at most FBOs. Ask: when did you last threat-model a feature, and what did it change? “We do it annually” means never — and the forty-five minutes would have caught early what the annual review found late and expensive.
2. Ten to twenty percent — the champion’s protected week
Embedded security champions carry their squad’s security questions when a protected 10–20% slice of the week is formally reserved for it. Below that, the role exists on an org chart only, absorbing whatever attention a deadline leaves behind — which, on most teams, is none. Ask: whose calendar holds these hours, and did they survive the last crunch? The answer reveals whether security is a duty or a decoration.
3. Five percent — the override ceiling that keeps a gate honest
A merge gate may refuse changes, and humans will sometimes overrule it. The health band: fewer than five percent of blocks overridden per month. Ask: what was last month’s figure? A team that can’t produce the number has a gate it doesn’t watch — or a gate nobody believes, which is worse, because the unbelieved gate still consumes everyone’s attention while catching nothing that matters.
4. Twenty-two point nine — the anatomy of a dead gate
The field’s worked example shows what a lost gate looks like: 1,240 changes in a month, 96 refused, and 22 of those overruled — 22.9 percent, nearly five times the healthy band. The lesson isn’t the arithmetic but the trajectory: overrides compound quietly until enforcement is fiction. Ask: how often has your gate been retuned because engineers pushed back successfully? A gate that never loses an argument is being ignored, not obeyed.
5. Effectively zero — the false-positive bar for blocking
The adoption evidence from Google’s Tricorder deployment is strict: a static-analysis rule may refuse merges only once its false alarms measure at essentially nil, scans cover only the lines a change touches, checker comments stay below a tenth of review traffic, and every rule gets a thirty-finding audition before enforcement. Ask: what’s the false-positive rate of the rule that’s currently blocking your team, and who measured it? An unmeasured blocker is a bet, not a control — and bets placed with other people’s delivery speed have a way of coming due at the worst moment.
6. Ninety days — the lifespan of an exception
Every legitimate waiver gets an owner, a written reason, and an expiry; ninety days is the standard ceiling before it must be re-justified. Ask: how many exceptions are open right now, and which is oldest? An undated waiver is debt with the invoice torn up — somebody, someday, rediscovers it during an incident, and nobody remembers approving it or why. The dated kind, by contrast, tends to die quietly on schedule, which is the system working.
7. One point four — the burnout multiplier
DORA’s 2022 research put teams with weak security practice at about 1.4 times the burnout odds, and found culture outpredicting tooling as the driver of adoption. Ask: does the security plan add protected capacity, or does it just add blame? The multiplier says the second option costs more than it appears, in exactly the currency — your engineers’ remaining energy — that no budget line tracks.
8. L0 to L3 — the supply-chain ladder
SLSA grades build integrity across four Build levels, plus a newer Source track spanning L1 to L4 for trust in the repository itself. GitHub’s artifact attestations reach Build L2 — L3 when reusable workflows are pinned — and the grade only matters if something verifies artifacts at deployment time. Ask: what level are your builds, and who checks it when a release goes out the door? Signing without verifying is a stamp collection, and the grade is only as good as the check that happens at the hangar door — deployment, in this analogy, being where the weight is on the wheels.
9. Forty percent — why AI-written code needs the same gates
The widely cited 2021 study of 1,689 programs generated by a code assistant found about forty percent carried vulnerabilities. More recent measurements put package hallucination — models inventing plausible-looking dependency names that somebody then installs — at 5.2 percent on commercial models and 21.7 percent on open-source ones. The vulnerability rate says assistants write insecure code at generative speed; the hallucination rates say they also invent supply chain with equal confidence. Ask: do AI-assisted changes pass through the same scanners as human ones? If the answer is “we trust the assistant,” reread item nine and then reread it again.
10. Two springs — the incident cadence to plan against
Spring 2025 brought the tj-actions/changed-files takeover: repositories running the action had their secrets drained, and CISA’s guidance centered on rotation. The following March, two scanner-related actions had their version tags rewritten mid-flight to serve a poisoned build — contained the same evening by teams with rehearsed runbooks and current inventories. Two springs, two lessons about trusting the machinery itself. Ask: when did you last rehearse “a dependency turned hostile,” and how long would you need to know whether you’re exposed? Teams that answer in minutes own an inventory; teams that answer in weeks own a hope, and hopes do not rotate credentials.
Reading DevSecOps numbers critically
Before you take these figures into a meeting, three cautions:
- Context first. The numbers describe mechanisms, not guarantees — a five percent override rate doesn’t by itself make a pipeline safe; it makes the gate believable, which is the precondition for everything else the gate is supposed to do.
- Source second. Each figure traces to public research or documented incident response, not vendor materials. In the meeting, ask for the trace; a practitioner will have it at hand.
- Trend third. Any single month can flatter or damn a team. Ask for the last six data points and the direction of travel — a bad number with a falling slope is a team fixing itself; a good number with a rising slope is a team about to stop paying attention.
A practice measured every month is a practice that exists; a practice measured once for a sales deck usually isn’t.
For aviation professionals the parallel is already familiar: hours logged, checks signed, incidents debriefed, and the numbers kept where the next decision-maker can find them without asking twice. If you’re weighing the personal investment side, the same evidence-first approach applies to a career — our analysis of whether pilot training is worth the investment and the follow-up on career growth after pilot training both run on numbers exactly like these. And for teams building the underlying reliability skills, the SRESchool approach to practical learning for reliable software pairs naturally with the security half. Fund the practices that can show you their numbers; decline, politely and permanently, the ones that can only show you their adjectives.
