The Economics of Secure Software Development

The Breadth of the Problem

Undeniably, many companies fail to subscribe to an effective process for developing software that does not introduce added risk to the enterprise. Proprietary applications are coded without regard for security implications and are rushed to production in the name of increased quarterly revenue opportunities. Poorly engineered code can result in software security issues such as buffer overflows, improperly handled exceptions, memory leaks and input validation issues. These oversights often lead to application vulnerabilities that attackers exploit to target software infrastructure.

There are several factors to consider when thinking about the economics of secure software development. This article will touch briefly on three unique challenges that can have a profound impact on the cost of developing secure software:

• Managing changing requirements in software development
• Remediating software bugs at each phase of the software development life cycle (SDLC)
• Compensation schemes for software developers

Each of these challenges can influence the total cost of software development. Some of the costs are clearly visible and easy to quantify while others may remain quite hidden to the inexperienced eye.

Managing Changing Requirements in Software Development

While many project managers and developers may argue over the pros and cons of waterfall vs agile methodologies for software development, it is becoming clear that the agile method is increasingly preferred when customer fulfillment is the highest priority for the business. One of the reasons for agile’s popularity here may be the added flexibility for changing requirements during the SDLC. The linear character of the waterfall method requires that each stage of the development process be considered separately in iterative steps, which means that even a small, overlooked requirement may derail the entire project. Conversely, because agile projects are executed in interconnected development phases via sprints, changes may be introduced more readily without a profound impact on the completion schedule or development costs.

There are several reasons that software requirements may change during the development process:

• A Requirement is Overlooked
  Functional requirements created by stakeholders may not always be fulfilled the first time around.
• A New Bug is Discovered
  The development team may find new software defects that require additional coding to fix, which adds time and cost to the equation.
• A Change in End-User Requirements
  The needs of the user may change at a moment’s notice for a myriad of reasons. When this situation occurs, the agile method may work more seamlessly.
• A Change in Laws and Regulations
  Software that is written to serve customers in regulated industries may experience changes in technical or functional requirements as industry-specific legislation changes over time.

All the above events may impact the security mechanisms needed to protect a software application and each change will have a monetary developmental cost. The key to successfully managing changing requirements is integrating changes with a workflow that organizes and processes requests (e.g., by limiting the communication of change requests to only project managers, by increasing collaboration between development teams and stakeholders and by including limited prioritization and planning activities that will enable developers and architects to concentrate on critical tasks within the sprint cycle).

Remediating Software Bugs at each Phase of the Software Development Life Cycle (SDLC)

One of the most serious challenges facing developers and security professionals is explaining to executives holding the purse strings the importance of secure development practices throughout the SDLC. Even with all the data available today that emphasizes how the cost to fix defects rises exponentially later in the SDLC, leadership still does not see the benefit of making early investments.

To successfully embed software security controls into the SDLC, product managers must be empowered to stand up to the business and pause development long enough at key junctures to enable testing to be completed. Doing so may add some up-front costs, but these costs can be properly written off when calculating the total cost of development. Failing to prescribe to this development philosophy will certainly result in costlier software projects and the increased potential for attacks that target software deployed into production environments.

Compensation Schemes for Software Developers

Software applications should be considered fixed assets whenever the owning entity controls those assets through custody or legal rights. And, because these software assets provide benefits to the end user for longer than a year, they should also be considered capital assets. Therefore, expenditures on software development that result in the creation of a capital asset, and expenditures that can be directly attributed to the creation of that asset, are capital expenditures.

Arguably, the salary and bonuses that companies currently pay software developers may not be optimal from either a performance or cost-savings perspective. Many companies attempt to motivate developers to create secure software by paying them bonuses based on how bug-free their software is. These same companies may also pay bonuses to quality assurance testers based on the number of bugs that they log. As one can imagine, these practices can be viewed as adversarial and altogether unproductive regarding the creation of secure software.

Over 12 years ago at RSA in London, Dan Pink gave a talk on motivation. He contends that monetary rewards used to incentivize good performance only works with jobs that require primarily mechanical skills. For jobs that require even basic cognitive skills, the larger the reward, the poorer the performance. In the context of software development, which is absolutely a cerebral activity, it makes sense to pay individuals a handsome salary to take the issue of money off the table. Only then can developers concentrate on the factors that truly motivate them: autonomy (the desire to be self-directed), mastery (the urge to improve at what we do) and the need to have a meaningful purpose. When companies make the decision to migrate away from bonuses toward feeding these more intangible factors, they see a path toward more secure software.

Why Saving Money on Secure Software Development During an Economic Downturn is Needed

If the Consortium for Information and Quality Software is correctly estimating in its report, The Cost of Poor Software Quality in the US: A 2020 Report, that the total cost of poor software quality in the US was $2.08 trillion, it is safe to say that teaching secure coding and strategically leveraging appropriate software-testing tools (e.g. static, dynamic, and interactive application security testing tools) makes a whole lot of sense.

In December 2022, Megan Greene, Kroll's Global Chief Economist, said that the US will enter a recession by the middle of 2023. While this downturn is not expected to be long and drawn out, it will certainly have an impact on the ability of U.S. companies to throw away money on poor software-development practices. In fact, any opportunity available to embrace cost-savings measures should be taken seriously and executed. The days of standing by old archaic development practices are gone; and the time for designing, building, testing, and deploying software with security embedded in every phase of the SDLC has arrived.

Explore how Kroll approaches the development of a holistic application security program and watch one of our experts, Rahul Raghavan, discuss appsec fundamentals in this video.