My Journey from Engineer to AppSec
How Did You Make a Career Change?
I can remember the first time I got into programming. My family got an Apple IIe and I taught myself BASIC so I could make it “do cool stuff”. This kicked off years of tinkering with computers, writing code and even building a few of my own. I loved building things and solving problems so I could get my program working just right.
Fast-forward (many) years later to my college years. While I started out in Computer Science, I quickly decided it wasn’t for me and switched over to an art/marketing degree plan. I kept my passion for programming, though. The internet was just starting to really catch on and it was another puzzle I felt drawn to try and solve. I spent plenty of time sitting in the computer labs at school learning everything I could about HTML, CSS, Javascript and, eventually, PHP. When I graduated, my first job was using exactly that same technology.
My Early Career as an Engineer
The next twelve years were spent working at a variety of companies building web applications. All the while I was growing my knowledge of how applications should be architected and where new technologies could be integrated. As I grew in my knowledge and experience, I moved up the line, first to Senior Engineer, then Lead Engineer but then I reached a certain point and I felt like my knowledge was plateauing. It seemed like a lot of the same functionality was being requested and the same problems kept coming up. That same spark in the work I was doing had faded, so I decided to make a change.
I took a step back and looked at what I enjoyed and where I felt I could grow. I had learned a bit about securing applications during my engineering career, but something about it struck a chord with me. I saw new challenges and new problems to solve. I saw how important security had become and wanted to be on the front lines, bridging the gap between development and security.
Pivoting Into Application Security
Application security was a natural fit so I started digging in. I read as much as I could from multiple sources - books, online articles, tutorials - all refreshing some concepts and learning entirely new ones.
My day-to-day was still programming, but I had a different perspective on it. I started to see places where the security of the application I was working on could be improved. I also learned more about security testing and, after trying my hand at it, found some endpoints that weren’t protected. Fortunately, we caught it before it was released and it felt good knowing I’d done at least a bit to secure the application. I knew that this was the direction I wanted to go.
Once I realized that I wanted to focus on application security, the next step was to find a role where I could not only explore this passion but also grow and improve my skills. I was definitely stepping outside of my comfort zone.
I interviewed at a few different companies but they weren’t quite a match. Finally, I interviewed with Salesforce for an AppSec role with a product with a large PHP codebase. It turned out to be a good fit and I got my first official application security job!
I spent the next three years drinking from the security firehose, learning as much as I could. I worked directly with the development teams, collaborating with them on security reviews and implementations. My background in development came in handy too, helping me to see things from their perspective and make sure that I was putting things into a context where they could apply it easily in their day-to-day work.
Ready to tackle my next security challenge, fearful of another plateau, I chose a security company. I came here to Duo, excited about moving into a more security-focused team. I’ve been here about two and a half years and am still learning new things every day and loving it.
My Advice to My Past Engineer Self Would Be...
The main piece of advice I would have given to myself back in my days of just writing code would be to take the time to learn some of the best security practices and, most importantly, integrate them into your daily work. Some of the resources linked down below are a great place to start.
I can remember thinking, especially when I was first starting out in the industry, that security was something to consider later. There was a time when the only concern in my mind was to make sure the code that I was writing was functional.
We’d take the feature request in, break it down into its parts and split out those tasks among the team. Unfortunately, security considerations weren’t included in that list and there wasn’t a push for it from those higher up the chain.
It sounds terrible to say now, but back then I didn’t care as much about whether what I was developing was secure. Most early-career developers focus on proof-of-concept vs. security. I knew about some of the basics about securing web applications like “there should be authentication” and “SQL injection is bad” but I had no idea about more complex attacks. It wasn’t until later, after I really started digging into application security, that I realized how vulnerable some of the code I had written was.
I think every application security engineer that has come over from the development world has a story similar to mine. You don’t know what you don’t know, but once you learn something new you can work hard to better secure your code.
How Do You Think AppSec Engineers Can Work Best With Software Engineers?
Software engineers and security engineers have a lot in common. True, when I first started working in application security, I was surprised that some Application Security Engineers hadn’t done much programming at all. Others were like me and had come from a development background. While they have different areas of focus, the drive to learn and grow in their knowledge and experience was the same. We work best when collaborating.
That’s the main thing I’d recommend to anyone in a security role. Don’t work in isolation, just passing a report back or just filing bugs. You need to build a relationship and trust with the engineers. Sit down and really understand what they’re working on and what they’re asking for. Sometimes that is just a report at the end of an assessment. Other times engineers need someone to work through a concept or feature to make sure they’re making the most secure product they can.
The engineer is not the only one who benefits, this collaboration is positive for the security engineer too. In working with the software engineer who spends the majority of their time in the code, they gain more perspective on the inner workings of the system and what really makes it tick. That way the security engineer doesn’t have to be an expert in the codebase, they just need to know who to ask for what kinds of details.
Each side brings their own specialized knowledge to the table, making for a good balance of knowledge and not requiring either to be a “jack of all trades.” Having engineering connections like this can be an invaluable resource and security engineers shouldn’t be afraid to ask questions to gain more context . In my experience, software engineers are more than happy to share if they know they’re being listened to.
My Favorite AppSec Resources
One of the recommendations I’d make to those either wanting to get into application security or those new to the field is to check out some of the resources the OWASP group has released. More specifically, I’d recommend their OWASP Top 10 list (most common vulnerability types, refreshed every few years), their “OWASP cheatsheets”, and some of the tools like the ZAP Proxy. Some of their information can be a bit out of date, as it’s a community-driven project so just be mindful of the date the resource was published on.
Outside of that I found that learning organically works well, starting with a source (like the Top 10 list) and working out from there, researching any terms or concepts I’m not familiar with. There’s some topics that are a bit more elusive than others, though. Cryptography is a good example. I’ve always had difficulty wrapping my head around its concepts and with it being such an important part of cybersecurity, it was frustrating.
The basic concepts were easier to grasp but when I started to dive into the specifics of ciphers, block modes, and algorithms things started to get a little fuzzy. So, instead of trying to bite off a big chunk of knowledge, I took it slow. I learned more “hands on” during my day to day work, reading up on concepts and technology as they came up. This “bite size” approach still grew my knowledge without it being overwhelming and frustrating.
One last thing I would recommend to those security engineers that don’t have much experience in development that they set aside some time to read about programming-related topics or, even better, write something in the language of their choice. It gives some amazing perspective on what software engineers do day-to-day and can help improve communication through common understanding.
We’re hiring! If your mission is collaborating with inspiring teammates, and creating and supporting products that make a difference, we want you! Learn more at duo.com/careers
Try Duo For Free
With our free 30-day trial you can see how easy it is to get started with Duo and secure your workforce, from anywhere and on any device.