Every engineering team knows the pain of rework. You spend weeks designing and building a feature, ship it, and then—boom! A production incident. Everything grinds to a halt. Engineers scramble to patch the issue. Other feature deadlines slip. Customers notice. And perhaps most frustrating of all, it’s a problem that could have been prevented with a bit more foresight earlier in the process.
This is the hidden cost that security teams, and engineers, need to help surface in terms of real business impact like dollars lost, productivity stalled, and engineering morale strained.
Studies have shown that the cost to fix a defect increases dramatically the later it’s discovered. An oldie, but one of the most referenced studies that highlights this is the National Institute of Standards and Technology (NIST) 2002 report “The Economic Impacts of Inadequate Infrastructure for Software Testing” (Section 5) (link here).
In modern environments with continuous integration and rapid delivery cycles, rework isn’t just expensive; it’s disruptive. Late-stage vulnerabilities ripple across teams as:
The result? Time, money, and momentum are lost, and much of the time, unnecessarily.
Yet despite this, most organizations still lack a clear, data-driven way to quantify the value of prevention.
One of the actionable metrics I recently shared in my keynote talk from AppSec SoCal 2025, as well as in the corresponding article, “From Soft Skills to Hard Data: Measuring Success of Security Champions and Culture Change” (link here), is this:
Productivity Gained via Reduced Rework — The estimated engineering time and cost saved by preventing vulnerabilities and reducing technical rework earlier in the SDLC.
This metric helps organizations estimate and track the actual cost savings from preventing vulnerabilities earlier in the SDLC through best practices like secure design, threat modeling, developer culture/enablement, and other proactive investments. It's about shifting the narrative from simply fixing issues as they pop up, to not having them in the first place, and being able to prove the impact of that shift in terms that resonate with both engineering and business leadership.
In short, it’s a way to actually measure what didn’t happen, and the corresponding business benefits.
This metric necessitates two complementary measurements to be successful: Empirical Cost Savings (After the Fact) and Estimated Cost Savings (Predictive). Here's how to make them work:
Example: “This production incident cost us $300,000 in cumulative engineering, leadership, and resource time. Had we invested $5,000 in performing a threat model for this system, we likely could have prevented it.”
Example: “By shifting to IDE AI-assisted secure code reviews, we estimate eliminating CI/CD pull request scan issues by 50%, which equates to ~$50,000 per month of total development time saved across our teams.”
These two strategies, one retrospective and one prospective, are most powerful when used together to prove that significant investments in preventative measures are justified. In addition, they demonstrate the capability of the organization to learn and adjust habits and processes to save the business money in the long run.
You'll of course need to account for the cost of rolling out these preventative measures, which can be significant, comparing this to the total dollars saved once implemented. Also, this isn't a one-time measurement. Be prepared to continuously capture and report on this metric going forward to allay any future questions of where time and effort is being spent.
Yes, this approach requires a mindset shift toward considering actual time wasted by salaried employees. This is not something often thought about in my experience. Salaried employees' time seems to be scrutinized less (likely due to "free" overtime expectations) than contractors' time, where every hour matters. But there are many hidden costs with ths approach and we need to think about this differently.
While this metric can be applied broadly, it’s most effective when focused on architectural-level issues. These are the systemic flaws such as improper access control, insecure design, flawed business logic, insecure service integration, and data flow vulnerabilities. You can identify these types of issues because they:
Preventative controls like threat modeling, secure design reviews, and architecture checklists are tailor-made for catching these issues early, when they are the cheapest and easiest to address.
This metric is most impactful when translated into outcomes that resonate with business and engineering leaders. Represent it not just in terms of cost/time savings, but in terms of how that time can be repurposed for feature development:
“Last quarter, we saved an estimated $150,000 by reducing production architectural issues by 45%. This time savings enabled us to deliver 150 additional story points and increased our average sprint velocity by 20 points.”
Sharing how our efforts affect the business' bottom line is not something the cybersecurity industry does well, yet. We need to show the benefits of reclaiming lost productivity and clearly tie quality and secure practices to measurable outcomes.
The “Productivity Gained Through Reduced Software Rework” metric is an effective method to bring alignment between security and delivery. It elevates prevention from a vague ideal into a measurable, strategic advantage.
Because every hour spent reworking production code due to quality or security issues is an hour not spent building the future.
Dustin
Note:
In researching for this article, I learned that the statement “the cost to fix a defect increases dramatically the later it’s discovered” has been debated, such as in this article: https://buttondown.com/hillelwayne/archive/i-ing-hate-science/, which says that a common study cited by the “IBM Systems Sciences Institute” doesn’t actually exist. I also had trouble finding this study, but I have always relied on the 2002 NIST study that I cited above (https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf).
If you’re interested in a more recent, related report about software quality, check out “The Cost of Poor Quality Software in the US: A 2018 Report” by the Consortium for IT Software Quality (CISQ): https://www.it-cisq.org/wp-content/uploads/sites/6/2023/09/The-Cost-of-Poor-Quality-Software-in-the-US-2018-Report.pdf, as well as their 2020 follow-up report: https://www.it-cisq.org/cisq-files/pdf/CPSQ-2020-report.pdf.
If you’re still not convinced, would it help to say that I’ve experienced the pain of having to troubleshoot and rework software firsthand? I believe many software engineers would attest to the fact that we’ve said to ourselves over and over something akin to “if we only did it right the first time, we wouldn’t be in this mess... I tried to warn them, but they didn't listen," further contributing to the cynicism that's all too common among us devs.
Why does it always seem like there’s enough time to fix it, but never enough time to build it right to begin with?