>_ Unvalidated input

stdin: is not a tty

CapEx vs. OpEx: Budgeting for Application Security

In a highly agile environment, security is fast becoming embedded into the Continuous Delivery of software as part of the DevOps process. As we are shifting things increasingly forward in the software development lifecycle which means the budgeting of software security should be more aligned with development costs.

Basic definitions

Software development costs fall into two categories: capital expenses (CapEx) and operational expenses (OpEx). Let’s first recap the basic definitions of CapEx and OpEx:

  • CapEx is a business expense incurred to create an asset that will have a future benefit and will span beyond the current tax year. These assets are presumed to have a useful life. Expenses for these assets are recognised as they are depreciated over time.

  • OpEx is a business expense to keep the business running. It is recognised in the period incurred (i.e., in the current tax year). Most expenses for the day-to-day operations that are not directly contributing towards the creation of assets with benefits spanning beyond the current tax year would end up being categorised as operational expenditure.

CapEx vs. OpEx

Why is the CapEx vs. OpEx distinction so important when trying to get a software security initiative approved?

Because the right mixture of CapEx and OpEx in your project can mean the difference between getting it approved and having it rejected for budgetary reasons.

Most software development activities resulting in a creation of a software asset would generally be accounted for as CapEx. A modern Agile software development process allows you to capitalise more of your costs. I will touch on this later in the post.

Any SDLC activities of a security team that directly contribute to the creation of a specific software like Security Architecture, Threat Modelling, Code Reviews or Testing would fall under CapEx.

On the other hand, any day-to-day operations that are not directly contributing to the creation of an asset like quarterly security testing of the running application portfolio, security training, vulnerability management would fall under OpEx.

Advanage of Secure Agile Development

You can capitalise the cost of development activities, provided you can demonstrate how the software will yield future economic benefits. However, any day-to-day operations as well ass research costs associated with the software project planning must be considered OpEx and cannot be capitalised.

Phase Expense Activities
Research OpEx Planning, researching, estimating
Development CapEx Secure programming, code reviews, security testing
Production OpEx Installation hardening, bug fixing, training

The classic waterfall development process employs a rigidly structured, sequential steps to produce an entire, finished software application in one iteration or, possibly, in several linear phases. While Agile process expends less effort during the research phase of a project, which means you need less OpEx to get your project started. Additionally, continuous delivery blends the development and production phases as new code is steadily added in an automated fashion to the product reducing the cost required to install and configure, means less OpEx.

Making an investment in building security early in the SDLC for specific software products (CapEx) should reduce the amount of OpEx that is required after the fact for security bug fixes as part of maintenance. OpEx should decrease because down the line maintenance costs of the software will be less as it was built securely from the beginning and thus will require fewer security fixes down the line

Alignment is key

A software security initiative should align with a specific software project to balance CapEx/OpEx and derive the greatest benefit. Strengthening that alignment is key as resources must directly contribute to the creation of asset to be capitalised. DevOps process helps with this as it creates self-sufficient teams that are self-contained and responsible for development and maintenance of a specific product.

Initiative Expense Alignment
Purchase of static code analysis tool CapEx Developing a specific software product
Triaging results from static analysis built into SDLC CapEx Developing a specific software product
Static/Dynamic scanning of the existing application OpEx As part of the standard bug fixes and software maintenance
Security Architects/Specialists CapEx Building security in a specific software product
Security Architects/Specialists OpEx Not aligned with a specific software project. Providing general assistance across the organisation

Organisations may sometimes choose to be more conservative and count some of that spend OpEx depending on current financial needs. By capitalising as much as possible, an organisation can amortise costs over several years and spread out the impact on earnings. On the contrary, organisations that prefer to expense quickly will take an immediate hit in the current year, allowing a greater one-time effect on earnings.

Book a meeting with your CFO or a member of the accounting department and find out how your organisation handles CapEx/OpEx. You may find that the ability to capitalise a larger percentage of software security costs can get your projects done sooner.