The Disconnect Between Developers and Application Security

As a developer, your responsibilities are wide-ranging as it is — just take a look at what some people refer to as the job description for the mythical “full-stack developer” as an example. Often, “security professional” is a role that can make its way onto that list. You are already concerned with producing a high-performing app that meets quality goals and is easy to use. How can you be expected to be a security professional too?

According to Scott Gerlach, co-founder and Chief Security Officer at application security firm StackHawk, you can’t, and shouldn’t. Gerlach offered this as the first of three points for why developers struggle with AppSec, the title of his panel at last week’s All The Talks virtual conference put on by Snyk.

“You never see the accountants do this to an executive when the executive team goes ‘Hey, we need to model a price increase or change the cost structure for one of these products that we have.’ The accountants don’t go ‘Sweet. We’d be happy to help you with that but let’s teach you about the General Ledger first.’ They don’t have to understand to the nth degree how accounting works, how the General Ledger is set up in that organization, all the details of what the accountants are doing,” said Gerlach. “They can just quickly decide. Plug in information, make decisions. We should do more of that as security teams. We should provide the organization, specifically when we’re talking about AppSec, with tools and information so they can make decisions, so they can decide quickly and get on the path of getting that product out into production.”

While security teams may expect developers to care about security, it’s often a topic at the bottom of their list of concerns, and instead of adding security to their list of responsibilities, providing developers with developer native tools can help to bring security into the workflow. Rather than expecting developers to learn the ins and outs of being a security professional, these tools can help guide them to make decisions with security in mind.

Gerlach’s second and third points both refer to a misalignment, both in expectations of roles and in how the different parts of a business interact with the security team. For example, AppSec teams can work really hard to find security issues and take pride in that process, but then simply throw it over the wall to the developers rather than trying to work together to find a solution.

“We approach the end part of that the wrong way. We come back to engineering and go ‘Hey I broke the crap out of your thing, isn’t that awesome?’ and no one thinks that’s awesome. No one thinks that the hard work that they put in needs to be demonized in the way that we tend to do it because we’re so proud of the thing that we did,” said Gerlach. “That’s another one of those bridge-building functions where we can partner with engineering teams to say, ‘Hey, let’s get together and talk about how this attack worked.'”

“For us to say everything that we find should be fixed is just disingenuous. We’re not in the business of fixing, patching, we’re in the business of providing a service to a customer.”

Not only is there often a lack of communication, says Gerlach, but the security team is so far removed from the development lifecycle that the holes they find may harken back to a change made by the development team weeks if not months ago. Part of the solution here, he says, is to work more closely together to make sure the efforts of both developers and the AppSec team are spent on worthwhile endeavors, which brings us to the last point — the misaligned expectation from the AppSec side of things that demands that developers fix all of the things.

“For us to say everything that we find should be fixed is just disingenuous. We’re not in the business of fixing, patching, we’re in the business of providing a service to a customer, and we should be prioritizing heavily the things that are really, really important, and being able to understand in the context of the organization what are those things that are really, really important,” explained Gerlach.

In his closing thoughts, Gerlach offers that security needs to be democratized through an organization, through the use of tools and information, but that the oft-repeated refrain that “security is everyone’s responsibility” is more a cop-out than anything else. He ends on this point, referring back to his original point about accountants not expecting executives to know the ins and outs of accounting to make their decisions.

“That’s just not how it really works. Accounting is not everyone’s job, pieces of accounting are your job — turn in your expense reports — but accounting is the responsibility of the accounting department. Chances are, everyone is not responsible for cleaning the restrooms, janitors are responsible. We’re responsible for picking up our little pieces of trash. Saying security is everyone’s responsibility is probably just way too broad.”

Developers, in the scenario, again care about code quality and performance and efficiency, and if AppSec teams are going to expect them to care about security, they need to provide them with the tools and information to more easily do so in a way that aligns with their abilities and knowledge.

https://youtu.be/d_FEqZKI-dM

Snyk is a sponsor of The New Stack.

Feature image via Pixabay.