top of page

Getting into Application Security

Updated: Sep 21, 2021

I’ve been asked a few times recently about how to get into application security work professionally. I’ve decided to wrap up my thoughts into this blog post, so I don’t need to send a long winded chat message over LinkedIn or Facebook. Application security is extremely lucrative and in high-demand, so it’s easy to see why the interest is there. Unfortunately, there is a severe lack of talent in this field. To me, just having a degree in the computer sciences isn’t everything and a true interest in computer security is required.

How I got my start and what I was doing before

My pathway into application security is quite unorthodox. Back in the 2000's (2008-2010), I had been laid off from multiple jobs because of the recession. For years up to that point I had been dabbling in web application technologies (PHP and MySQL) and web application design (HTML, CSS, Photoshop, etc.). By 2010 I had only worked for two clients creating their website from scratch, however the pay wasn’t good enough. But I did have a pretty good understanding of the fundamentals of web technologies.

And in late May of 2010, I had a chance meeting with a director of a web application security company while drinking at a nearby pub. He gave me an impromptu interview on the spot while we drank beer and shots of whiskey. I guess I did good enough in my drunken state understanding concepts like output encoding and SQL injection that I was given a formal interview. I completed the interview and got the job, and the rest is history.

What this also goes to show you is who you know is also a huge factor in getting a job sometimes. I was extremely lucky, because at that time I didn’t even consider application security as a possible career avenue. Unfortunately, even now, there are a lot of people that don’t realize this is a possible career path in IT, thus why there is a severe shortage of talent.

Was it worth starting so far down on the bottom rung?

You have to get your start someplace. When I started my first application security job, I was severely underpaid, especially for a 20-something living in the Silicon Valley, where rent for a one bedroom apartment hovers around the $1500-$2000 a month range. But this was considering that I started essentially as a complete junior in this field, entry level to the nth degree.

I spent about a year and a half doing very remedial work, Vulnerability Verification, where I would manually check web application scanner findings for true positives (so that their clients didn’t have to wade through thousands of false scanner findings). This involved getting a possible result from the scanner, then manually going to the website and trying to get web vulnerabilities to work like Cross-Site Scripting and SQL injection. This was beneficial for someone like me because it gave me a very good understanding of how these issues essentially worked and why they are bad.

Later I was able to move over to doing web application penetration tests, where given a client’s website I had to crawl and diagram it’s structure and attempt to attack it to discover possible security issues. I did penetration testing for a little while, but realized later that there was a missing gap in the organization that I decided to fill, the lack of proper training for new hires.

So I eventually moved into a more managerial position, training new hires that came into the company. I remember having a thought ran through my mind in 2012, “how many people can say that they train people to hack websites for a living?” It was a great opportunity for me, because I was tasked with teaching these relatively complex topics to complete novices in computer security. For example, I had to train someone who was a chef and also someone who was a sound engineer. This not only helped ramp up new hires quicker, but also helped reinforce these topics for myself.

I won’t go over my entire career, but from there I changed positions two more times. I’ve gained an even greater understanding of the work required for this type of job and also where I foresee it going in the future.

Does it require a college degree?

In short, no. I did not get a college degree to do this job. I did attend a semester of art college in San Francisco, back when I still wanted to pursue an art degree in video game design. I eventually had to drop out due to financial struggles, but this was a huge blessing in disguise.

However, I have had a lifelong interest in computers being a PC gamer. I know how to disassemble and reassemble a PC computer; I even got good enough at it that in 2007 I worked for a systems integrator (à la Alienware or Republic of Gamers) where I built PC’s from its base components. In 2005 I received an A+ Certification for PC repair. But more importantly, I also had an interest in website creation, working in HTML and JavaScript while I was in middle school and high school.

If however you’re coming into this field completely green, where you know how to use a computer but you don’t understand it’s inner workings, especially if you don’t understand basic networking technology, then a more traditional college route may be beneficial for you to get those basics set in stone. I was lucky enough that I already came into the job knowing how most of this stuff worked.

Learn about security bugs

The base discipline of any information security job is understanding security bugs. What makes a software bug a security bug? A security bug is a flaw in source code that can lead to unforeseen consequences in the running application, even though it's still functionally sound. Security bugs are a subset of software issues that impacts the security of the application itself or its supporting systems. Due to this, security bugs can easily fly under the radar of both unit testing and quality assurance, because the application is still fully functional. Yet with a properly crafted input, an attacker can cause the application to act in an unforeseen, insecure manner.

Security bugs can live in any codebase, thick software clients and thin web based services. However, the types of security bugs a codebase is susceptible to can be vastly different due to numerous factors. As an application security professional, you should have a fundamental understanding of all of these.

Having a complete understanding of all of the possible security issues, and being able to explain them plainly, will be key to any job interview. So prepare to be extremely familiar with them.

Learn to dissect an application

While you may not be a programmer, you need to know how an application is fundamentally built and operates. One of the main tasks as an application security engineer is the Security Application Review. A development team in the organization is planning on a new application, and they’ve asked you to be their security reviewer. Where do you start?

First, get an understanding of how to structure a security review. The Microsoft SDL it is a good place to start as it lays out what tasks should be completed when in a development lifecycle. You will need to be able to read and understand application design documentation and architecture overview documentation. Stay tuned to this blog for additional content around these topics.

From those documents and diagrams, you will need to be able to build a threat model. A threat model lays out all of the possible security issues that will be of concern to the application, where the issues may arise, and how to prevent these issues from cropping up. This threat model is a document that is your responsibility as an application security engineer to draft up and deliver to the development team before they get too deep into the coding process. Remember, catching security bugs earlier in the development process makes them far easier and cheaper to correct then later on in the development lifecycle.

Also as part of the security application review, you will need to be able to read and review source code. Again, I don’t consider an application security engineer a programming position, but you will need to know how to read and understand source code. The key is being able to take source code, break up the review into manageable chunks, and be able to search for possible security issues. There are a lot of possible thought-processes on how to approach a security code review, but that is outside the scope of this article.

Suggestions on how to practice

While there is plenty of reading material and tutorials you can watch (passive learning), you must balance that with practical hands-on practice (active learning), at least a 50/50 mix. When you read about a new topic or watch a tutorial video, find a way to practice this new knowledge.

Usage of your tools is also very important. I prefer to use Burp Suite from PortSwigger as my go-to tool for web application penetration testing, but there are plenty others like OWASP Zap. Getting a good understanding of general security tools like Metasploit, SQLMap, and nmap will also help.

Participate in the open source community. Security review open source projects in Github, and if you find issues, see if you can write fixes to correct them. Open source project maintainers will always appreciate your assistance creating pull requests to fix security bugs. Bug Bounty is also a fantastic avenue to sharpen your penetration testing skills. Hundreds of companies now have a public bug bounty program, generally through either Bugcrowd or HackerOne. It's simple to sign up and get started penetration testing against real world applications. Just be careful to fully read the brief and scope of the participating company to ensure that your time is used wisely and that you are not inadvertently doing something illegal!

Take what you are learning through both passive and active learning, and then employ the Feynman technique. Boil it down into layman's terms so that a child can understand and write about it or create a presentation. Even if this material is just for yourself, you can save it for later if you require it for study material for an interview or a test for a certification.

The Application Security Engineer Interview

I’ve conducted dozens of application security interviews in my time. Here are some of the technical topics I like to bring up during an interview:

  1. A high level of understanding of the HTTP/S protocol.

  2. A high level of understanding of TLS and secure communication.

  3. Ability to effectively communicate with developers and project managers.

  4. Ability to write documentation like penetration testing results.

  5. Fundamental understanding of web application security issues (see Owasp Top Ten below).

  6. Ability to understand application design and architecture overview documents and diagrams.

  7. Ability to create a threat model based on application documentation and diagrams.

  8. Fundamental understanding of security features in applications like Authentication, Authorization, and Session Management.

  9. Ability to analyze source code for basic security issues.

  10. Understanding of password security and known issues with hashing/encryption algorithms.

Go to Conferences

While I don’t suggest the extremely expensive security conferences like BlackHat or RSA, there are a ton of smaller conferences around the world that are definitely worth the price of admission. Here are some of my suggestions:

  • Defcon @_defcon_

  • B-Sides @SecurityBSides

  • AppSec United States (OWASP National Conference) @appsecusa

Additional conferences that are dated for 2019, but most will come back in 2020 (rip DerbyCon):

Reading suggestions

Here are some reading suggestions I suggest you pursue:

Testing/Practice Apps

Where I see Application Security in the future

Ultimately wherever you end up, having a fundamental understanding of cloud infrastructure is now becoming mandatory. Study up or even spend some time working within AWS, creating IAM roles, spinning up EC2 boxes, and understanding how components in the cloud connect to each other. Even if you are interviewing for an organization that uses, say, Azure instead of AWS, having a base understanding of the cloud is beneficial for any platform.

Ultimately, knowing where Application Security is going in the future will help pivot your training path early. Please take a look at my previous article where I explain the direction I see Application Security is heading in the future.

Have comments or questions? Hit me up on Twitter @HellaSecure.


About the Author

Aaron is an Application Security Engineer with over 10 years of experience. His unorthodox career path has led to many unique insights in the security industry.

2,651 views0 comments

Recent Posts

See All


bottom of page