Pilots do not inspect an aircraft once a year; they walk around it before every flight, because the walk costs five minutes and the alternative can cost the aircraft. Software teams spent decades doing the annual-inspection version of security, then wondered why problems kept appearing at altitude. DevSecOps is the industry’s correction: build the checks into the pipeline itself so that every single change gets looked at, traced, and confirmed safe before it carries passengers — meaning users. This explainer keeps the language plain and borrows the shape of a briefing, because briefing formats survive stress better than essays. The source for everything cited here is the DevSecOps reference at xOps School; nothing below comes from vendor brochures.
What DevSecOps means, in briefing terms
Definition first, since the word gets stretched: it is security built into the software delivery pipeline and shared by the team that runs it, so each change is examined, leaves a record, and is fit to release. Security is not a stage at the end of the line — it is the line itself. Waiting until the end is precisely the habit that failed. The term is established across NIST and DoD documents, yet no one body owns a definition, and the alternate spellings — SecDevOps, DevOpsSec — carry no technical difference. Treat anyone who insists otherwise as telling you about their preferences, not the field.
Aviation readers will recognize the philosophy underneath. Preemptive checks on every cycle, a paper trail for each one, and authority granted by demonstrated procedure rather than job title. The field formalizes that with a placed-controls model: every safeguard is judged on four axes: where it sits in the flow, how much confidence it has earned, its cost, and its action on failure — refuse, caution, or simply log.
The DevSecOps preflight, item by item
Item one: the threat walk-around
Before building something significant, the team spends roughly three quarters of an hour on one question: what can hurt this feature? STRIDE gives the walk a pattern, the same way a checklist section does, and four standing questions from the Threat Modeling Manifesto close it out. The output is decisions written down while they are cheap to change.
Item two: secrets, the keys in the ignition
Passwords and API keys checked into code are the classic self-inflicted wound. Two layers catch them: a scanner on the developer’s machine before the commit, and server-side push protection behind it. When one does leak, the drill is rotate first, rewrite the history second — invalidate the key before tidying the paperwork. GitHub’s push-protection bypass, available to any writer by default, is worth knowing about before you rely on the protection.
Item three: automated inspection of the code itself
Static analyzers and dependency checkers are the computer-vision systems of software — tireless, consistent, and only as good as their calibration. Aviation has already lived this with computer vision applied to aircraft inspection: the tool flags, the human judges. A scanner earns the right to refuse a release only after proving it is nearly never wrong, and its findings stay scoped to the lines the change actually touched.
Item four: the evidence folder
Every build produces its paperwork automatically: an inventory of components (the SBOM), a cryptographic signature, and provenance that records how the artifact came to exist. SLSA grades this — Build levels L0 to L3, plus a Source track L1 to L4. The step people skip is the one that matters: verify the paperwork at deployment, not just produce it. Signed and unchecked is checked-out.
Item five: guard the hangar itself
The pipeline machines are targets too. The OWASP CI/CD Top 10 lists how they get attacked, and the counters are unglamorous:
- pin third-party build actions to a fixed commit, not a mutable tag;
- hold each job’s access to the minimum that still works;
- prefer short-lived identity tokens over stored keys;
- keep outside contributors’ code nowhere near credentials.
None of it is difficult; all of it is routinely skipped, which is why the list exists.
The one rule about stopping a release
Gates fail in an interesting way: set strict and people route around them. The working rule permits blocking only for new findings that are serious, fixable, and reported with high confidence; all three must hold. The remainder gets logged as tracked work with a named owner and a deadline, ninety days out at most. Inherited problems never block anyone. Teams that block on every medium finding teach their engineers to bypass, and the gate becomes decoration.
Machine-assisted monitoring belongs in the same mental drawer as AI used for aircraft engine health monitoring — trends surfaced by software, decisions made by people. The pipeline flags the anomaly; the crew decides the response.
Who actually does this work
Everyone in the delivery team, with one named person per squad holding protected hours — ten to twenty percent of the week — as the security champion. That person answers the small questions early so they never become large questions late. Research backs the arrangement: DORA’s 2022 study associated weak security practice with burnout odds about 1.4 times higher, and found culture predicting adoption better than tools did. Buy the tools after the habit exists, not before. Tools purchased ahead of habit tend to become dashboards nobody reads; habits formed ahead of tools tend to choose their tools well.
DevSecOps after takeoff
Nothing here requires a reorganization or a certification — no official certificate exists, and the discipline works fine without one. It requires a walk-around on every change, an evidence folder nobody has to reconstruct, and a gate strict enough to matter and narrow enough to believe. A team that ships weekly with those three habits is further along than a team that ships quarterly with a security badge on the wall. Preflight is a habit, not a phase — and that, in one sentence, is the whole discipline.