A surgical team never walks in and improvises. The chart is reviewed, the site is marked, the allergies are read aloud, and a checklist confirms every one of it before the first cut. Delivery pipelines deserve the same ceremony, and DevSecOps — security built directly into the delivery pipeline and the people who run it — supplies it. What follows is a readiness checklist in seven stages, written the way a pre-op review reads: verify before you proceed, and record that you verified.
Stage one: review the chart before you count the patient in
Day zero of any serious effort belongs to paperwork, and three documents should exist before a single tool is installed:
- A gate policy, one page, naming the only findings that may stop a release.
- A place to keep scanner output — a SARIF store — so results accumulate as history rather than evaporating as alerts.
- An identity model, stating which humans and machines hold which credentials, and how each could be revoked.
Teams that skip this stage discover later that their scanner findings had nowhere to live and their gates had nobody to answer to. The chart comes first; the operation follows it.
Stage two: the DevSecOps consent form — what a gate may stop
Informed consent, in pipeline terms, is an agreement about when blocking is legitimate. The defensible scope is narrow: a change may be held only for a finding that arrived with the change itself, that the tool flags with high confidence, and that can be repaired on the spot. Everything else converts into recorded work, each item assigned to someone by name and given an expiry that sits ninety days out at most, while the pre-existing backlog never blocks anyone. Teams that consent to wider blocking get bypass culture; the record shows a gate cancelled in 22 of 1,240 changes looked trustworthy next to one cancelled in a quarter of them. Aim to keep overrides beneath five percent a month, and read every override as feedback about the rule, not about the engineer.
Stage three: surgical safety checks on the pipeline itself
Theatre discipline applies to the operating room before the patient, and in delivery terms that means the CI system, which the OWASP CI/CD Top 10 catalogues as CICD-SEC-1 through 10. The core precautions:
- Pin each third-party action to the complete commit SHA, so a moved tag cannot swap the instrument mid-procedure.
- Scope permissions per job rather than granting the whole workflow a master key.
- Prefer OIDC or workload identity to stored cloud credentials; where a key must exist, treat its rotation as urgent and its history rewrite as second priority.
- Give fork contributions no secrets, and never run untrusted code from a pull_request_target checkout.
- Take gate rules from the base commit, never from whatever the incoming change carries.
Stage four: imaging and labs — scanners with known accuracy
A lab result is only as good as its false-positive rate, and code scanners obey the same law. The Tricorder-derived rules of evidence: enforce a check only where its measured false-alarm rate is effectively nil; keep machine-generated review comments under ten percent; restrict results to changed lines; and judge each rule on a thirty-finding sample, demoting it if it fails. Secrets deserve their own lab: a pre-commit scanner on the developer’s machine plus server-side push protection, with the caveat that GitHub’s bypass option is open to every writer by default unless an admin closes it. And when a secret does escape, the sequencing is medical — stop the bleeding first. Rotate the credential before touching history.
Stage five: the DevSecOps implant registry — evidence per build
Every implant is logged: maker, model, lot. Every build should carry the equivalent — an SBOM listing the components, a signature across the artifact, and provenance that records the manner of its making. SLSA grades the build path from level 0 to level 3, GitHub artifact attestations reach level 2, and level 3 arrives with pinned reusable workflows; the Source track grades the repository itself. One precaution gets skipped more than any other, and it is the one that matters: verify at deploy. A signed build nobody checks is an implant nobody X-rayed. The 2024 XZ Utils backdoor made the point publicly — prevention failed, but teams with ingredient lists answered “are we affected?” in minutes, and response speed turned out to be the entire value.
Stage six: the forty-five-minute consult
Before significant changes are built, a short structured session works through four questions in the spirit of the Threat Modeling Manifesto: what exactly is being built, how could it be attacked, what is the chosen countermeasure, and did that countermeasure hold? STRIDE gives the “what can go wrong” part its categories. The playbook budget is forty-five minutes, and the output is decisions recorded while they are still cheap to make. Clinics that pre-operative-review properly rarely cancel on the table; the same arithmetic holds for software changes.
Stage seven: discharge criteria and the follow-up clinic
Recovery is measured, not assumed. The monthly review reads the panel aloud:
- Effective false-positive rate, and the override rate beneath it — under five percent monthly.
- Fix time for new findings, median and ninetieth percentile.
- Escape rate — flaws that still reached production, set against how many positioned checks ought to have intercepted them.
- Provenance coverage: the share of deploys carrying verified evidence.
- Pipeline overhead, plus the health of the exception ledger — no expired entries loitering.
Then rehearse the bad day: a compromise runbook practised on a schedule, so a compromised action or a falsified SBOM meets a team that has drilled rather than a team improvising. For the framework this checklist condenses, the DevSecOps field notes in The Ops Atlas are the source to study. And if the checklist habit itself feels familiar, it should — it is the same discipline patients rely on when they check a hospital’s accreditation before travelling, or ask the essential questions before surgery abroad: verification recorded in advance beats reassurance given afterward, and careful comparison protects the whole journey.