Iâve done an amount of training developers recently, and it seems like there are a number of different kinds of responses to my security message.
[You can safely assume that thereâs also something thatâs wrong with the message and the messenger, but I want to learn about the thing I likely canât control or change â the supply of developers]
Here are some unfairly broad descriptions of stereotypes Iâve encountered along the way. The truth, as ever, is more nuanced, but I think if I can reach each of these target personas, I should have just about everyone covered.
Is there anyone Iâve missed?
Iâm always happy to have one or more of these people in the room â the sort of developer who has some experience, and has been on a project that was attacked successfully at some point or another.
This kind of developer has likely quickly learned the lesson that even his own code is subject to attack, vulnerable and weak to the persistent probes of attackers. Perhaps his experience has also included examples of his own failures in more ordinary ways â mere bugs, with no particular security implications.
Usually, this will be an older developer, because experience is required â and his tales of terror, unrehearsed and true, can sometimes provide the âscared straightâ lesson I try to deliver to my students.
This guy is usually a smart, younger individual. He may have had some previous nefarious activity, or simply researched security issues by attacking systems he owns.
But for my purposes, this guy can be too clever, because he distracts from my talk of âleast privilegeâ and âdefence in depthâ with questions about race conditions, side-channel attacks, sub-millisecond time deltas across multi-second latency routes, and the like. IF those were the worst problems we see in this industry, Iâd focus on them â but sadly, sites are still vulnerable to simple attacks, like my favourite â Reflected XSS in the Search field. [Simple exercise â watch a commercial break, and see how many of the sites advertised there have this vulnerability in them.]
But I like this guy for other reasons â heâs a possible future hire for my team, and a probable future assistant in finding, reporting and addressing vulnerabilities. Keeping this guy interested and engaged is key to making sure that he tells me about his findings, rather than sharing them with friends on the outside, or exploiting them himself.
Unbelievably to me, there are people who âdone a project on itâ, and therefore know all they want to about security. If what I was about to tell them was important, theyâd have been told it by their professor at college, because their professor knew everything of any importance.
I personally wonder if this is going to be the kind of SDE who will join us for a short while, and not progress â because the impression they give to me is that theyâve finished learning right before their last final exam.
Related to the previous category is the developer who only does what it takes to get paid and to receive a good performance review.
I think this is the developer I should work the hardest to try and reach, because this attitude lies at the heart of every developer on their worst days at their desk. When the passion wanes, or the task is uninteresting, the desire to keep your job, continue to get paid, and progress through your career while satisfying your boss is the grinding cog that keeps you moving forward like a wind-up toy.
This is why it is important to keep searching to find ways of measuring code quality, and rewarding people who exhibit it â larger rewards for consistent prolonged improvement, smaller but more frequent rewards to keep the attention of the developer who makes a quick improvement to even a small piece of code.
Sadly, this guy is in my class because his boss told him he ought to attend. So I tell him at the end of my class that he needs to report back to his boss the security lesson that he learned â that all of his development-related goals should have the adverb âsecurelyâ appended to them. So âdevelop feature Xâ becomes âdevelop feature X securelyâ. If that is the one change I can make to this developerâs goals, I believe it will make a difference.
Iâve been doing this for long enough that I see the same faces in the crowd over and over again. I know I used to be a fanboy myself, and so Iâm aware that sometimes this is because these folks learn something new each time. Thatâs why I like to deliver a different talk each time, even if itâs on the same subject as a previous lesson.
Or maybe they just didnât get it all last time, and need to hear it again to get a deeper understanding. Either way, repeat visitors are definitely welcome â but I wonât get anywhere if thatâs all I get in my audience.
Some developers do the development thing because they canât NOT write code. If they were independently wealthy and could do whatever they want, theyâd be behind a screen coding up some fun little app.
I like the ones with a calling to this job, because I believe I can give them enough passion in security to make it a part of their calling as well. [Yes, I feel I have a calling to do security â I want to save the world from bad code, and would do it if I was independently wealthy.]
Sadly, the hardest person to reach â harder even than the Salaryman â is the developer who matches the stereotypical perception of the developer mindset.
Convinced of his own superiority and cleverness, even if he doesnât express it directly in such conceited terms, this person will see every suggested approach as beneath him, and every example of poor code as yet more proof of his own superiority.
âSure, youâve had problems with other developers making stupid security mistakes,â heâll think to himself, âBut Iâm not that dumb. Iâve never written code that bad.â
I certainly hope you wonât ever write code as bad as the examples I give in my classes â those are errant samples of code written in haste, and which I wouldnât include in my class if they didnât clearly illustrate my point. But my point is that your colleagues â everyone around you â are going to write this bad a piece of code one day, and it is your job to find it. It is also their job to find it in the code you write, so either you had better be truly as good as you think you are, or you had better apply good security practices so they donât find you at your worst coding moment.