So your developers don’t care about security? They shouldn’t have to

Say your company is fully committed to web application security. You have lots of security tools, you scan for vulnerabilities on a regular basis, and you’ve invested in educating your developers about SQLi, XSS, RCE, and other weaknesses. And yet – even in new code, your scanners keep finding the same vulnerabilities. Your application security is either not improving or is improving far too slowly. What is going wrong?

OPINION I recently came across a no-holds-barred post by Mark Curphey. Based on his extensive experience in managing security and development, Mark states bluntly that “the vast majority of developers don’t care about security” and that educating them will not help. He even goes on to say that “‘developer education and awareness is the key’ and similar phrases are muttered at security conferences everywhere.” Ouch. I confess that’s also been muttered here at Invicti more than once. 

Mark’s opinion comes straight from the source and is based on real experiences. And while I’m not as pessimistic as he is, he makes some valid and important points that we need to expand on.

“I had to ship features or my boss would get mad”

Even with extensive developer education and the best intentions of the developers, security will not be a priority if management does not prioritize it. If developers are under pressure to deliver features and are not given the time and resources to incorporate security, they will ignore security – simple as that. Their management may also believe that secure development means spending an extra five minutes when reviewing the code. If management had ever tried to build effective XSS filter routines on their own, they might realize that it’s not five minutes but closer to the fate of Sisyphus.

It takes a significant amount of time and effort to secure software. Everyone in a development organization needs to understand this, remember it, and consider it in all and any development plans. If this isn’t done, don’t blame the developers. Anyone who pushes for quick releases before they are ready also needs to take responsibility for any security flaws in your applications.

“All developers will do the right thing if it solves a problem that they have”

Mark goes on to make a point that the AppSec mutterers among us can only wholeheartedly agree with:

“If you want to improve application security (…), stop trying to make developers care, accept they don’t, and start deploying solutions that solve a problem that they care about that as a side effect improves security or allows you to tag security on later.”

There’s no question that if you want secure software, you must empower your developers to build it. How? By giving them the appropriate development and security tools that they can use without messing up their workflows. For example, many frameworks include secure functionality for user input processing, and standardizing on using these features will eliminate the causes of most injection vulnerabilities.

Such decisions are primarily for software architects and those overseeing high-level design and development decisions. Faced with tickets and sprint deadlines, your development teams on the ground will not be rushing to find secure solutions, such as a library to filter user input or introduce parameterized queries. But if you prepare for this in advance, you can instruct them to use specific programming language elements. For example, you can build an internal library that uses tools such as ESAPI or AntiXSS and prepared statements for all SQL queries, and instruct developers to use only that library for any input processing.

In fact, I would even go a step further than Mark because humans are inherently lazy – and lazy is good when it saves effort but not so much when it compromises security. Even equipped with the best tools, a developer may go for a less secure solution if it’s simpler. So there must be a stick in addition to the carrot. Block constructs such as eval and shell_exec. Add allow_url_include = Off to your php.ini. Disable all unnecessary URL schemas. And last but not least, enforce a security scan after every commit and make passing it a requirement. Do whatever it takes to minimize security risks at every step of the pipeline – and if developers object, show them secure and practical ways of resolving issues and avoiding them in the future.

“Get over it and move on”

Though admittedly in very different words, Mark echoes the message we’ve been trying to get across for years: that application security tools must not get in the way:

“I think we should accept that developers only pay lip service to security, get over it, and develop security solutions that first and foremost solve a problem that developers have. (…) Getting over it and moving on doesn’t mean you can’t still enable developers to build secure software, it just means you take a different, less direct approach.”

I’ve written before about the reasons why developers shun security, and Mark mentions one typical offender in the form of “useless code review findings filtered from a tool by some intern at an accounting firm playing security consultants on the Internet.” Getting a list of cryptic and questionable findings doesn’t help anyone. Instead, get a helpful tool that, first and foremost, does not bombard developers with false positives. Remember that every false alarm from a security tool brings your developers closer to ignoring security completely. Instead of having them nap during security lectures, give them proof of a successful exploit, show them where the vulnerability was introduced, and teach them practically how to fix security bugs right away.

Yes, Mark, let’s move on. And, as we move forward, let’s make sure the tools we use to assess application security solve the developers’ problems rather than adding to them.