Cybersecurity Career Paths: Application Security
This will be a deep dive on Application Security, part 2 of a 5 part series where we discuss career paths and roles within Cybersecurity in more depth.
Previously we mentioned we were going to cover,
AppSec
Detection and Response
Incident Response
Threat Intelligence
Threat Hunting
Compliance
Blue Team Paths Overview
In this post, AppSec (Application Security) will be discussed.
Other names for this area of Cybersecurity are “Production Security” or “Prod Security”. When we hear “Production”, this means anything that could be considered customer facing. With nomenclatures out of the way, let’s dive into this domain, how it fits into the field of Cybersecurity, and what the day to day can look like for someone.
This is the field you’d pursue if you have some developer or engineer experience. For example, maybe you’ve worked at a startup as a Software Engineer for a year or two but have been interested in Security.
I work with several members of the Prod Security team, and can say that the scope of work can include Incident Response on the Production side, security library reviews, and code reviews for other engineering teams. Diving a little deeper into these this could look like the following:
Incident Response for Production
This can be incidents where the main web app is down, or a major API in production has been leaked.
The AppSec team leads this incident with support from other members of the Security team.
What could this look like?
Members on the AppSec team will investigate application logs, root cause, and bring in other engineering teams as needed.
Depending on the nature of the incident, and the application being in production, careful consideration is given to the availability of the application while responding to the incident.
Security Library Reviews
Apps and tools all use different code libraries, such as jQuery in JavaScript, Requests or Pandas in Python and so forth.
Members of the Product Security team can find themselves reviewing these libraries for best practices and security holes. This could be proactive or due to a vulnerability disclosed in a certain library or package.
What could this look like?
Reviewing the codebase after libraries in use are reported vulnerable in a disclosure. Going through a plethora of packages, to locate where they’re vulnerable either through a combination of manual and automated analysis or through a platform like Snyk.
Code Reviews
When an engineering team wants to ship a feature and this has been peer reviewed (i.e. Github), a Security review follows as a last step.
What could this look like?
The AppSec team here is not necessarily reviewing for purposes of the actual feature to be shipped (chat, widget, etc. ) but for code using vulnerable libraries or disclosing sensitive information.
These are 3 areas of the job and what a day to day could look like securing applications within Application Security.
Conclusion
This is not an exhaustive list, just an overview of what the job looks like.
Hope this was helpful in understanding the career path and domain of Application Security. Now that you have a glimpse into the world of Application Security, take the next step on your journey. Dive deeper into the topics discussed, and you’ll be well equipped to make an impact.