Constructive Security Training For Application Developers That Works

Talk to developers in their language-code and make security ramifications visible so they have a reason to improve their habits

Dont believe the lie that developers dont care whether their application code causes expensive vulnerabilities for their organizations. If the dev team is apathetic, then chances are that the security team and IT leadership arent giving them a reason or the means to care, application security pundits say.
If you ask any developer, Hey, do you want to write code that is going to potentially cause millions of dollars of losses for the company? most of them are probably going to say no, says Bill Pennington, chief strategy officer of WhiteHat Security.
The problem is that much of todays security testing and training isnt tailored to suit the way developers think and do their jobs, says Ed Adams, CEO of Security Innovations, who agrees that developers want to write high-quality code.
[How can you start instituting a secure software development life cycle? See
10 Commandments Of Application Security
.]
Remember that most software developers are engineers. If youre asking them to do something, give them a reason why, he says. And then give them the method to do what you ask.
For example, today a lot of security pros think it is good enough to leave the dev team with a policy statement along the lines of, Write all Web applications so theyre not vulnerable to common threats on OWASPs Top 10 list.
Thats great, but it means nothing to a developer, Adams says, explaining that it leaves the developer to figure out what the top 10 is, then drill down into each statement on the list and try to figure out how that actually applies to the way they code applications.
Its a pet cause for Romain Gaucher, lead security researcher for Coverity, who says that at the moment, security people dont give developers complete advice that they can apply right away in their work environments.
Security people should be able to talk to developers with code, he says. They should do it with code examples and how to actually do the thing properly, not with very generic advice.
This could be a problem for some security professionals who are usually not developers by trade, says Adams, who adds that security training should come from developers who can speak the language of their brethren.
If it isn’t a developer doing the training, you’re bound to get questions that can’t be answered, which will frustrate the developers even further, he says.
In addition to taking this more pragmatic approach to offering advice, organizations should also be seeking ways to make security problems and goals more visible to developers on a day-to-day basis. In the hunt for greater testing efficiency -- a good thing -- many organizations have done a lot to obscure security from the developers line-of-sight by using frameworks, prewritten libraries, and routines for things like input sanitization, authentication, and cryptography, Adams says. Thats not very conducive to developer training.
That’s a good way to ensure developers are doing the right thing. But you cant prewrite everything. Developers still have to write integration code to tie in the business logic, not to mention the rest of the functionality, and it is very easy to write insecure code if you arent trained properly, Adams says. The implementation of security during development can feel invisible; however, implications and importance of security should be quite visible to developers.
Nick Galbreath, vice president of engineering for IPONWEB, says he strives to make security more visible among the developers at his organization. One of the big ways to do that is by giving developers regular data from security tools about the types of attacks hitting their application infrastructure so they can see what theyre up against.
Instrumenting real-time graphs like SQL injection, cross-site scripting, and all of the garden variety junk that comes in from scanners actually educates everyone -- management and developers, he says. If you start instrumenting it so you can see these probes and attacks come in, developers are actually pretty interested in it, and it really is a great way of engaging people.
But dont just give them real-time information feeds to raise awareness. Also consider crunching the data with analysis that shows them the most common security issues and tying them to root causes within the code.
Theres a bazillion things you can screw up when writing code or deploying applications, says David Mortman, chief security architect for enStratus. So if you can, start measuring where youre screwing up and how youre screwing up.
Not only can this improve the way that code is developed, but also how it is implemented.
Theres no point in spending a lot of time talking about SQL injection if everything is cross-site scripting [in your environment], he says. And theres no point in harassing developers who were writing code securely if the problem is that the ops keep screwing up the configuration files or something like that. If youre going to improve things you have to know where youre breaking things first.
Have a comment on this story? Please click Add Your Comment below. If youd like to contact
Dark Readings
editors directly,
send us a message
.

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Constructive Security Training For Application Developers That Works