In order to reduce the risk to our applications, we must start hiring resources that come in with some level of secure development knowledge. As a matter of fact, it shouldn’t even be thought of as security knowledge, but just good development knowledge.
Job Description
The first question that pops up is around writing job descriptions. How much “security” should be in a job description for a developer role? Does it change from entry level engineer to a senior level engineer?
I think there does need to be some mention of security in the job description because it lets the developer quickly see that security is going to be important in their role. It creates on opportunity to distinguish developers from one another. It forces a trend where resumes for these roles will start to contain some indicator of secure development experience.
Updating job descriptions may have a direct impact on the current team members. Make sure there is a clear plan to help the existing team members elevate to these new requirements in a dedicated time frame. This will show that there is an expectation for everyone to get to that baseline, but the changes won’t immediately affect them and they will have time to get there. Hopefully, you will already have a plan in place to help provide direction or training for them to meet these expectations.
Interviewing
You might think that for the interview we want to grill the candidate on their knowledge of the OWASP Top 10. Ask for explanations of Cross-Site Scripting, SQL Injection, or Server Side Request Forgery. Fortunately, that is not where I am going with this. While I want people to understand the risks to the application, I don’t believe they have to focus on the security terms associated with it, not the nitty gritty details around it.
So how can you determine if a candidate has some secure coding knowledge without bringing up specific security terms? Here are a couple thoughts.
Don’t start with the security terms
Don’t start with questions like “Can you tell me what XXE is and how to exploit it”?
Jumping straight to security jargon will throw people off and most likely make them uncomfortable. Instead, if you want to see if they have some understanding of secure coding, present the question just about configuring XML parsers. “You are developing a function to Parse XML Files, what are some configurations you should be considering?”
This starts a discussion of XML parsing, opening it up for them to start showing if they understand External Entities and the risk they may provide.
This can be expanded to other vulnerabilities or just other secure development processes. For example, you can discuss how they may have handled 3rd party components in the past or even what type of secure development training they may have had. I will cover some more scenarios in another post.
Where to start
Sometimes the hardest part to any change is just getting started. In this case, it is good to start with reviewing the current job descriptions to get some ideas of what additions you may be looking to add. I like to do this before reaching out to the development leadership group so that I am coming in with a plan. That plan should be flexible, but it is a starting point. Then you can start working with leadership and the development team to fine tune the requests.
It is good to start small. Don’t try to put a bunch of security requirements in at the start. Start simple and build a plan to continue increasing the requirements over time. Too much modification up front may cause too much friction and slow the implementation.
Collaboration with the different teams is going to be critical. It won’t work if security just tries to push new requirements into development job descriptions. Most likely, they requests won’t line up and it will fail. Working with the different teams will create a more successful implementation.