I am the manager of a small team of software engineers. One member of this team write very insecure code. I have tried showing him documentation like the OWASP Top 10, but he just doesn't get it. I can't knowingly put vulnerable code into production. So what do I do with this programmer?
+3
A:
You could just open a new bug report each time you see a security problem in his code. Eventually he will get the idea, or at least learn a thing or two...
Justin Ethier
2010-04-14 01:45:13
"I admire your optimism."
Tom Hawtin - tackline
2010-04-14 01:57:09
Now which Spolsky article was that again...
NomeN
2010-04-14 03:03:45
+3
A:
Communicate to him. In writing
Establish written coding standards. Including security.
Include fixing the problem in his performance reviews.
Explain to management the risks/costs associate with violating.
If he violates, refer him to management/HR
Or, if you don't wish to get rid of him for some reason, stick him on tasks that are not security sensitive - test writing, utilities, code prettyfying, styling, etc...
Also, please don't literally follow your own answer ("just fire him"). Without following points #1-5 you'd be opening yourself to lawsuit risk etc... - even though that (firing) might be the desired outcome.
DVK
2010-04-14 01:48:38
+1
A:
Train them. As you have a leadership role in your development team it is your job to assist in bringing developers up to the standards that are expected of your team. If you've already invested a large amount of effort into this person and they have achieved no success and aren't clearly focused on attempting to do better. At that point I think it is time to consider letting them go or moving them to a more junior level project that is fitting of their ability.
Chris Marisic
2010-04-14 01:49:15
+11
A:
Have you considered doing code reviews with your team?
Don't single out this particular programmer, rather review everyone's code. That way he will learn from his peers how they code for security, see examples of how they do it, and learn why they consider it important.
If after doing this for a while he does not come up to a level that the other team members can respect, it will become obvious to all and you will not be viewed as heavy handed or the "bad guy".
A side benefit of code reviews will be higher quality, more secure code from all members of your team.
JonnyBoats
2010-04-14 01:51:16
Instead of firing him, you could 'fire him' from working on code that touches authentication. No writing SQL, no writing public APIs (especially 'services'). If he's a good engineer other than that, how about have him work on consolidating your utility code into a core library? All of the parsing and data shuffling routines need love too. If he's not even good at that, then ask yourself if morale will go up or down if you let him go, and do what you have to do.
Jason
2010-05-05 20:36:01
Another option is to assign him to things like infrastructure, administration and toolsmithing - getting your build environment in order. However, I tend to think of myself - and hear few complaints - as the one on my projects with the greatest attention to detail (read: The pickiest person in the group), and I often grab some of these tasks for myself, even when I'm the lead. Why? Because they're so deceivingly important to do right. If a person can't be bothered to scrub their data inputs, you probably don't want them being the one greasing the gears of your proverbial engine either.
Jason
2010-05-05 20:47:58
@Jason You have a good point on a large software project there is plenty for someone to do that has little or no security impact.
Rook
2010-05-05 23:00:19