Getting developers on board with security – once and for all

Making Web application security work is more than simply telling developers they need to write better code. We can scream “Write better code!” and “Integrate security into the application lifecycle!” at developers until end of time but that’s not going to fix the fundamental problems we have with unsecure software. Developers, by and large, know they need to write better code and integrate security into the application lifecycle. It’s like the average person knowing he or she needs to eat less and exercise more. However, just because people understand simple concepts and know certain things to be true doesn’t mean they’re going to do them.

I believe the reason why getting developers on board with security is not so cut and dried is something called the expediency principle. This principle says that people are going to take the fastest and easiest routes to get what they want without regard for the long-term consequences of their actions. Putting the expediency principle into software development terms: developers are going to develop software (the thing they want or have to do) in the quickest and simplest ways possible often ignoring the outcome of their choices (software security flaws that can be exploited for ill-gotten gains).

So what’s to give? If developers are going to take the path of least resistance, why even bother? The reality is, developers behaving in this fashion don’t have buy-in. It’s not that they don’t care. Rather it’s that developers are often not being held accountable. But how can we get them on board with security? I’m not saying it’s going to be easy but it is possible. Here are several things you can do right now to get started:

1. Find an advocate on the development team who’s interested in learning more about security and ultimately making things better for the business.
2. Get someone in management involved (i.e. the CTO, CIO, or CFO) who can not only set expectations and hold people responsible but also lead by example.
3. Invite developers to IT, compliance, security, and internal audit meetings so they can see how their actions affect these areas of the business.
4. Show developers what can happen when security flaws are exploited. Quite often developers haven’t even had a chance to slow down and think about the outcomes of XSS, SQL injection, session manipulation and so on. Some real-world examples can go a long way.
5. Share with them – even show them the ins and outs of – a good Web vulnerability scanner such as Acunetix Web Vulnerability Scanner that’s available to them throughout the development process.
6. Have them help you formulate a set security standards and policies that apply to software development across the board in your business.

Finally, it’s important to understand the reasoning behind why people do what they do. Psychologists have determined that people do things for two reasons: the desire for gain and the fear of loss. In other words, people want to get something positive (money, recognition, promotion, etc.) or they’re afraid they’re going to get into trouble (miss key system requirements, cause the business to fail to meet contractual or compliance requirements, get fired, etc.) as a result of their actions. This translates nicely into developers writing security code.

If we as information security professionals are going to get the right people on board in the right ways to improve software security it’s going to take some work. It’s all a matter of choice.

THE AUTHOR

Kevin Beaver

LinkedIn

Kevin Beaver, CISSP is an independent information security consultant, writer, and professional speaker with Atlanta, GA-based Principle Logic, LLC. With over 32 years in IT and 26 years in security, Kevin specializes in vulnerability and penetration testing, security program reviews, and virtual CISO consulting work to help businesses uncheck the boxes that keep creating a false sense of security.