Why application security should be a key part of development [Q&A]

As data protection legislation tightens and breaches continue to make headlines, there is increased pressure on businesses to implement security by design in their applications.

For many this has meant a move to DevSecOps. We spoke with Rusty Carter, vice president of product management at application security specialist Arxan to find out why this approach is becoming essential.

BN: Why are businesses turning to DevSecOps?

RC: The push to DevOps from a business point of view is increasing rapidly. The critical piece that is generally missing from many approaches is that we need to make developers smarter about their code and operations side to detect security vulnerabilities and risks.

Trying to teach developers security techniques is getting them to do something that is not their core business. There's going to be a conflict between putting security features in an application and delivering business value and functionality to the end user.

The second part of the problem is that the types of things going into the education of developers are ineffective against the vulnerabilities that exist. There are trivial attacks that can reverse engineer an application or exfiltrate data. Good coding should prevent this, but just scanning a piece of software as an initial part of the DevSecOps process doesn't get at the core of the problem.

BN: What is at the core of introducing DevSecOps practice?

RC: The real intent of DevSecOps at a fundamental level is to introduce security and improve the security of an application with a very fast delivery. You are continuously integrating software and delivering apps to the market and you want to do it safely.

BN: Do we need to look at security right from the start of the software lifecycle?

RC: Absolutely, but a key point is to leverage the specialisations that we already have. Teaching developers how to implement cryptographic algorithms is not productive, but you can incorporate security though existing technology such as ours and leave developers to creating business logic. All of these things have to work in concert with one another. Whatever you are putting into the application it needs to be implemented and sent back, then the operational result needs to come full circle and inform the development. The way to do that is to integrate technology that has solutions for individual things but which also feed one another with telemetry about their status. This is the end goal of DevSecOps.

BN: As DevOps has become more common has compliance failed to keep pace?

RC: In many businesses you are competing against time to market. For some industries speed to market is critical in providing the best customer experience. The other side of that coin is without security you will experience a breach and customers will stop trusting you and go elsewhere. Including security by design as a default underlines all of DevSecOps.

BN: Is adoption of DevSecOps being driven by legislation such as GDPR?

RC: GDPR is pushing on this, but many businesses are simply looking to fill a check box to say that compliance is covered and that's not the right approach. The ultimate problem is customer trust, before the internet when you did business face to face if you didn’t trust someone you walked away. The same human characteristic exists today but through software and the manifestation of a loss of trust is becoming much more about loss of data, loss of privacy and in some cases a perceived negligence. Areas like medical devices, automotive, banking and finance are key ones when it comes to security. Retail and hospitality and eCommerce are important when it comes to privacy too.

BN: DevSecOps is aimed at eliminating vulnerabilities but can it also help speed up fixing problems that do creep in?

RC: Yes, the vulnerability race is one that will never be won. You have two adversaries, one trying to build the wall, the other trying to find a way through it. Ultimately nothing is impenetrable. The real opportunity that DevSecOps creates is speed, if you are able to stay ahead of the attacker then even if there are vulnerabilities that will some day be found you have the ability to react to them before they become a problem for the business.

From a market standpoint the businesses that have been least affected by breaches are those that are able to respond quickly to an attack. This responsiveness dramatically mitigates the loss. If you can detect an attack as it's beginning you have an opportunity to mitigate it before it becomes a breach.

BN: Are we reaching a tipping point where DevOps/DevSecOps will become the norm?

RC: Yes. The velocity is increasing, the concept of DevOps has been around to the point where governments, defense, infrastructure, where software is involved, even these very 'traditional' businesses that move slowly and methodically are adopting DevOps.

We're also seeing more commoditization of hardware which means you can control more things with software because it’s faster. The path is set and the pace is increasing, DevOps is probably in the majority now and DevSecOps is starting to catch up.

Image credit: mikkolem/depositphotos.com