Do you need to be a coding expert?
I think it's time to put another AppSec career blocker in front of the firing squad.
Today's target is the ridiculous and unrealistic requirement of "Expertise with a programming language" in many AppSec job postings.
This "requirement" is a concern and worry for people trying to break into the industry and can put some people off permanently. Who can blame them? Knowing and understanding the ever-changing landscape of application security is hard enough, let alone the expectation of being competent developers too.
So do you need to dust off your "Foo's" and "Bar's" to get a job in AppSec?
For an entry-level or general position, the answer is no. It's not needed. I wouldn't recommend that you delay or dismiss making a career move because of it.
It's easy for me to say, and it might be hard for you to believe. To reassure you, what I want to do in this article is walk you through some scenarios where you "think" you might need to be a coding ninja and explain to you why you don't.
Scott Mitchell
The role of AppSec is to enable
One of the primary functions of an ASE is to enable developers to write secure code.
You will help identify and resolve security issues and remove security blockers for the development team. You do not write code; you understand the applicable threats and controls.
Having expertise in a specific programming language might sound beneficial from the outside looking in, but remember that you may be responsible for a number if not all of the development teams in an organisation.
In an ideal world, all those teams would be using the same technology stacks you know and understand, but unfortunately, that's rarely the case. There are often multiple languages and frameworks in play.
There is no real benefit to mastering one language if you have to work with twenty you don't know.
In software development, things are regularly changing. Don't expect the current tech stack to remain the same. To be scalable, you need to realise that security is your focus, not code.
It's a two-way thing
There will be sceptics out there already brandishing torches and pitchforks screaming that if AppSec can't understand the deeply technical side of a language they won't be able to perform in the role. Not true.
If you are sitting across the table from an expert in their field, would you spend hours trying to do something they could do in minutes? No, of course, you wouldn't and neither will they. Working together will lead to a faster, more efficient process and pulling together that expertise will minimise the risk of mistakes.
Break down the problem into security and code, then work together to find a solution.
For example, when looking into code-related issues, the first thing you should do is to ask the developer:
What is this code doing?
Now, when you ask that question, Developers being Developers, are likely to have a technical explanation that will make your brain melt and fall out of your ears. Don't be afraid of this situation. It's perfectly acceptable to rein them in and ask for the information in layman's terms.
Don't forget whilst you think a developer's techno-babble sounds like Klingon. They will be thinking the same about your security ramblings.
Whatever language or technology that comes your way, this approach will get results. Tell me again why you need "Expertise with a programming language"?
Identifying and fixing issues
You may feel worried that if you don't know a programming language, you won't be able to identify or help fix issues.
It's unlikely that anyone will review every page of code written on a manual basis. It's more likely that the issue will get identified by some tooling like Static Application Security Testing (SAST).
Tooling finding issues is not a bad thing. That's what it's there to do.
When SAST identifies problems in the code, it is your job to ensure the different protection mechanisms are understood.
Nearly every SAST solution I've used will give language-specific technical implementations that can help. Often these solutions can't be directly applied but remember, you should be focused on the security and let the developer worry about the intricacies of the implementation.
There will be times when you are both scratching your heads as you don't know how to fix the problem or the developer has raised some complications.
These are the times you need to take the lead and investigate further.
Oh dear, this sounds massively technical.
Even at this escalated level, there is still no need to panic. What you will be looking at will be very focused, usually method level and class level at the most. Remember that you won't be required to fix the code. You are only doing the security research to assist the developer (or architect) in solving the problem.
Still want to do that two-year course?
Script don't code
So, hopefully, you understand that the role is security, not development. However, scripting is immensely powerful, so it should be high on your pre-career checklist.
AppSec is not the only team that can be overloaded. DevOps is always in demand. Getting a good grip on the above will allow you to ensure your automation and shift left journey is not delayed.
Get familiar with Bash and PowerShell.
Many tools, utilities and scripts will require a reasonable understanding of Bash and Powershell. These tools are no longer specific to either Linux or Windows.
Docker and Docker Compose are useful.
Docker is not scripting. It won't hurt to learn basic commands and understand a compose file though. Many tools and utilities will leverage containerised technologies, so it's worth investing some time in the basics.
Conclusion
Hopefully, I've been able to demonstrate why there is little if any call for "Expertise with a programming language" in fact, not having it can encourage a healthier and more efficient working environment.
If you want to learn a programming language, then go for it but understand there is no need to spend two years and wads of cash because you think it's an essential requirement.
As a hiring manager in Application Security, a candidate who can talk about the threats and mitigations that apply to my languages and frameworks will always have an advantage over someone with expertise in programming.
As always, I hope this little insight into my world has been able to answer some questions and give you some encouragement and confidence.
