A while ago, we blogged about why Prevention is better than Recovery in the context of Threat Prevention. With many Cyber Security maxims, the principles translate readily into other domains. This article focusses on how, in Application Development, an ounce of prevention is worth a pound of cure.

Challenges commonly faced by Organisations

First, let’s take a look at the challenges commonly faced by organisations who eschew prevention in favour of addressing incidents after they occur.

Business Impact – PR, reputational damage, customer confidence, legal costs, fines. This is the biggie. It’s a C-suite issue, so often doesn’t directly impact DevOps teams in the way the examples that follow definitely will.

Timing issues with the unexpected – Software security issues are like unexploded bombs.  You never know if, or when they might detonate. This makes for an impossible planning assumption.

All businesses aim to operate efficiently, rather than with an excess of spare resource.  When incidents occur, resources are always locked into other projects.  Normally, they are projects with deadlines, and business value. Diverting resources away from business priorities always has an impact.

The double-whammy – You have to deal not only with the business impact mentioned above, and the operational clean-up, but also need to fix the underlying root cause in the application.

Initially, research will be required to properly understand the issue. Sometimes the result is a minor code change, but often it can be a fundamental, architectural change that’s needed.  Dealing with the consequences and cause at the same time doubles up on the resource needed to properly address the situation.

Lost expertise – Fixing old code involves a lot of re-learning, potentially using older languages and tools. This imposes a further overhead which doesn’t occur when issues are fixed as the application is initially built.

A clustering effect – If one of the applications you develop is found to be vulnerable, it’s common for attackers (and researchers) to assume there may be more than just a single issue, and your application will see an elevated level of attention as a result.  This is why we often see multiple security issues in the same application released around the same time.

There’s a reason for this behaviour. Organisations that are found to have made one security mistake have usually made many such mistakes, normally for systemic reasons like training & awareness, testing processes, culture or available tools.

Even the ‘good news’ version of the story tends to be bad news. Not everyone is a bad actor, so responsible disclosure may mean you have some time to address any code security issues, rather than dealing with a public security breach, but that still creates a need to make urgent and unplanned changes in old code.

So why don’t we do prioritize prevention?

To be fair, app development teams increasingly do. And some are not only seeking to reduce risk, but also to optimize that processes.

However, for many organisations, a bias towards a recent (but narrow) experience of security not being an issue often induces an optimism about the future. “We’ve lived without it so far, so why change approach?”

Prevention only ever yields an intangible benefit.  As with the saying “You can’t prove a negative”. The lack of a tangible return on investment can discourage action.

A sense that ignorance is bliss with regards to the scale of security issues lurking in older, soon to be legacy, applications (which often have a shelf life longer than expected) drives organisations to rationalise doing nothing.

The best preventative measures

Aligning with DevOps best practice to ensure securing applications is part of the natural development and testing cycle, not an awkward add-on late in the process.  An approach often referred to as DevSecOps.

Integrated tools.  Having the right tools, automated into the development, testing and deployment process reduces the number of software security faults that make it through to production code.

Learning from Behavioural Data.  Consistent collection of relevant metrics help guide decisions about training, tools, releases and resourcing generally improves all aspects of software quality, security included.

Click here if you’d like to know more, or want to start you own DevSecOps journey.