Call it the blame game or just a vicious circle. The long-standing tension between developers and IT security experts is not easing anytime soon. Each side blames the other for security risks in application security and other areas, but digital defense overall will suffer unless the two sides come together. We spoke to Vikram Kunchala, U.S. lead for Deloitte’s cyber cloud practice, about helping security and developers work together.

Who’s Responsible for Application Security?

Results from a recent GitLab survey underscore the issue: most security professionals lack faith in developers’ ability to write secure code, while most developers feel they lack proper guidance. What’s worse, many companies surveyed aren’t being serious enough about their defense.

What’s lacking most, however, is clarity. Within a typical group, there needs to be a more explicit consensus on who the onus of defense falls on at the end of the day.

There is work to be done. One-third of security respondents to GitLab’s survey expressed they were on the hook for security, but almost as many (29%) felt that everyone was responsible. Others (21%) put the onus on developers, while12% believe operations should be responsible.

How can the two teams work together for the greater good?

Shifting left will be a good start. If you’re not familiar with the term, shifting left moves security earlier into the application process instead of accepting it as an afterthought. Shifting left allows the entity to tackle defense issues early and throughout the entire process.

The Importance of Secure Code in Application Security

Kunchala says secure code is more critical today than ever before due to remote working. Kunchala, who formerly led Deloitte’s application security practice, explained that knowing the risks of a pure remote workforce is critical for a good cyber hygiene interface.

“Your attack surface is much larger now. It’s not within the four walls of your enterprise,” he says. “Application security should be a top priority. The biggest attack vector is the application layer.”

This focus on application security is nothing new, however. Because most attacks occur at the application layer, Kunchala says, the focus on building secure code has been happening for the last decade. And with that focus, of course, the push and pull between developers and security experts has increased.

In dealing with multiple clients across a diverse set of industries, Kunchala suggested that those groups in which defense is built into the culture have less friction for application security. Of course, it’s highly dependent on the industry. For some, like health care and finance, security may be more at the forefront. For others, it may not be as critical.

“It’s a mixed bag, and a lot of that is defined by how the company perceives security, and how important security is for their products and solutions,” he says.

Inside the Mindset of the Developer

With higher and higher demand for more software and apps, even more so in today’s business climate, the top priority for any developer is to get the code out quickly. It’s a harsh reality and puts undue pressure on development departments. In fact, GitLab’s survey reports 82% of developers are releasing code more quickly — in some cases, two- to five-fold speed increases.

What it boils down to is what people consider most important.

“If I’m a developer, my charter is to get functional and good quality code out, because there’s a speed time to market,” says Kunchala. “So security is probably not on top of my mind.”

But to developers, and in most business entities, good quality code means that it meets organizational and business goals.

“That’s the developer’s perspective,” he says. “The problem is that both are operating on different priorities.”

Making security the best it can be, from a developer’s perspective, is like a cop with a radar gun slowing them down when they only want to go faster.

Security Experts: How to Find Common Ground

From a security expert’s perspective, it’s not difficult to pin down how we’re thinking. We want developers to code with application security built in.

But instead of talking about the mindset, it’s more important to explore how security experts can work with developers to achieve the collective goal of secure code.

When it comes to the cop with a radar gun, security experts counter it with their own ‘here’s a driver driving without seatbelts or the right controls’ analogy. But seatbelts weren’t created to slow you down. By the same token, security isn’t meant to slow developers down, either.

Security should help you go faster as a developer, says Kunchala, if you know that the right guardrails and controls are in place. “It’s important to make that connection.”

According to Kunchala, there are three critical steps security experts should consider when helping developers with secure code.

1. It doesn’t have to be perfect. 

The biggest hurdle for developers in adopting a security mindset is knowing what good defense looks like. You don’t need it to be perfect. After all, there is no such thing as perfect, in application security or elsewhere. But developers need to have a framework to say something like, “If I do these ten things, I’m on the right track.”

2. Security for developers should be frictionless and easy to consume. 

If it takes a developer four weeks to develop code and then five weeks to address security, that’s a recipe for disaster. The development security team should be able to expose the services they provide through a seamless application programming interface consumption-based model. That way, developers, as part of their process, have the guardrails to understand precisely where to consume this service.

3. Shift left. 

Shifting security left is all about shifting the mindset that you need to build it early instead of bolting it on at the end.

For a developer looking to create a product or an app, they need to engage with application security teams to answer several questions that drive various risk elements:

• What kind of app am I building?
• What is the risk it poses to the business because of the data it captures or the geographical factors?
• Are you working with on-prem apps or cloud-based applications?

Then, after mapping based on the risks, defense teams can present controls that need to be put in place, handling the controls that must not be left out first. Those teams must provide an easy way to consume these controls as part of the development process and CICD (continuous integration/continuous delivery) pipeline. This way, you can develop a method of narrowing down the number of critical defects that go out.

“It’s really a collaborative game,” says Kunchala. “It takes a village to get this right.”

Countering the Push-Back

Over the last few years, given the increasing threats, the default reaction from the application development teams has been to push back. Now, security experts need to make defense easier to do. Kunchala suggests tackling the most common problems first before starting to address the more obscure areas of application security.

First, address the Open Web Application Security Project (OWASP) top 10. For example, you shouldn’t have any cross-site scripting or SQL injection vulnerabilities. After focusing on the more basic risks, you can help developers build on the rest of the layers.

Next, ensure that application security and other security scanning is done early in the process.

“As soon as you do the build, scan the code,” Kunchala says. “As you write the code, you should be able to plug in software that tells you if there’s a better way to write a line or section.”

Perhaps the most critical advice you should impart to the development team is that the longer it takes to fix the issue, the more expensive it gets.

“It’s no different than building a house,” he says. “If there’s a foundation problem, you can’t wait until after the roof is up to fix the foundation issue.”

Equally important is to quantify the impact of insecure code. For example, if an app were to go down or be exploited, the impact to a company’s brand, customer loyalty, good name and bottom line can be dramatic.

If a hotel’s reservation system goes down, that business could face millions in losses quickly. Framing your argument in the context of business loss helps developers realize the need to put security up front.

“Having good hygiene and being known for building secure solutions actually improves the trust factor of the company,” Kunchala says.

Winning at Application Security and Beyond

In the end, solving this developers-versus-security dilemma is no different from getting over other defense hurdles. Any company that embraces a security culture will always be a step ahead of those that do not. That applies to the development process as well.

Besides, when your company puts application security and other defenses first, you’re putting the customer first, too. When surveys tell us that 78% of U.S. respondents believe it is extremely important for a company to keep their data private, building security into your product or service is putting your customer first. And, there are numerous strategies for fostering a defense first-culture.

Above all else, you’ll need to ensure buy-in from the C-suite. Don’t forget to include managers, key stakeholders and relevant IT teams in the process, and update them (with easily readable documents and slides) as often as it takes.

“With any process, security should be built in, not bolted on,” Kunchala says. “Anything that organizations can do to consider shifting left and start engaging security at the conception phase is going to be beneficial.”