Cybersecurity Career Paths: AppSec
Application Security
This will be a deep dive on Application Security, part 3 of the series where we discuss different career paths and roles within Cybersecurity in more depth.
Previously we went over
Detection and Response
Threat Intelligence
Threat Hunting
In this post, AppSec (Application Security) will be discussed.
Other names for this area of Cybersecurity are “Production Security” or “Prod Security”. The word “Production” here 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 in this role.
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 but have been interested in Security.
I have worked with several members of the Prod Security team, and can say that the scope of work could include Incident Response on the Production side, security library reviews, code reviews for other engineering teams, or Threat Modeling using STRIDE (or some other framework.)
Diving a little deeper into these job functions could look like the following.
Incident Response for Production
This can be incidents where a main web app is down, a major API in production has been leaked, or some other secret has been exposed in CI/CD.
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. Whenever you hear of a company breach in the news, this team was most likely involved in the aftermath.
Security Library Reviews
Apps and tools all use different code libraries, such as jQuery in JavaScript, Requests or Pandas in Python and so forth.
Doing security reviews with these libraries for best practices and security holes is a crucial part of the process. This could be proactive or due to a vulnerability disclosed in a certain library or a back-doored package or library (xz anyone?).
What could this look like?
This could be reviewing the codebase after libraries in use are reported vulnerable in a disclosure. Going through a plethora of packages, to locate where if there is a vulnerable one 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 then 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 or out of date libraries, or disclosing sensitive information.
This form of Security review could be as part of a design process, before any code is written for the project.
These are just 3 areas of the job and what a day to day could look like when securing applications within AppSec.
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. Some resources to dive deeper into this domain.
Stay tuned for the next part of this series, where we will look into another domain of Cybersecurity.