In May 2012, Etsy CTO John Allspaw published "Blameless PostMortems and a Just Culture" on the company's engineering blog, and the idea reshaped how software teams talk about failure. Instead of asking who broke production, Etsy's process asked what conditions made the mistake possible — a framing borrowed from aviation and healthcare safety research going back decades. Thirteen years later, the 2025 DORA State of DevOps report found that only 16.2% of organizations achieve on-demand, multiple-times-daily deployment, while 23.9% still deploy less than once a month. The gap between those two groups isn't tooling maturity — most low performers run the same CI/CD platforms as elite ones. It's culture: whether engineers treat security and reliability as a shared property of the system they own, or as a gate someone else enforces on them after the fact. This post is a CISO-level guide to closing that gap through three concrete levers — security champions programs, metrics that measure the right things, and blameless postmortems — and where a central security team's own findings pipeline fits into that culture instead of undermining it.
Why doesn't a central AppSec team scale on its own?
A central AppSec team doesn't scale because the ratio of security engineers to developers gets worse every year a company grows, while the volume of code, dependencies, and infrastructure changes grows faster than headcount ever will. OWASP's Software Assurance Maturity Model (SAMM) names this explicitly under its Education & Guidance practice: a security champions program — developers embedded in product teams who act as the local security point of contact — exists specifically to multiply a small central team's reach without multiplying its headcount. A champion doesn't replace the AppSec team's expertise; they translate it into daily standups, PR reviews, and design docs where a central team has no seat. The alternative — routing every question and every finding through a handful of centralized reviewers — creates a queue that gets longer as the org grows, and queues train engineers to route around security rather than through it.
What makes a champions program work instead of becoming a title with no function?
A champions program works when champions have three things a badge alone doesn't provide: dedicated time, direct access to real findings, and a feedback loop back to the central team that shapes what gets prioritized next. OWASP SAMM frames this as a maturity progression — an organization moves from ad hoc awareness to a structured program with defined responsibilities, training cadences, and measurable participation, not a one-time kickoff email. In practice, that means a champion needs enough allocated hours per sprint to actually triage findings in their team's own service, visibility into the same dataflow context a security engineer would see (not just a severity label), and a standing channel to flag when a rule is too noisy or a control is unworkable for their stack. Programs that skip the second part — real findings context — tend to stall, because champions end up relaying tickets they don't understand well enough to defend in a design review.
Which metrics actually predict whether security is embedded, not just measured?
The four core DORA metrics — deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time — predict whether security is embedded because they measure how safely a team can move, not how many findings it generated. The 2025 DORA report found only 9.4% of organizations achieve sub-one-hour lead times from commit to production, and it introduced a "Rework Rate" metric specifically to separate genuine throughput from work that has to be redone — a proxy for how often changes (including security fixes) go out wrong the first time. This matters for a CISO because vulnerability counts and scan coverage percentages tell you what your tools found, not whether engineering can act on it. A team with a 30-minute lead time can ship a critical patch same-day; a team with a two-week lead time treats every hotfix as an exception process, which is exactly the condition that produces rushed, under-tested emergency changes. Pairing DORA's throughput/stability metrics with the 2025 report's expanded cultural signals gives a CISO a dashboard that reflects engineering reality, not just AppSec activity.
Why do blameless postmortems change how teams respond to security incidents?
Blameless postmortems change incident response because they remove the incentive to hide or minimize what happened, which is the only way a team ever learns the actual chain of contributing factors. Allspaw's original framing, later codified in Google's SRE Book as canonical postmortem culture, argues that punishing the person who made the last visible mistake teaches everyone else to conceal near-misses instead of reporting them — the opposite of what a security program needs. A security incident postmortem run blamelessly asks how a hardcoded credential passed three reviewers, not who wrote it; the answer is usually a gap in tooling, onboarding, or review load, all of which are fixable at the system level. Teams that run blameless reviews consistently build a pattern library of these systemic gaps over time, which is far more useful to a CISO than a headcount of individual mistakes. The practice's roots in aviation and healthcare "just culture" models exist precisely because those industries learned the same lesson decades earlier: punishing individuals for reporting failure produces less safety, not more.
Where does a unified findings pipeline fit into this culture, and where doesn't it?
A unified findings pipeline fits into this culture as the shared source of truth a champions program and a metrics dashboard both need — it doesn't fit as a substitute for either one. Safeguard's application security testing correlates SAST, DAST, and SCA findings into one model with source-to-sink dataflow traces, so a champion reviewing a finding in their own service sees the same context a central security engineer would, rather than a bare CVE ID with no explanation of why it matters. That closes the "real findings access" gap SAMM identifies as a prerequisite for a functioning champions program. But a tool cannot manufacture the allocated time, the blameless review norm, or the metrics discipline a CISO has to build deliberately — it can only make the technical half of the job legible to the people doing the cultural half. Culture change and platform investment move together, not one after the other.