Secure code review requirement for cybersecurity engineer hiring

Question

I am the team lead on the IT Security team where I work. Recently we were interviewing for an security engine role. One of the traditional security / SOC engineer roles in all the places I worked is leading security code scanning and vulnerability remediation.

When I asked candidate what experience they have with static and or dynamic code scanning tools (SAST / DAST), they responded they used tools such as BurpSuite and SonarQube among others but the security code scanning process is more owned by development , not the cybersecurity. These candidates come from well known companies with mature histories so I expected much more more security ownership in the code scanning / vulnerability management process.

As this candidate has significant experience in working with our suite of security tools such as BurpSuite, MetaSpoit etc, I dont want to pass over them simply due to them used to a different process. However, the willingness own the code scanning vulnerability management processes is a critical requirement of the role.

• Is ownership of secure requirements during development by teams outside of cybersecurity a common occurrence in big, mature companies?

• How should I evaluate candidates with significant experience in using the technical tools of our team but may not have experience owning processes or are used to working using a significantly different process owned by another team?

Answer 1

more owned by development, not the cybersecurity

That's absolutely reasonable. Since development is the department that can actually do something about it, it's pretty pointless to let them run in one direction and later tell them they need to redo their work because automated scanning found a vulnerability. I don't let someone drive straight into the sunset and call them half an hour later like "hey buddy, my navigation device says you would have needed to turn left here". The tool should be used by the people that can change the outcome and it should be used as soon as possible, not after the fact.

It should be normal to have development run those scans while developing and security to run them again (or request the reports) just to make sure development did their jobs or to find vulnerabilities in parts of the system not in the hands of in-house development.

As far as big and mature goes, that's hard to guess. I have seen big, I have seen old, but mature is really something completely disconnected from those two. I think you are way ahead on the maturity curve by just having a cyber security department or team in the first place.

How should I evaluate candidates with significant experience in using the technical tools of our team but may not have experience owning processes or are used to working using a significantly different process owned by another team?

I have the same question with project planning processes. For example Scrum. It's always good to have someone with experience, but in the end, it's not their choice. if their old company did not do it, it's not in their domain to change it.

So what I do is I will evaluate based on what they know about it theoretically and if they are open to doing it. It's not their fault they did not do it before, as long as they are interested and willing. I will draw the line at "never heard before" though. Even if the former company had different guidelines and departmental organization, if someone hasn't heard about the thing, that means they did not properly educate themselves through books or conferences or usergroups or whatever else one can do to keep up to date.

Answer 2

I'm failing to see the problem here.

When I asked candidate what experience they have with static and or dynamic code scanning tools (SAST / DAST), they responded they used tools such as BurpSuite and SonarQube among others but the security code scanning process is more owned by development , not the cybersecurity.

... is NOT inconsistent with:

Willingness own the code scanning vulnerability management processes is a critical requirement of the role.

One is simply saying, "I know about this topic, though the emphasis in my past jobs wasn't the same" and not "I refuse to take responsibility for this."

It's the exact same thing as McDonalds interviewing someone for a drivethru worker that said, "Yeah, I'm comfortable taking the orders as well as manning the window. Though where I worked last, they were handled by two different people."

You're not going to say, "Dude, that applicant refused to work drivethru!" Because it's not true - they're simply saying the last place they worked had a different process, not that they're refusing to do something!

Same thing with your applicant. Did they actually say, "I refuse to handle code scanning!" Because, otherwise, you're making a mountain out of a (nonexistent) molehill.

Answer 3

Yes, ownership of tasks such as vulnerability scanning and vulnerability remediation is increasingly owned outside of a centralized security org in many organizations.

This is almost universally recognized as a benefit - the centralized security team model has been failing for 30 years to product secure systems and applications. Therefore “shifting left” these functions into the teams that actually create the software and have the ability to actually fix vulnerabilities is an accelerator to actually achieving the goals of security.

Here you have a opportunity by hiring new blood to actually learn newer, more effective approaches from the industry. There’s still a role for dedicated cybersecurity professionals in this new way of working (which is why you are talking to a bunch of people with those skills, that just aren’t obsessed with old command and control style organization). You could use these newer-skilled folks as you pivot your focus to education, empowerment, and centralized reporting instead of insisting on “owning” everything. Because when you say “owning” you don’t really mean it - security groups still own the approach even if performing these tasks is decentralized into the teams (that is the process the organization uses in this case) - you mean micromanaging it. I’d strongly encourage looking into the DevSecOps track at RSA or other similar venues to learn about newer approaches (maybe like hiring someone that knows them, even).

As for “how to interview someone who’s used a different approach” - well, interview them on their skills, and also talk with them about your approach. I’ll be honest, it’ll probably cause a number of them to discontinue pursuing the job. I had a similar discussion with a tech department at a large home improvement retailer about leading a Web application performance team - I had done this previously by empowering development teams with tools and techniques and leading the setting of department-wide goals. I had a conversation with some upper managers about how “no we expect YOU and your team to own it and do it, not that hippie stuff”, and I decided not to pursue the opportunity because they were basically artificially constraining how successful it could ever be, and life in tech is too short for that noise.

Answer 4

How should I evaluate candidates with significant experience in using the technical tools of our team but may not have experience owning processes or are used to working using a significantly different process owned by another team?

Evaluate them based on their skills, experience, and merits... not by the processes their current/former employer used or is using. You're bringing them into your company and your processes.

Answer 5

For me personally, as a Ruby on Rails developer, I generally think of "cybersecurity" as what is traditionally referred to as perimeter security and network security, or in a cloud context could be thought of as cluster security or cloud security.

Being an application developer, I tend to agree with your candidate that in the app dev realm, it is the app developers who are responsible for write our own secure code. I tend think it is best for the developer to write their own secure code, and best for the application. When it is "someone else's job" to make my app secure, I'm bound to pay less attention to it.

it seems to me that this answer is perfectly valid from an application developer, but perhaps you want a security specialist, like perimeter and network security. Hence, the linguistic distinction.

Answer 6

Here's an option that is frown upon by some, and accepted by others: Send them a take home exercise. Provide a temporary license for the tools, describe a workflow, along with code to review and tasks to do.

The great candidates will pick up the flow you want and leverage their knowledge of the tool. The bad ones will submit the bare minimum or just give up.

Depending on your company culture and legality of it, you may elect to pay the candidates a token amount, say 4h or 8h pay. Still cheap compared to your interviewers' time or a plane ticket to the in-person interview.

But it's much more work to setup and maintain. YMMV.

PS : A docker image, all setup with the tools and task is easy to install and will tell you the difference between those who can figure stuff out and those who can't.