Cybersecurity Career Path: Application Security
Career Path Series
Continuing on with the Career Path Series, this will be a deep dive on Application Security, part 4 of the series where we discuss different career paths and roles within Cybersecurity.
Cybersecurity Career Paths: GRC
One path within Cybersecurity that holds a lot of potential for growth is the one of Compliance and Governance, Risk, and Compliance (GRC)...
Previously we went over
Detection and Response
Threat Intelligence
Threat Hunting
GRC
In this post, Application Security (AppSec) will be discussed.
Otherwise known as “Production Security” or “Prod Security”.
With naming 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.
Most of my time has been in Detection and Response but I have worked with several members of the Prod Security team.
Part of 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 any of several frameworks.
Diving a little deeper into these job functions could look like the following.
Production Incident Response
This can be incidents where a web app is down, a major API key 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 reactive due to a vulnerability disclosed in a certain library, a back-doored package, or dependency confusion (Cursor* anyone?).
This could be reviewing the codebase after libraries in use are reported vulnerable in a disclosure. Scanning through a plethora of packages, to locate where there is a vulnerable one either through a combination of manual and automated analysis.
Security Reviews
When an engineering team wants to ship a feature and this has been peer reviewed (i.e. Github), a Security review could then follow 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, disclosing sensitive information, or other best practices.
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.
Example Job Description
https://www.linkedin.com/jobs/view/4130496866
Directly from the job description, some of the responsibilities:
Triage a wide range of vulnerabilities reported via our bug bounty program, responsible disclosure, GitHub Issues covering web, API and server - client assets including low level memory issues like heap or buffer overflows
Improve and develop security assurance activities - pentests, vulnerability assessments, bug bounty programs, fuzzing
Drive implementation and usage of engineering security tools - static, dynamic code analysis, dependency checks, code licensing compliance (working knowledge of Snyk, Semgrep, GitHub CodeQL)
It requires a combination of Engineering skills and enabling Software Engineers throughout the company.
What I Read This Week
A workshop as a blog series about Threat Hunting utilizing the PEAK framework
How To Detect Honeypots in AWS
Tejas Zarekar describes how to detect and avoid canarytokens for AWS access key IDs
Product Security Bad Practices
Here are Product Security bad practices provided by CISA, following the Secure by the Design initiative
Conclusion
This is not an exhaustive list of what the domain entails, just an overview of what the job looks like.
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.