Ask a security vendor how much cheaper it is to catch a bug in code review versus production, and you'll likely hear "100x" — a figure traced to a chart attributed to the "IBM Systems Sciences Institute." Journalist and researcher Laurent Bossavit spent years trying to find the underlying study and concluded, in reporting covered by The Register in July 2021, that no such study appears to exist in any retrievable form; the "Institute" was most likely an internal IBM training reference, not a peer-reviewed dataset. Barry Boehm, the software economist whose real 1970s–80s research actually established that fix costs rise across the lifecycle, said in 2001 that for small, non-critical systems the ratio is closer to 5:1 than 100:1. That doesn't mean the underlying idea is wrong — it means the specific number security teams have been citing for two decades is unsupported. This post rebuilds the case for shifting left on real, sourced numbers: a 2002 NIST estimate of what inadequate testing costs the US economy, and IBM's 2025 Cost of a Data Breach Report on what a flaw costs once it reaches production. The goal is a cost model you can actually defend to a CFO, not a chart that collapses under a citation check.
Where did the "100x" number actually come from?
It came from a citation chain nobody can close. The chart usually shows costs multiplying roughly 1x at design, 6.5x at implementation, 15x at testing, and 60–100x after release, attributed to an "IBM Systems Sciences Institute." Bossavit's investigation, reported by The Register in 2021, found no publishable study, no author, and no methodology behind the number — just decades of slides citing other slides. The real lineage traces to Barry Boehm's work on software cost estimation, which did find costs increase later in the lifecycle, but Boehm himself pushed back on the extreme multiplier, telling interviewers in 2001 that a 5:1 ratio was more realistic for smaller, non-critical projects, with higher ratios only plausible for large, safety-critical systems. If your risk model still leans on "100x cheaper to fix in design," it's leaning on a number nobody can source.
What did NIST actually find inadequate testing costs?
NIST Planning Report 02-3, published in 2002, estimated that inadequate software testing infrastructure cost the US economy $59.5 billion annually, with more than half of that burden falling on software users who discovered defects after deployment rather than on the vendors who shipped them. NIST further estimated that roughly $22 billion of that annual cost was avoidable through improved testing practices earlier in development. This is a real, citable federal study — but it's now 24 years old, predates modern CI/CD and SaaS delivery models entirely, and its methodology has been criticized as overly broad. Treat it as historical evidence that the shift-left thesis has government backing going back decades, not as a current-dollar estimate for your organization's risk exposure today.
What does a flaw cost once it reaches production in 2026?
IBM's Cost of a Data Breach Report 2025 put the global average cost of a breach at $4.44 million, a 9% decline from $4.88 million the prior year — the first year-over-year drop in five years, which IBM attributed largely to organizations using AI and automation to identify and contain incidents faster. Mean time to identify and contain a breach fell to 241 days, the lowest in nine years of the report. The US average was far higher, hitting a record $10.22 million, and healthcare remained the most expensive industry at $7.42 million despite that also declining from $9.77 million the year before. These figures describe the cost of the flaw surviving all the way to an exploited production incident — not the cost of merely finding it in a scanner.
Why is a like-for-like cost comparison so hard to build?
Because "cost to fix" and "cost of a breach" measure different things at different points of a very long pipeline, and most public data only covers the far end of it. A finding caught in a pull request costs a developer's review time and maybe a re-run CI pipeline — minutes to hours, and almost never publicly reported, so there's no NIST- or IBM-scale dataset for it. A finding that survives to a customer-facing incident triggers IBM's $4.44M-average machinery: forensics, notification, legal exposure, customer churn, and regulatory fines, all of which get tracked and reported because breaches are disclosure events and fixes in code review are not. Any model claiming a precise multiplier between the two is extrapolating across a data gap that no rigorous, recent study has actually filled — which is exactly the gap the debunked "100x" chart was invented to paper over.
What can teams actually measure and act on?
Two variables you can measure honestly are volume and exploitability, not a universal dollar multiplier. Volume: SAST and SCA scans routinely surface far more findings than any team can triage line by line, and vendor research from 2023–2024 has repeatedly found that a large majority of SCA-flagged CVEs sit in code paths never actually executed at runtime — reachability analysis is what separates the handful worth a sprint from the hundreds that aren't. Exploitability: CISA's Known Exploited Vulnerabilities catalog and the EPSS scoring model both let teams rank findings by real-world attacker interest instead of CVSS base score alone, so the limited engineering time available goes to the flaws most likely to become the next IBM breach-cost statistic rather than the ones with the scariest-looking severity label.
How Safeguard Helps
Safeguard's SAST and SCA engines trace every finding through a unified reachability model instead of reporting raw CVE or rule-match counts, so a source→sink dataflow trace tells you whether a flagged sink is actually reachable from untrusted input before it ever reaches a developer's queue. SCA findings carry EPSS and CISA KEV context alongside the full transitive dependency path, so triage prioritizes exploited-in-the-wild issues over theoretical ones. Because SAST, DAST, and SCA findings share one tenant-isolated model with correlation keys, a runtime issue confirmed by DAST links back to the exact source-code sink that produced it — giving security and engineering teams a shared, evidence-based answer to "how much did catching this early actually save us," instead of another slide citing an untraceable chart.